Explanation: What to Consider When Designing Cross-Chain Bridges?

Introduction

Since the establishment of the blockchain industry, countless L1/L2s have emerged, and almost every public chain has developed its own DeFi ecosystem. Some people only interact on specific public chains, while more people hope to find profit opportunities such as trading and mining on different chains. Among these, cross-chain fund transfer has become an indispensable necessity.

In addition to ordinary users, many project parties also need to transfer funds between different chains, guide liquidity on different chains, and achieve “one money for multiple uses.”

However, different blockchains are isolated consensus systems, and there is no way for funds to cross directly from one chain to another. The essence of cross-chain funds is that the cross-chain bridge acts as a public counterparty, receiving user funds on the source chain and sending money to users on the target chain. (Issue mapped assets, or release funds for users from the liquidity pool reserved by the target chain).

What is the best way to realize cross-chain funds? In the beginning, people still trusted centralized exchanges. There was a saying at one time: “Centralized exchanges are the best cross-chain bridges.” However, the operation of “Stake-swap-withdraw” is very cumbersome, and people hope to have a pure chain. In this way, funds can be cross-chained more directly.

Moreover, compared to centralized exchanges, Cross-chain bridges can complete more general cross-chain messaging, not just limited to fund transfers. For example, if you use a cross-chain lending dApp to provide stake from chain A and lend assets on chain B, you need to use cross-chain messaging.

If you examine the historical origin of cross-chain, it can be traced back to the early stages of the development of blockchain technology. At that time, the emergence of different public chains made people realize that the interoperability problem between chains had to be solved, otherwise many information/fund islands would appear. Over time, people have proposed different types of cross-chain methods, gradually forming today’s general cross-chain model.

Below we will explain some developments in cross-chain technology.

1. Methodology

Find counterparties yourself think about it, what is the most intuitive cross-chain method? Suppose you have 100 USDT on chain A and you want to transfer them to chain B. There happens to be a person who has 100 USDT in chain B, and he wants to transfer USDT to chain A. The two of you saw that this was just right, so you hit it off immediately. But when you transferred USDT to the other party’s address on chain A, he regretted it and did not transfer his USDT on chain B to your address. Therefore, This P2P trading model is not very reliable. Firstly, the other party may break the contract, causing you to suffer losses without any guarantee; secondly, this counterparty is not easy to find, and you may have to wait a long time to find one that just matches the amount you want to cross, but the cross-chain direction On the contrary, users may not even be able to wait for such a counterparty for an eternity.

2. Notary Services

2.1 Individual notary

So we thought that since the other party may breach the contract, Can I find a trusted third party to conduct transactions? I give him the money first on the source chain, and then he promises to transfer the money to me on the target chain. For example, this person has assets on both chain A and chain B and then he guarantees that as long as he receives 100 USDT from me on chain A, he will transfer 100 USDT to me from chain B.

This is much better than the first P2P inter-chain asset exchange, because there is a trusted public counterparty, who has a magical thing called “liquidity” in his hands, and you can trade with it at any time.

In other words, your transaction with him becomes a “point-to-pool” transaction rather than a “point-to-point” transaction. But you still feel uneasy. If you trade 100 USDT with him, that’s fine. What if you want to trade 1 million USDT with him? Even though he had a relatively good reputation, he still took the money and ran away.

After all, this notary introduces a kind of centralization, which is still not the Trustless cross-chain method we want.

2.2 Multiple notaries (MultiSig)

What if this notary is not one person, but a group of people? We can establish a co-managed account, and multiple signers jointly manage the account. They have to sign a message. Only when the number of signatures reaches a threshold (usually 2/3) will the funds be transferred.

In this case, if a small number of them (no more than 1/3) have a wrong idea and want to collect money from me on the source chain, but don’t want to send money to me on the target chain, or are offline, it doesn’t matter. Another honest notary would still sign and transfer the money due to me.

This solution is more reliable, weakens the risk of centralization, and is more secure. For example, if there are 20 reputable notaries in total, the probability that they will act wrongly at the same time is still very low. (This does not include situations like Multichain where 20 nodes are managed by one person, or situations like Axie cross-chain bridge where hackers stole 2/3 of the notary’s signature keys.)

2.3 Multiple Notary Public (MPC)

However, the multi-signature account management method also has many inconveniences.

Multi-signatures make signature rules more easily exposed. If it is a 5/7 signature scheme, the smart contract code of the multi-signature wallet will reveal how many signers there are, and hackers can look for these signers in a targeted manner and wait for opportunities to steal the private key.

Multi-signature requires adaptation to different public chains. For example, some public chains do not support smart contracts, so you have to use the chain’s specialized cryptographic primitives to implement multi-signature accounts. If this is not supported, your multi-signature wallet will not be able to operate.

The signer of multiple signatures cannot be changed once the signer has been decided. For example, if you want to change the 5/7 signature scheme to the 6/8 scheme, or if you want to change the signer, you have to redeploy the multi-signature contract and transfer the funds to the new multi-signature contract.

The first cross-chain solution for BTC derivatives, tBTC, used the multi-signature method, which has been eliminated because it was lame and difficult to use. Most of the current cross-chain bridges adopt the more advanced MPC method.

Multi-Party Computation’s full name is Multi-Party-Computation (Multi-Party Secure Computation), which is a private key sharding technology. A multi-signature account manages an account with multiple private keys, while an MPC account manages an account with one private key. The private key is divided into multiple fragments. Multiple signers each hold one private key fragment. When the number of signers is A complete signature can be synthesized only when the threshold is reached, and the complete private key will not be exposed during the signing process.MPC accounts have the following advantages: they are more confidential than ordinary multi-signature wallets. When a signature is required, for example, 5/7 private key fragments are used to sign each, and multiple sub-signatures are merged to form a final legal signature. In this way, what you see on the chain is a single, ordinary signature. You cannot tell whether it comes from the MPC account, let alone who the signer is behind it, nor the number of private key fragments and the specific signature rules. It can adapt to most public chains better than multi-signature wallets.MPC is a signature technology and has nothing to do with the chain. An MPC account is an ordinary account. Regardless of whether a public chain supports smart contracts, a co-managed account can be constructed through MPC technology.MPC replacement signature mechanism is more flexible. It can support more flexible signature rule adjustments, such as changing the number of private key fragments and signature thresholds at any time, and you can also change the signer at any time. You only need to re-share the private key.

3. Further security measures

3.1 Separation of hot and cold

After the notary’s custody account received my 100 USDT on chain A, it transferred 100 USDT to my address on chain B. What should be the triggering process for this behavior?

Suppose that each notary member has a machine monitoring the transactions on chain A. When they found out that I transferred 100 USDT to the cross-chain bridge custody account, this transaction stated that I hoped to be named on chain B. Receive these USDT for user2’s address.

At this time, the notaries jointly signed and transferred 100 USDT in the cross-chain bridge account on chain B to the user. This process must be written into code and run automatically, otherwise, the notary would have to be online in real-time and have to operate immediately after receiving the request, which is too unrealistic.

This automated program will contain several parts

1. Monitoring program: Responsible for monitoring transactions on the source chain. To filter irrelevant transactions or invalid transactions, this step may perform some basic format verification;

2. Verification procedure: This will include the light node client (which may also be a full node) of the supported blockchain, responsible for verifying that a transaction on the source chain that interacts with the cross-chain bridge contract is packaged into a block and put on the chain. ;

3. Signature procedure: Responsible for signing and initiating transfer transactions to users on the target chain.

But automation also brings a problem, that is, the automated program may be attacked and manipulated by hackers. Therefore, to control risks, cross-chain bridges will take measures to separate hot and cold. The automated program controls the hotkey, and the amount of the transfer is limited. For large transfers, the notary must use the cold key to sign manually. The rules for hot and cold separation can be implemented in the MPC account.

3.2 Risk isolation

If there is a bug, don’t you want to deal with it all in one incident? Therefore, it is necessary to isolate the capital pool and use multiple custody accounts to manage liquidity funds. For example, according to the isolation between different public chains, A and B, B and C, and C and D are all independent capital pools.

3.3 TEE

The automated monitoring and signing programs run by the notary can be run on TEE devices, which can greatly increase the difficulty of hacker attacks.TEE stands for Trusted Execute Environment, which is a computing environment running on a given device that is isolated from the main operating system, like an enclave.

This isolation is hardware-enforced with extremely high security, so TEEs can run applications with high-security requirements, such as encryption key management, biometric authentication, secure payment processing, etc.

3.4 PoA goes to the left, PoS goes to the right

To make cross-chain bridges more secure, There are two directions in the selection of notaries:

One is to choose large companies and well-known institutions with good reputations as much as possible. For these institutions, the cost of doing evil is extremely high, and they may lose years of goodwill. Additionally, try to keep them as geographically diverse as possible (avoiding concentration in the same jurisdiction).

For example, the cross-chain bridge project Wormhole has chosen this model. Its 19 nodes are backed by well-known large institutions with large sizes and strong funds. This is the PoA method.

Another way is to admit permissionless notaries but require them to stake. If they misbehave, their staked funds will be slashed. This is how PoS works. This is what ZetaChain uses.

Which of the two methods is better and which is worse is difficult to draw an arbitrary conclusion directly. It depends on how well the cross-chain bridge project parties do in their respective directions.

Whether it is PoA or PoS, you can make the cross-chain bridge directly into a public chain. Each node runs the same program, and all cross-chain requests and processing processes will be recorded on this chain. The chain itself can also host applications, thus becoming an ecological hub.

3.5 Observer

Another way to enhance security is to set an observer role. This role is responsible for monitoring cross-chain behavior and, if problems are discovered, reporting on-chain and aborted transactions. Since observers need a window period to react, the arrival time of cross-chain transfers may be delayed. Therefore, observers will only intervene if users accept transfer delays for large-value transactions or sensitive cross-chain operations.

Other cross-chain solutionsHash lockBack to the first method mentioned in this article: P2P looking for counterparties for cross-chain asset exchange. If we are afraid that the counterparty will default on the loan, we can set up a mechanism. Once someone reneges, the other party can get the money back and return it intact. This is hash locking, which cleverly uses hash locks and time locks, It forces the recipient of the funds to confirm the payment before the deadline and generate a proof of receipt on the source chain. With this proof of receipt, the payer will be able to obtain the recipient’s equivalent assets on the target chain. Otherwise, both parties will All funds will be returned via the original route.

However, this method can only exchange funds and cannot complete general cross-chain information transfer. Even from the perspective of cross-chain fund transfer, the user experience of hash time locks is very bad: if the fluctuation of currency prices is unfavorable to the counterparty (liquidity provider), he may rationally choose not to complete the transaction; to complete For a cross-chain exchange, both the user and the counterparty must sign twice. therefore, As a cross-chain solution, hash time locks have been eliminated. Early cross-chain bridges (such as cBridge, and Connext) that used this solution have changed their ways. On-chain light clientThis method is to directly deploy the light client contract of the source chain on the target chain. If you deploy a contract on a chain, all nodes in the chain will run the contract code you deployed.

Therefore, the on-chain light client solution allows the target chain to directly verify transactions from the source chain. This method is extremely secure but is also the most expensive. Expensiveness is reflected in the following aspects: The light client contract of the target chain needs to receive and verify the new block header from the source chain in real-time. This process consumes a lot of Gas. Even if ZK is used to achieve a concise proof, the Gas consumption of verifying a ZK proof will not be less than 400,000 Gas (EVM For example), in the MPC scheme, all that is required to be verified on the chain is a signature, and the gas consumption is only a little over 20,000, a difference of 20 times! Would you use a safer bridge but 20 times more expensive?

The amount of work required to develop light client contracts is huge. To make the cross-chain bridge compatible with more heterogeneous chains, you need to implement the light client contracts of other chains in completely different development environments of different chains, which is a hell-level challenge for developers. This leads to a greater probability of bugs in contract writing, that is to say, the security of a light client bridge is only at the theoretical level, but in terms of engineering practice, it is very unsafe. To reduce the amount of development work, a feasible solution is to introduce a relay chain and let all chains establish light client contracts with this relay chain. This can indeed reduce the workload of C(n,2) to n, but still not too small. The original direct cross-chain transfer from the source chain to the target chain has become a second-order transfer of the source chain → relay chain → target chain, which will cause additional gas consumption and time consumption.

Therefore, the light client technical solution currently cannot be used to build a more universal cross-chain bridge.

End Game

First of all, different public chains have different approaches and have different resources to support them. As long as they don’t admit defeat, the ecosystem will exist. Even if the development is not very good in the short term, it may one day be upgraded and it will come back to life. The thing about underlying infra like this is to see who can persist longer and who can adjust to the market quickly.

Bitcoin and Ethereum cannot solve all application scenarios, or in a certain segment, there are always people who don’t like the first place, so they create a new wheel, so the future will be multi-chain. In the future, the bottom layer will no longer be a chain, so the future must be multi-ecological. How to transfer funds and messages between multiple ecologies requires cross-chain/cross-ecological technology!

What are users most concerned about when it comes to cross-chain? Nothing more than the following points:

Speed: How long does it take for a cross-chain operation to be completed?

Fee: How much do I need to pay for a cross-chain operation

Security: Is the cross-chain bridge safe and will funds be lost?

Liquidity: Is there enough liquidity to support my trade and an acceptable price impact?

Connection scope: How many chains do you support? Do you support the chains I need to use in cross-chain operations?

Experience: Is cross-chain operation convenient, such as whether it supports gas payment, whether the cost estimate is accurate, whether it supports progress query and browser viewing, whether failures frequently occur, how to handle failures, etc?

Let’s first take an overview of the characteristics of some projects from three relatively clear perspectives: security, cost, and connection range.

Click the link to view the clear table (the table is constantly being updated):

https://docs.google.com/spreadsheets/d/1LKlbd5KJUnQIx3ZBTgyMADhxHtWVwBH9qDRm765tPMw/

To fully explain the cross-chain bridge, there are many dimensional details that need to be discussed, such as all dimensions and data analysis in the table above. So what factors do you care about when crossing chains? Which cross-chain bridges do you often use? What aspects do you think cross-chain bridges should focus on for optimization? If you have your ideas, please feel free to communicate with the author.

Disclaimer：

1. This article is reprinted from [极客Web3]. All copyrights belong to the original author [0xKooKoo]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.