Vernacular popular science: What should be considered when designing a cross-chain bridge?

Author: 0xKooKoo, Technical Consultant for Geek Web3 & Moledao, former Technical Lead at Bybit

**Thanks to 0xmiddle for their help in writing this article. **

Introduction****

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

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

But 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 to receive user funds on the source chain and send money to users on the destination chain (issuing mapped assets, or releasing funds for users from the liquidity pool of the target chain).

In the beginning, people still trusted centralized exchanges, and there was a saying that “centralized exchanges are the best cross-chain bridges.” However, the operation of “charging-swapping-withdrawing” is very cumbersome, and people hope that there will be a pure on-chain method to complete the cross-chain of funds more directly.

Moreover, compared to centralized exchanges, cross-chain bridges can complete more general cross-chain messaging, not only limited to the transfer of funds. For example, if you use a cross-chain lending dApp that provides collateral from Chain A and lends assets on Chain B, you’ll need to use cross-chain messaging.

If we look at the historical origins of cross-chain, we can trace it 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 there would be a lot of information/capital silos. Over time, different types of cross-chain approaches have been proposed, gradually forming today’s universal cross-chain pattern.

Let’s take a look at some of the developments in cross-chain technology.

Methodology****

1. Find your own counterparty

Let’s think about it, what is the most intuitive way to cross-chain? Let’s say 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 wants to transfer USDT to Chain A. The two of you saw that this was not just right, so they hit it off.

But when you transfer USDT to the other party’s address on Chain A, he repents and does not transfer his USDT to your address on Chain B.

Therefore, this P2P transaction model is not very reliable, firstly, the other party may break the contract, so that you suffer losses, without any protection, and secondly, this counterparty is not easy to find, you may have to wait for a long time to meet a user who just matches the amount you want to step out, but the cross-chain direction is opposite, and may not even wait for a long time to wait for such a counterparty.

2. Notary Schemes

2.1 Single notary witness

So we thought, since the other party may default, can I find a trusted third party to trade?**I give him the money on the source chain first, 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 my 100 USDT on Chain A, he will definitely transfer 100 USDT from Chain B.

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

In other words, your transaction with him becomes a “peer-to-pool” transaction, rather than a “peer-to-peer” transaction. But you still don’t feel sure, if you trade 100 USDT with him, it’s fine, what if you want to trade 1 million USDT with him?

In the final analysis, this notary has actually introduced a kind of centralization, which is still not the trustless cross-chain method we want.

2.2 Multiple Notaries (MultiSig)

What if the notary is not a single person, but a group of people? We can set up a condominium account, where multiple signatories jointly manage the account, and they have to sign a message, and the number of signatures reaches a threshold (usually 2/3) before the funds are transferred.

In this case, if a few of them (no more than 1/3) have a crooked mind and want to collect my money on the source chain, but they don’t want to send me money on the target chain, or if they go offline, it doesn’t matter, other honest notaries will still sign and transfer the money that should be given to me.

**This scheme is more reliable, weakens the risk of centralization, and is more secure. For example, there are a total of 20 reputable notaries, and the probability of them having crooked minds at the same time is still very low. (This doesn’t include Multichain’s 20 nodes actually managed by one person, or hackers stealing 2/3 of the notary’s signing keys like the Axie bridge.) ）

2.3 Multiple Notary Public (MPC)

However, there are also many inconveniences in the account management method of multi-signature.

Multisig makes signature rules easier to expose. **If it is a 5/7 signature scheme, the smart contract code of the multisig wallet will expose how many signatories there are, and hackers can find these signers in a targeted manner and wait for the opportunity to steal the private key.

**Multisig needs to be adapted to different public chains. For example, some public chains do not support smart contracts, you have to use the chain’s special cryptographic primitives to implement multisig accounts, if this is not supported, your multisig wallet will not be able to do it.

The multi-signature cannot be changed if the signatory is set. For example, if you want to change to a 6/8 signing scheme, or if you want to change the signer, you have to redeploy the multi-signature contract, and you also have to transfer the funds to the new multi-signature contract.

The cross-chain scheme of the first BTC derivative tBTC uses a multi-signature method, which has been eliminated because it is very lame and difficult to use. **Most of the current cross-chain bridges adopt a more advanced MPC approach. **

MPC stands for Multi-Party-Computation, which is a private key sharding technology. The multi-signature account is an account managed by multiple private keys, while the MPC account is managed by a private key to manage an account, the private key is divided into multiple fragments, and multiple signers each hold a private key fragment, and a complete signature can be synthesized when the number of signers reaches the threshold, and the complete private key will not be exposed during the signing process.

The MPC account has the following advantages:**

**More confidentiality than regular multisig wallets. **When a signature is required, for example, 5/7 private key fragments are used to sign each other, and multiple sub-signatures are fused into one piece to form a final legal signature. In this way, what you see on the chain is a single, ordinary signature, and you can’t tell whether it’s from an MPC account, let alone who the signer behind it is, and you can’t know the number of private key fragments and specific signature rules.

**It can be better adapted to most public chains than multisig wallets. MPC is a signature technology and is chain-agnostic. An MPC account is actually an ordinary account, regardless of whether a public chain supports smart contracts or not, you can build a condominium account through MPC technology.

**MPC is more flexible in changing signatures. **It can support more flexible adjustment of signature rules, such as changing the number of private key fragments and signature threshold at any time, and changing the signer at any time, only need to re-share the private key.

3. Further security measures

3.1 Hot and cold separation

**After the notary’s escrow account received my 100 USDT on Chain A, he transferred 100 USDT to my address on Chain B, how to trigger this behavior?

Let’s say that each notary member has a machine listening on transactions on chain A, and when they find out that I transferred 100 USDT to a cross-chain bridge escrow account, and the transaction states that I want to receive these USDT at an address named user2 on chain B.

At this time, the notaries collectively co-signed and transferred 100 USDT from the cross-chain bridge account on Chain B to user2. This process must be written in code and automated, otherwise the notary will have to be online in real time, and the request will have to be operated immediately, which is too unrealistic.

There will be several parts in this automated program

1. Listener: Responsible for monitoring transactions on the source chain, in order to filter irrelevant transactions or invalid transactions, this step may do some basic format verification;

2. Verification procedure: This will include the light node client (or full node) of the supported blockchain, which is responsible for verifying that a transaction on the source chain that has an interactive relationship with the cross-chain bridge contract has really been packaged into a block and put on the chain;

3. Signature program: Responsible for signing and initiating the transfer transaction to the user on the target chain.

But automation also brings with it the problem that this automated program can be hacked and manipulated. Therefore, in order to control the risk, the cross-chain bridge will take measures to separate hot and cold. **The automated program controls the hot key, the amount of the transfer is limited, and in the case of a large transfer, the notary must manually sign with the cold key. The rules for hot and cold separation can be implemented in the MPC account.

3.2 Risk isolation

Therefore, it is necessary to do a good job of isolating the capital pool and using multiple custodian accounts to manage liquidity funds, such as isolating according to different public chains, such as A and B, B and C, C and D are all independent capital pools.

3.3 TEE

**The automated listening and signing procedures run by the notary can be run in the TEE device, which can greatly increase the difficulty of hacking attacks. **TEE stands for Trusted Execution 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 cryptographic key management, biometric authentication, secure payment processing, and more.

3.4 PoA to the left, PoS to the right

In order to make cross-chain bridges more secure, there are two directions in the selection of notaries:

**One is to choose a large company or well-known institution with a good reputation as much as possible. For these organizations, the cost of doing evil is extremely high, and it can cost years of goodwill. In addition, try to make them geographically diverse enough (avoid being concentrated in the same jurisdiction).

For example, the cross-chain bridge project Wormhole has chosen such a model, and its 19 nodes are all well-known institutions with large volume and strong funds, which is the way of PoA.

The other way is for Permissionless notaries to admit, but they are required to make a pledge, and if they misbehave, their pledged funds will be slashed. That’s the way PoS works. That’s what ZetaChain is all about.

It is not good to directly and arbitrarily draw conclusions about who is superior and who is inferior in the two ways. It depends on how well the cross-chain bridge project parties are doing in their respective directions.

Whether it’s PoA or PoS, you can make a cross-chain bridge directly into a public chain, where 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 up an observer role. This role is responsible for monitoring cross-chain behavior and can report and abort transactions on-chain if issues are found. Since the observer needs a window to react, the arrival time of the cross-chain transfer may be delayed, so the observer will only intervene if the user accepts the delay in the transfer for a large transaction or sensitive cross-chain operation.

Other cross-chain solutions****

Hash Lock

Back to the first method mentioned in this article: P2P to find a counterparty for cross-chain asset swaps. If we are afraid that the other party will default on the debt, then we can set up a mechanism, once someone repents, the other party can get the money back and return it to Zhao.

This is hash locking, which cleverly uses hash locks and timelocks to force the recipient of the funds to determine the receipt before the deadline, and generate a receipt certificate on the source chain, and the payer must obtain the recipient’s equivalent assets on the target chain with this receipt proof, otherwise the funds of both parties will be returned to the original way.

However, this method can only exchange funds, and cannot complete the general cross-chain information transfer. And even from the perspective of cross-chain transfer of funds, the user experience of hash timelock is very bad:

If the fluctuation of the currency price is unfavorable to the counterparty (liquidity provider), he may rationally choose not to execute;

In order to complete a cross-chain swap, both the user and the counterparty must perform two signatures.

As a result, hash timelocks, as a cross-chain solution, have largely been phased out. **The early cross-chain bridges that used this solution (e.g., cBridge, Connext) have all changed course.

On-chain light client

This method is to deploy the light client contract of the source chain directly on the target chain. If you deploy a contract on a chain, then all nodes of that chain will run the contract code you deployed. Therefore, the on-chain light client solution is actually to let the target chain directly verify the transaction from the source chain.

This method is extremely secure, but it is also the most expensive. Expensive in the following ways:**

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 is very gas-intensive, even if ZK is used to achieve concise proofs, the gas consumption of verifying a ZK proof will not be less than 400,000 Gas (EVM for example), and in the MPC scheme, the chain only needs to verify a signature, and the Gas consumption is only more than 20,000, which is 20 times worse!A more secure, but 20 times more expensive bridge, will you use it?

The amount of work involved in developing light client contracts is huge, and in order for cross-chain bridges to be compatible with more heterogeneous chains, you need to implement light client contracts for each other chain in completely different development environments on different chains, which is a hellish challenge for developers. This leads to a greater probability of bugs in contract writing, that is to say, the security of the light client bridge is only at the theoretical level, and it is very unsafe in terms of engineering practice. **

In order to reduce the amount of development work, a feasible solution is to introduce a relay chain, so that all chains and this relay chain can establish light client contracts with each other, which can indeed reduce the workload of C(n,2) to n, but it is still not too small. What was originally a direct cross-chain transfer from the source chain to the destination chain has also become a second-order transmission between the source chain → the relay chain → the destination chain, which will generate additional gas consumption and time consumption.

Therefore, the technical solutions of light clients, at present, cannot be used to build more universal cross-chain bridges.

End Game****

First of all, different public chains have different practices, and there are different resources behind them, as long as they do not admit defeat, the ecology will definitely exist, even if the development is not very good in the short term, maybe one day they will come back to life after making an upgrade. The thing like this kind of underlying infra is to see who lasts a long time and who adjusts quickly to the market. **

Bitcoin and Ethereum can’t solve all application scenarios, or in a certain subdivision, there are always people who don’t like the first place, so they create a new wheel, so the future will definitely be multi-chain. Or in the future, the bottom layer will not be a chain, then the future must be multi-ecological, how to transmit funds and information between multiple ecosystems, there must be cross-chain/cross-ecological technology!

What do users pay most attention to in the matter of cross-chain?

Speed: How long it takes for a cross-chain operation to complete

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

Security: Whether the cross-chain bridge is secure and whether funds will not be lost

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

Connection range: How many chains do you support, and whether you support the chains I need for my cross-chain operation

Experience: Whether the cross-chain operation is convenient, such as whether it supports gas payment, whether the cost estimation is accurate, whether it supports progress query and browser viewing, whether failures occur frequently, how to deal with failures, etc.

**Let’s first give an overview of the features of some projects from three clear perspectives: security, cost, and connection range. **

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

In order to fully explain the cross-chain bridge, there are actually many dimensions that need to be discussed, such as all the dimensions and data analysis in the table above. So what elements do you care about when cross-chaining?What are the cross-chain bridges you often use?What do you think cross-chain bridges should focus on?If you have your ideas, welcome to communicate with the authors.