Written by: NIC Lin
This article will introduce what cross-chain bridges are, classify and compare cross-chain bridges, and analyze some famous cross-chain bridge attacks.
What is a cross-chain bridge
A cross-chain bridge is a bridge responsible for transmitting "messages" between different chains. As for what kind of messages it is, we will introduce it next. Examples of cross-chain bridges include Multichain, Celer, LayerZero, Nomad, Hop, etc.
Chains are unaware of each other's existence
Most of the familiar cross-chain bridge usage scenarios involve cross-chain assets such as ETH and BTC. But in fact, "assets" cannot cross chains. This is because each chain is independent and they will not know each other's existence and status.
As for where the ETH on Solana or the BTC on ETH come from? Those are minted by cross-chain bridges. As long as these cross-chain bridges are safe, these minted coins are safe.
Note: Others, such as USDT or USDC, are minted by Tether and Circle on different chains, while the rest are minted by cross-chain bridges.
What "message" is being sent?
Although on the surface, assets are crossing the chain, behind the scenes, it is actually just "messages" crossing the chain. These messages are like "I locked/burned asset .
For example, when Alice wants to "transfer" USDT from chain A to chain B through a cross-chain bridge, what actually happens behind the scenes is:
The cross-chain bridge's contract on chain A transfers USDT from Alice and sends a message: "Alice locked 10 USDT with me."
The message is brought to the cross-chain bridge's contract on chain B, and the contract transfers 10 USDT from itself to Alice's address on chain B.
Asset cross-chain is actually a simple message transfer, with many details omitted.
The transmission of "messages" is the core of cross-chain bridges. Nowadays, the most common cross-chain assets are just one of the uses. For example, the V3 version of Aave is a mortgage lending platform running on multiple networks.
Limitations and Challenges
But the cross-chain bridge is not as simple as the above example. One of the most fundamental limitations of cross-chain bridges comes from the fact that "chains don't know each other exists", so it needs to " trust someone to deliver the message ." Therefore, the main challenge of the cross-chain bridge is " how to verify the validity of a sent message ."
Note: "Believing" the messenger here does not mean completely trusting the messenger. Later paragraphs will introduce some bridges that do not require trusting the messenger. The deliverer may be a good or bad person, but there will be some other assumptions about the traits of the deliverer(s).
safety
Basically the security of a cross-chain bridge depends on:
How much trust do you need to put in the messenger? Are there any assumptions about the behavior of the message sender? Is it assumed that the messenger can only perform his job honestly?
How to verify the validity of the message?
Next, the classification of different cross-chain bridges will be introduced.
Classification of cross-chain bridges
Cross-chain bridges can basically be divided into four types:
Trusted Relayers
Optimistic Verification
Light client + Trustless relayers
HTLC
(If you have other ideas or comments about the classification, please leave a message or write a letter for discussion.)
1. Trusted Relayers
As the name suggests, Trusted Relayers are trust message messengers . Basically, after trusting the messenger, there is no need to verify the validity of the message. As long as the message is brought by the trusted messenger, it is believed to be valid. Naturally, when there are assumptions of trust and centralization, the architecture will be much simpler, the cost will be very low, and the user experience will be great.
There is nothing special or bright about the technology of Trusted Relayers. It just depends on the composition of these message transmitters, which can be single or multiple (just like multi-signature); behind each message transmitter, there can also be multi-signature or MPC.
One thing that must be mentioned here is that the security assumption of Trusted Relayers is Honest Majority, that is, more than half of the message senders must be honest and good people. If more than half of the message senders are bad guys or hacked, the cross-chain bridge is no longer safe.
Another thing to mention is that Layer Zero also belongs to Trusted Relayers. Even if the role of the message transmitter is divided into "Oracle" and "Relayer" in their definition, it still does not change that the security of the entire bridge cannot rely on these two roles. Is a bad person. However, the advantage of Layer Zero compared to other Trusted Relayers bridges is that each dApp can customize the security it needs. If you need security very much, you can set the number of "Oracles" and "Relayers" very high. Another advantage is that the security of each dApp is independent of each other and does not affect each other.
Examples: Multichain, Celer, LayerZero, Wormhole, Ronin Bridge, XY
2. Optimistic Verification
Like Optimistic Rollup, Optimistic first accepts the message delivered optimistically, but will verify the validity of the message and initiate a challenge if it is found to be invalid . The advantage is that the system will operate normally most of the time (because evildoers will be challenged and punished), and the messages are valid so there is no need to initiate a challenge, so the cost is very low because there is no need to verify the message on the chain. The disadvantage is that there must be a challenge period (Optimistic Window) to allow the person responsible for verification enough time to verify and initiate a challenge. Next, we will take Nomad as an example to introduce the operation of Optimistic Verification.
There are three roles in Nomad: Updater, Relayer and Watcher.
Updater pledges collateral and is responsible for guaranteeing the message signature, for example, "I swear by my collateral that Alice applies to send XXX message from chain A to chain B."
Relayer is simply responsible for sending the message and Updater's signature to the target chain (Chain B)
Watcher is responsible for supervising Updater and reacting when Updater does evil.
normal circumstances
Alice triggers the chain A contract and requests to send a message to chain B
Updater signs Alice's message
Relayer is responsible for sending the message and Updater signature to chain B
After the challenge period (Optimistic Window) ends, the message will take effect and the message cross-chain will be completed.
Updater do evil
Updater signs a fabricated message and asks Relayer partners to send it to chain B
After Watcher discovers it, it first goes to chain B to invalidate the message, and then sends the evidence (Updater signature) to chain A, confiscating the Updater collateral.
The contract of chain A can clearly verify whether the message signed by the Updater exists, because the message will really exist only if the user personally sends the request to the contract. Therefore, when an Updater signs a message that does not exist, this signature will become indefensible evidence for the evil Updater and be used to confiscate the Updater's collateral.
The evidence is only valid in the message source chain (chain A)
The target chain (chain B) will never know who on chain A wants to send what message, so the chain B contract has no way of knowing whether the message guaranteed by the Updater is true.
What can chain B do? The answer is that Permissioned Watcher needs to be introduced. Permissioned Watcher has the right to invalidate any message to prevent any damage caused by forged messages. But on the contrary, it can also invalidate a normal message, so this role must be Permissioned, and he needs to be a trusted role.
If there is a Permissioned Watcher messing around and maliciously invalidating normal messages, then you can only rely on another layer of trust, perhaps a Governance or a multi-signature Admin to intervene and eliminate the malicious Watcher.
Just assume that at least one Watcher is doing something
The security assumption of Trusted Relayer is very different. Compared with Trusted Relayer, which needs to assume that there are more than half honest participants, Optimistic Verification only needs to assume that at least one Watcher is a good person . This means that to defeat Optimistic Verification, you need to defeat (e.g. hack, bribe, DoS) all Watchers .
30 minute challenge period
Unlike the Optimistic Rollup challenge period which lasts up to seven days, the Optimistic Verification challenge period is only 30 minutes. This is because the challenge of Optimistic Verification does not require back-and-forth interaction between the challenger and the challenged, but directly submits a one-time life-or-death evidence: "Does the message signed by the Updater exist? (yes/no)".
3. Light client + Trustless relayers
This cross-chain bridge method allows the target chain to become a light node of the source chain. It can run a light node off the chain, or it can simulate a light node using an on-chain contract: each block of the source chain is recorded and verified in the contract. The header file of each block (Block Header). In addition to verifying that the content of the header file is valid, it is also necessary to verify the consensus, that is, the verification of PoW or the voting result of PoS. The verification of PoW is relatively simple, but the voting results of PoS are much more complicated, especially with more than 400,000 Validators like the Ethereum Beacon Chain. The cost of maintaining these lists in terms of contracts or vote counting is very high.
In addition, the block content and consensus mechanism of each chain are different, so it is not a simple task to support a new chain. In addition, the verification cost will be much higher than other cross-chain bridges. These are such cross-chain bridges. main disadvantages. But the advantage is that it is very secure. It does not need to trust the relayer responsible for bringing the block information. It will verify the block and consensus by itself.
The Light Client contract verifies the block information and consensus of chain A brought by the Relayer
Note: Although the Relayer is just running errands, it is still necessary to assume that there is an honest Relayer online to ensure that the correct block information will be brought over to avoid fake forked chains that undermine security.
After verifying the block header file, what is left is to verify that (1) the transaction exists in a certain block, or (2) an event is emitted in a certain block, or (3) a certain address storage is some value. Example:
(1) Such as verifying that Alice transfers funds to a certain address on BTC, or attaching a certain message to OP_RETURN
(2) For example, verify that the Bridge contract on ETH has indeed emitted the CrossChainMessageRequestedevent (the event's receipt will exist in the receipt tree, and the tree root will be recorded in the header file)
(3) For example, verifying that there is indeed a piece of data in the storage of the Bridge contract on Optimism that records the cross-chain request for the message requested by Alice.
Then Alice uses the method (1)(2)(3) to prove to the Light Client contract that she has initiated a cross-chain request.
After the verification is successful, it can be believed that there is indeed a cross-chain message request in the source chain.
Examples: Cosmos IBC, Near Rainbow Bridge
Note: Cosmos IBC transmits messages between different (and limited to) Cosmos chains by running light nodes instead of using contracts. Near Rainbow Bridge can only transfer between Ethereum, Near, and Aurora chains.
In addition to complex construction and high verification costs, this cross-chain bridge also has a disadvantage: the Finality time of each chain is different. For example, data coming from BTC may have to wait six blocks (one hour), and data coming from ETH may have to wait six blocks (one hour). The data may have to wait for 12.8 minutes, etc., and the user experience will be much worse.
4. HTLC
HTLC stands for Hashed TimeLock Contract (hash time lock contract, the following will assume that the reader knows how HTLC operates).
Note: HTLC does not necessarily need to use Hash for commitment, and can use signature instead.
The advantage of HTLC is that it is very secure, but the disadvantage is that the user experience is much worse than other cross-chain bridges, such as:
It takes more transactions to complete the cross-chain
Users must stay online until the cross-chain is completed
Free Option Problem, the person initiating HTLC is the passive party, and the counterparty can choose to cooperate or not (whichever is beneficial to him). However, if the counterparty is a reputable merchant (called Router), you don’t need to worry about this issue so much.
The service quality of different Routers will be different, resulting in inconsistent user experience.
Examples: Connext, Celer V1
The above is an introduction to the four types of cross-chain bridges. Next, we will analyze the attacks that have occurred on each type of cross-chain bridge.
Attack event analysis
1. Trusted Relayers cross-chain bridge attack
1) Multichain, 2021.07, ~8M loss
This randomly generated random value is reused in their MPC suite library, allowing the private key to be restored. Related Links:
https://medium.com/multichainorg/anyswap-multichain-router-v3-exploit-statement-6833f1b7e6fb
2) PolyNetwork, 2021.08, ~600M loss
Smart contract vulnerabilities allow attackers to gain access to protocol assets. Related Links:
https://en.wikipedia.org/wiki/Poly_Network_exploit
https://certik.medium.com/polynetwork-hack-analysis-a86513f2a730
3) Multichain, 2022.01, ~3M loss
Smart contract vulnerabilities allow attackers to transfer the victim's wrapped tokens (such as WETH, WBNB, etc.) at will. Related Links:
https://medium.com/multichainorg/action-required-critical-vulnerability-for-six-tokens-6b3cbd22bfc0
https://halborn.com/explained-the-multichain-hack-january-2022/
4) Qubit, 2022.01, ~80M loss
Smart contract vulnerabilities and negligence in the contract upgrade process allow attackers to directly withdraw all assets in the protocol. Related Links:
https://certik.medium.com/qubit-bridge-collapse-exploited-to-the-tune-of-80-million-a7ab9068e1a0
5) Wormhole, 2022.02, ~300M loss
Smart contract vulnerabilities allow attackers to bypass permission checks and mint new tokens indefinitely. Related Links:
https://wormholecrypto.medium.com/wormhole-incident-report-02-02-22-ad9b8f21eec6
6) Ronin Bridge, 2022.03, ~600M loss
The nodes of multi-signature members (five out of nine) were compromised. Related Links:
https://www.theverge.com/2022/7/6/23196713/axie-infinity-ronin-blockchain-hack-phishing-linkedin-job-offer
7) Horizon Bridge, 2022.06, ~100M loss
The private keys of the multisig members (two out of five) were stolen. Related Links:
https://halborn.com/explained-the-harmony-horizon-bridge-hack/
2. Optimistic Verification cross-chain bridge attack incident
Nomad, 2022.08, ~190M loss
Smart contract vulnerabilities and negligence in the contract upgrade process allow anyone to forge cross-chain messages to transfer assets. Related Links:
https://www.coinbase.com/blog/nomad-bridge-incident-analysis
3. Light Client + Trustless Relayers cross-chain bridge attack incident
Near Rainbow Bridge, 2022.05 & 2022.08, no fund lost
Two attempts to forge cross-chain messages were blocked by the watchdog service. Related Links:
https://decrypt.co/108015/nears-rainbow-bridge-blocks-another-attack-costing-hackers-5-ethereum
4. HTLC has no attacks
In fact, it can be seen that the attacks all occurred due to Trusted Relayers node security management issues and contract problems. There were no successful attacks on Optimistic Verification, Light Client or the HTLC cross-chain bridge protocol itself.
Comparison of cross-chain bridges
Next is a comparison of different cross-chain bridge technologies in terms of "Cost", "User Experience (UX)" and "Security". The following will be presented directly in pictures
1. Cost
Trusted Relayers: The lowest cost, because no complicated verification is required, and the information brought by Relayer is directly trusted.
Optimistic Verification: Only need to verify Merkle Proof
Light Client: To verify the most things, including consensus, block header files and proof of transactions or status
HTLC: The verification is very simple, but it will require multiple transactions (Lock/Unlock) to complete.
2. User experience (UX)
Trusted Relayers: The best experience. Relayer moves across chains as quickly as possible, and users don’t need to do anything.
Optimistic Verification: You need to wait for the challenge period (Optimistic Window), and you may encounter Updater offline or Watcher spoof
Light Client: You need to wait for Finality, different chains will have different experiences, and there are few supported chains.
HTLC: Multiple transactions (Lock/Unlock) are required to complete, users need to stay online, and Routers’ service quality is inconsistent.
3. Security
Trusted Relayers: The lowest security, requiring the assumption that most multi-signature members are honest, or a small number of members being knocked offline by DoS will also cause service shutdown.
Optimistic Verification: It is only necessary to assume that at least one Watcher is honest, but if the Updater is offline due to DoS, it will still cause the service to stop.
Light Client: Very safe, you must be able to attack the consensus of those chains to cause harm.
HTLC: The safest, the hash function must be broken before it can cause harm
The difference between Rollup Bridge and cross-chain bridge
Rollup Bridge refers to the native bridge between Rollup and its L1. Because messages can be transmitted directly between L1 and Rollup, and the validity of the message is guaranteed by zero-knowledge proof or fraud proof, it is better than the relationship between L1 and L1. The cross-chain bridge between them is much safer.
However, there will be some delays in the Rollup native bridge: ZK Rollup needs to wait for the zero-knowledge proof to be generated and uploaded to the chain, and Optimistic Rollup needs to wait for the end of the challenge period.
Note: The delay mainly occurs in Rollup -> L1 messages, and L1 -> Rollup messages are very fast.
If you don't want to wait, you can use the services provided by a third party: you use the native bridge to transfer money to the third party. The third party advances the money to you at L1 first, and then slowly waits for the money to come through the native bridge. For more information about Rollup Bridge, please refer to imToken's series of articles "Introduction to Rollup Bridge (1): Maker DAI Bridge":
https://medium.com/imtoken/rollup-bridge-%E4%BB%8B%E7%B4%B9-%E4%B8%80-maker-dai-bridge-678c62228eb5
The security requirements for using cross-chains are different from providing liquidity
If you simply use cross-chain services, such as transferring money from chain A to chain B, you don’t need to worry too much. Even if the bridge is hacked, as long as the bridge still has residual liquidity or there is new liquidity injected later, you can The cross-chain request will definitely be completed.
But if you want to provide liquidity to a cross-chain bridge to earn cross-chain handling fees, you should choose the cross-chain bridge carefully. If the amount stolen is too large and the project party cannot compensate, then you will definitely lose money. You can choose a cross-chain bridge with additional security mechanisms. For example, Celer and XY both set a limit for cross-chain transfers (for example, the maximum accumulated transfer can only be 100M in a single time or within a period of time).
In fact, just like using AMM, providing liquidity will definitely bear greater risks than simple swap.
Recent new technologies or developments
1) ZK Light Client Bridge
As mentioned earlier, although the Light Client cross-chain bridge is safe, it is very costly. The good news is that zero-knowledge proof can effectively reduce this cost. But it should be noted that zero-knowledge proof can only improve efficiency, but not security. Moreover, zero-knowledge proof is more complicated, and it will take a long time until ZK Light Client supports enough chains.
There are two new projects implementing ZK Light Client:
Succinct Labs
https://blog.succinct.xyz/post/2022/09/20/proof-of-consensus
zkBridge
https://twitter.com/dawnsongtweets/status/1574775694139314176
2) The cross-chain world is still an untapped MEV treasure land.
Cross-chain transactions create more MEV opportunities than single-chain transfers
If cross-chain transactions are combined with DEX to do swap, there will be more MEV opportunities.
For more information, please refer to the speech and slides given by the founder of Nomad at MEV Day at ETHamsterdam. He concluded that cross-chain DEX cannot be implemented because the price will be uncompetitive due to the impact of more MEV opportunities. To use cross-chain DEX, it is better to simply cross-chain the assets first and then go to DEX swap yourself.
Original link:
https://medium.com/taipei-ethereum-meetup/%E8%B7%A8%E9%8F%88%E6%A9%8B%E6%AF%94%E8%BC%83-4327192f7200
**This article only represents the views of the original author and does not constitute any investment opinions or recommendations.
-END-
[The purpose of publishing articles is to disseminate more valuable information. The copyright of the article belongs to the original author. Its content and opinions do not represent the position of Unitimes. The pictures appearing on this WeChat platform are all collected from the Internet, and the copyright belongs to the copyright owner. If the copyright owner believes that his work is not suitable for everyone to browse or should not be used for free, please add WeChat uniforms2018 to contact us, and this platform will make corrections immediately. 】
Just click " Like " when you come.
