Demystifying Cross-chain Bridge - Coucou

Author: Tommywong.eth, Chasey, 菠菜菠菜

Overview 👀

01/ Why Cross-chain is Needed

02/ Five Stages of Cross-chain Development

03/ Three Main Operation Principles of Cross-chain Bridges

04/ Three Types of Verification Mechanisms

05/ Mainstream Analysis Dimensions of Cross-Chain Bridges

06/ Security Analysis of Cross-Chain Bridges

07/ Third Party Cross-Chain Bridge Representative Projects

08/ Hacking Incidents Analysis

09/ Summary and Outlook

Why Cross-chain is Needed

The existence of cross-chain bridges is based on the core assumption of a future multi-chain ecological landscape under which the flow of assets and information across different blockchains facilitated by cross-chain bridges would be instrumental.

Due to the design of Ethereum Network, applications and protocols built on it inevitably compete for the underlying resources and restrict the performance of each other, resulting in high gas fees and the slow transaction speed. As Ethereum 2.0 still needs some time to complete development and launch, it allowed for a window for several “Ethereum killers” public chains, such as Avalanche and Solana, to attract funds/build up their ecosystem in 2021. While the multi-chain ecosystem’s taking off and sharing the pressure on Ethereum to some extent, it is actually also eroding its leadership.

Although the return of the relatively reasonable gas fees and transaction speed of Ethererum Network under the bear market has weakened the momentum of capital outflows, according to the July data from Defi Llama, which counted the market share of each public chain in terms of TVL lockups, Ethererum (in blue) dropped from 98% market share at the beginning of 2021 to 62% in July 2022. Although its market share rebounded from a low of 55% to 64% in May due to Terra's meltdown, Ethereum’s market share is still gradually declining. In the short term, it seems that the multi-chain ecosystem is still an irreversible trend. Among all the chains, Tron is worth further attention as it was able to grab the market share in the bear market with the JustLend protocol.

In the medium to long term, where users flow to is closely linked to the overall quality of each blockchain ecosystem. Ultimately, users will vote with their capital to make the competition between chains relatively balanced. It is not simply the number of projects that determines the prosperity of the multi-chain ecology, but the users’ activeness and the sustainability of funding need to be considered comprehensively.

Market share of each public chain (by TVL) - from Defi Llama

The Five Stages of Cross-chain Development

Composable Finance proposes the five stages of the cross-chain interoperability development:

0-20%: Realize minimal cross-chain communication and inter-chain token movement.
20-50%: Enable users to provide liquidity to assets on different chains, thereby maximizing revenue.
50-75%: Enable the communication between applications of different chains. For example, projects like Aave enable users to deposit collateral on one chain while borrowing a loan on another.
75%: Enable applications to deploy different parts on different chains so that each part runs on the most efficient chain. Backend packages from these different chains will communicate with each other to ensure continuity of user experience.
100%：Ecosystem agnosticism - Able to provide a wide range of interfaces to Web3 ecosystems. Traditional developers will be able to arbitrarily deploy applications powered by web3 tools on chains without complex blockchain programming, with all complexity gotten rid of through abstraction.

Three main operation mechanisms of cross-chain bridges

Atomic swaps

When User A has a cross-chain demand, the cross-chain bridge will match/seek another User B’s corresponding opposite need on the target chain, so that the two sides can have peer-to-peer matching and asset exchange through Hash Time Lock Contract (HTLC) with their funds‘ security guaranteed.

The following is an example of exchanging 1 BTC of User A’ s with 20 ETH of User B’ s. Specific steps are illustrated as below:

User A generates a random password r, calculates the has value m = hash(r) of r and sends the m value to User B.
User A initiates a conditional transaction, transferring 1 BTC to User B. Only when User B presents the password r at the preset time will the transaction succeed, otherwise, the transaction automatically fails.
User B initiates a conditional transaction, transferring 20 ETH to User A. User A must present the password r at the preset time in order for the transaction to succeed, otherwise, the transaction will automatically fail. (It is not necessary for User B to get the value of password r to create such a transaction that is conditional on the presentation of r value; B only needs to know the value of m to create it. The hash operation is irreversible; knowing m does not lead to the derivation of r.)
A presents the password r to receive 20 ETH, while B gets the password r to get 1 BTC.

Pros:

The use of hash time lock mechanism makes it impossible for funds to get stolen, resulting in high level of security.
No need for universal consensus and external verification nodes.
Relatively fast speed for cross-chain transactions

Cons:

The scope of application is relatively limited: it cannot support generic data transfer between chains, and its statefulness is poor.
The cost is relatively high: each cross-chain transaction may need to deploy a “hash time lock” smart contract.
Both sides of the transaction must be online same time: there will be a long waiting time if the counterparty cannot be found at the moment.
Not suitable for large transactions - it may not be able to find a counter-party to provide sufficient liquidity.

Lock + Mint / Burn

The cross-chain bridge locks the user’s assets in the original chain, mint/destroy an equal amount of composite tokens on the target chain and transfer them to/from the user’s account on the target chain, thus completing the cross-chain transfer. A typical example would be Wrapped Bitcoin(wBTC) on the Ethereum Network.

Pros:

No requirements for liquidity.

Cons:

Asset security relies on network validation nodes. Should validation nodes become malicious or controlled by hackers, serious financial loss can happen.
Wrapped assets are inherently different from native assets, with the assets being illiquid and having the potential for a price collapse.

Liquidity pool

Cross-chain bridge deploys smart contracts of the source chain on the target chain and transfers the target chain into a side chain of the source chain to communicate information between the two sides. The project owner will establish liquidity pools on different chains, through which users can, on one hand, directly exchange the native assets of the other chains; and on the other hand, by providing liquidity for the tokens and becoming liquidity providers, they can also earn a portion of the cross-chain transfer fees or APY(The annual percentage yield) revenue.

Pros:

A unified liquidity pool providing users with native assets can reduce the potential risk faced by users receiving wrapped assets.
It bypasses the efficiency issues of the “lock-in & mint” mechanism and improves cross-chain speed.
It enables co-creating liquidity pools with users, expanding the possible variety of cross-chain cryptocurrencies.

Cons:

Security Relies on smart contracts deployed by project owners on different blockchains, with potential vulnerabilities in the contracts
Some liquidity pools may lack depth, resulting in considerable price differences in different liquidity pools.

Three Types of Verification Mechanisms

Each blockchain has its own communication protocol, consensus rules, governance model, and native assets. The core of cross-chain lies in reaching consensus, allowing one blockchain to access the state of another blockchain, and to promote the flow of information and assets between blockchains. Nowadays, there are three main validation mechanisms, namely external verification, local verification, and native verification

External Verification

It relies on a single/multi-point external verifier(s) to reach consensus and sign off on the transaction.

The signing methods are typically multi-sig and multi-party computation (MPC). The multi-sig mechanism requires the verifiers to have a complete private key to sign the transaction. Multi-party computing eliminates the concept of a single private key and requires the verifiers to jointly form a private key to complete the transaction verification.

To ensure the security of the users' assets, some cross-chain bridges require a pledge from the verifier to run the node to provide services for transaction verification. There are two types of pledge models, insured and bonded, between which insured cross-chain bridges are more secure for users, as the funds pledged by the verifier will be compensated to the users if the node commits fraud. While for the bonded cross-chain bridge, for the same scenario, funds pledged by the verifier will only be destroyed, rendering less guarantee for the users’ fund.

External verification has security concerns, which requires users to have confidence in the project owner, and the external verifier not being evil. In June 2022, Harmony Horizon Bridge was hacked to steal $100 million, primarily because the hackers stole the private keys of 2 of the multi-signature participants and used the stolen private keys to complete the signatures and create the transactions that withdrew $100 million.

Local Verification

On the relevant blockchains, only the parties involved in the cross-chain behavior are involved in verification. Local verification turns the complex multi-party verification into two-party verification where both parties verify each other's transactions.

Native Verification

The underlying verifiers of the target chain and the source chain are responsible for verification. The cross-chain bridge deploys a light node smart contract of the source chain on the target chain to transform the target chain into the side chain of the source chain and realize the information flow between both sides. The Relayer transmits the information from the source chain to the light client of the target chain, and the native validation node will verify the correctness of the information and trigger the corresponding smart contract.

The recently discussed Layer Zero projects introduced Ultra light node and Oracle on top of the native verification, in which the Oracle and Relayer work independently to improve the security and reduce the cost of the whole system.

When a user wants to send a message from blockchain A to blockchain B, the message is sent from the terminal of blockchain A, notifying the user program's oracle (Block ID and the smart contract identifier of blockchain B), and the relayer (which notifies the full message). The oracle forwards the block header to the terminal of blockchain B. The relayer then submits the proof of transaction. After the proof of transaction is verified on the blockchain B, the message is forwarded to the destination address. The user finally acquires the native assets on the destination chain through the liquidity aggregator pool built by Stargate Finance.

Block headers are forwarded on demand by a decentralized oracle instead of being kept in whole to reduce costs.

The oracle and the relayer work independently, and the oracle uses an independent third-party provider, Chainlink, which increases the difficulty and cost of hacking it. Even if the oracle is hacked, there is still a relayer to verify it, which increases the security level.

Mainstream Analysis Dimensions of Cross-Chain Bridge

In line with blockchains, cross-chain bridges are also limited by the classic “impossible triangle”: security, interoperability, and decentralization. The current cross-chain bridges make trade-offs in different performance dimensions to solve their respective user pain points. The current mainstream analysis of cross-chain bridges examines the below dimensions. The following definition is from Zonff Partners, Lewis.

Security: Trust and validity assumptions, tolerance of malicious actors, security of user funds and reflexivity.
Speed: Delays in completing transactions, and finality guarantees. Usually a trade-off between speed and security.
Connectivity: Choose target chains for users and developers, as well as the different difficulty levels of integrating target chains. Good connectivity means high compatibility with public chains, not easily limited by differences in consensus algorithms and data structures of different public chains
Capital efficiency: Capital required for system security, transaction costs for transferring assets
Statefulness: Ability to transfer specific assets, more complex state, and/or perform cross-chain contract calls

Security Analysis of Cross-Chain Bridge

Among the various dimensions, security is the most important. Cross-chain bridge security vulnerabilities have resulted in the theft of billions of dollars in assets, as detailed in Section 4 of this article. The main vulnerabilities lie in the smart contract, followed by the use of multi-signature technology when adopting external validation technology where hackers have access to more than half of the validation nodes and their private keys. The overall project owner needs to audit the smart contract and improve the technology to ensure the security of the smart contract.

The overall design of the cross-chain bridge has the following security ranking:

Security decreases from native verification, local verification, multipoint verification to single-point validation.
In multipoint verification, bridges that require pledges from external verifiers are more secure than bridges without pledges. Among cross-chain bridges that require pledges, those that are Insured are more secure for the user than those that are Bonded. When a node commits fraud, the funds pledged by the verifiers will be compensated to the users.
Receiving native assets is safer/less risky than encapsulated synthetic tokens when assets are cross-chained.

For example, Wormhole's cross-chain bridge applies the approach of lock-in + mint/burn. Users' locking of assets on the original chain is equivalent to collateralizing for the new on-chain wrapped asset, but if the original chain asset is stolen, then the user's new on-chain wrapped asset may lose its value.

In addition, although Insured's cross-chain bridge releases the funds pledged by the malicious verifier to the user as compensation, if the security of the cross-chain bridge is at risk, the pledged tokens, which generally are the bridge’s native tokens, would have a sharp drop in its price that still brings significant impact on the users.

In the actual cross-chain operation, it is better to choose a different cross-chain strategy according to the size of your capital. For large sum of capital, out of security concerns, it is advisable to exchange to the native assets of the corresponding chain on Binance or OKCoin exchanges, and then withdraw to swap on the target chain to the target coins.

For cross-chain needs with small capital volumes, consider a cross-chain bridge with lower Gas fees, faster speeds, and no previous risks for transactions. The cross-chain aggregator can assist users in filtering out the optimal cross-chain path at the minimal cost for service.

Third Party Cross-Chain Bridge Representative Projects

(Data are collected from Defi Llama in July 2022.)

Multichain

Introduction: The bridge is currently with the deepest liquidity pool and the largest number of supported blockchains

Consensus mechanism: Multi-point external verification mode, verified by a multi-party computing system (MPC) with threshold signature

Cross-chain model: Non-target chain native tokens → source chain lock in, target chain mint/burn; native tokens → liquidity swap (liquidity pool deployed on multiple chains in V3 version)

Security: Need to fully trust the external verifier(s), currently 30+ nodes; no pledge mechanism introduced, medium-level security

Speed: <30min

Cost: Source Chain Gas fee +0.3% processing fee

Scalability: Scalable, currently supports 36 blockchains, can apply to the project owner for NFT cross-chain contract deployment

CBrigde

Introduction: CBridge 1.0 uses peer-to-peer transactions with atomic swap, which ensures security while causing gaps in liquidity, resulting in its poor scalability; after upgrading to 2.0, it switched to liquidity swap mode to improve scalability.

Consensus mechanism: Multi-point verification mode, verification conducted by nodes of the sidechain Celer State Guard Network (SGN)

Cross-chain model: Liquidity swap

Security: need to fully trust the verification nodes; SGN uses DPoS verification; currently relatively secure with a large number of pledges

Speed: <20min

Fees: Source chain Gas fee +0.04% processing fee; when the source chain is L2Rollup source chain, the processing fee is increased to 0.1%~0.5%

Scalability: Scalability becomes stronger after upgrade; currently supports 20 blockchains

Hop Protocol

Introduction: Sacrifices the asset security of liquidity providers, validation nodes and arbitrageurs to safeguard users' assets; also allows users to pay more fees to incentivize several other roles.

Consensus Mechanism: Multi-point verification model is adopted, with whitelist node Bonder pledging assets and then participating in verification transactions.

Cross-chain model: Liquidity swap.

Security: Rollup technology is used, security depends on the underlying chain, no need to trust anyone, so it is safer.

Speed: <5 min.

Cost: Gas on source and target chains + liquidity provider fees + 0.06% to 0.25% verification node fees

**Scalabity:**Most scalable on EVM compatible chains; Currently only supports Layer-2 Rollups.

Connext Bridge

Introduction: Based on NXTP liquidity protocol, cross-chain smart contracts have been implemented.

Consensus Mechanism: Using multi-point verification mode, verification completed based on NXTP protocol.

Cross-chain model: Atomic swap

Security: peer-to-peer transactions, NXTP sets up an internal verification architecture, no need to trust anyone, extremely secure

Speed: <5min

Cost: Gas+0.05% processing fee

Scalability: NXTP protocol architecture is scalable, currently supports 16 blockchains and supports smart contract calls across chains

Stargate

Introduction: LayerZero-based bridge for liquidity sharing across blockchains.

Consensus mechanism: LayerZero ultra-light node native verification.

Cross-chain model: Liquidity pool

Security: Triple guarantee from setting up oracle, relayer and target chain UA, strong security.

Speed: <1 min.

Cost: Gas+about 0.2% processing fee.

Scalability: according to the official description, scalability is strong, currently supports 7 blockchains, only supports stable coins.

Barter Bridge x MAP Protocol

Expected to launch in September 2022.

Introduction: Cross-chain bridge based on the underlying cross-chain infrastructure MAP Protocol

Consensus Mechanism: MAP Protocol Light Node + Relay Chain Native Verification

Cross-chain model: Liquidity pool

Security: Blockchain level security through light node smart contracts deployment on different chains

Speed: < 1min, depending on the block generation time of the target and source chains

Fee: Source Chain Gas + approx. 0.2% processing fee

Scalability: Can cover target chains that support smart contracts

Disadvantages: demanding development work in the early stage, requiring light node smart contract development based on the different structures of different chains

Source

Lee - Co-founder of Barter Network

MAP Protocol core developer

Note: The expected September launch of the underlying cross-chain infrastructure MAP Protocol's cross-chain bridge focuses on solving the impossible triangle of cross-chain bridges, if you want more details, please pay attention to BuidlerDAO research report updates.

Hacking Incident Analysis

Among the dimensions, security is the most important. Security vulnerabilities in cross-chain bridges have caused the theft of billions of dollars of assets. They mainly exist in smart contracts, followed by the ones when using the multi-signature technology for external verification where hackers manage to obtain more than half of the verification nodes and their private keys.

We will use the existent representative cross-bridge hacks as examples to analyze how hackers exploit contract vulnerabilities. Project owners need to conduct audits on smart contracts, improve their technology and risk control, as well as open source the contract code to ensure the security of smart contracts.

Poly Network

Time: 2021/8

Amount: $610m

Background：

EthCrossChainData contract manages a list of public keys taht are used to validate the on-chain data of the counter-party chain.
EthCrossChainManager is a privileged contract which has the right to send orders commands to contracts on other chains.
Anyone can call the verifyHeaderAndExecuteTx function to initiate a cross-chain transaction.
any contract can be called using the _executeCrossChainTx function.

Process: The hacker called the EthCrossChainData contract using EthCrossChainManager and used hash collisions to find the sighash (used to call the target function), replaced the private key with his own, and transferred the coins away from the contract.

The main problem: Poly Network has no mechanism in place to prevent calls to the EthCrossChainData contract.

Ronin Network

Time: March 2022

Amount: $600m

Background: There are 9 verified nodes in the Ronin chain

Process: Hackers controlled 5 nodes and transferred the locked ETH away from the vault

Main problem: 51% attack due to centralized management

Wormhole

Time: February 2022

Amount: $320m

Background:

Guardians is part of Wormhole's contract on the Solana Network and is responsible for signing transactions
When a cross-chain request is received, the Solana Network will call the post_vaa function, and the post_vaa function will call the verify_signatures function
The verify_signatures function asks Guardians for the signature set and calls the secp256k1 program to verify the transaction
The secp256k1 program is executed using Solana's built-in function load_instruction_at, but before Wormhole deploys the contract, Solana replaces the load_instruction_at function with load_instruction_at_checked

Process: The hacker created a program with the same instruction set as Sysvar, to which load_instruction_at belongs, and used it to verify the signature, disguising himself as a system account, thus circumventing Guardians' verification and minting ETH on the Ethereum Network.

Main problem: Failure to verify the validity of the load_instruction_at function in a timely manner

Harmony Horizon Bridge

Time: June 2022

Amount：$100m

Background

Horizon uses multi-signature mechanism consisting of 5 addresses to verify transactions
As long as 2 or more of the 5 addresses complete the signature, the transaction will be executed

Process: Hackers stole the private keys of 2 of the multi-signature participants, created a transaction to withdraw $100 million, and completed the signature with the stolen private keys.

Main problem: 51% attack due to centralized management

Chainswap

Time: July 2021

Amount: $8m

When user submits Deposit request, he/she will get multiple node signatures.
When calling the _receive function for Withdraw in the target chain, only one signature is required.
Calling the receive function consumes the signer quota authQuota.
To enhance decentralization, the signer quota is automatically increased after it is exhausted.

Process: The hacker uses the _receive function to transfer the tokens to his own address and signs it with the generated extra signature.

Main problem: The contract regarding the number of signatures of nodes is not properly initialized and there is no mechanism to check the validity of signatures.

Multichain

Time: July 2021

Amount: $7.8m

Background

AnySwap Multichain Router V3 uses a non-custodial cross-chain model with a secure multi-party computing system (MPC) to verify transactions
ECDSA is a non-deterministic digital signature algorithm, which introduces a random number k and calculates the R-value from k
When two signatures have the same R-value, ~~then~~ the corresponding random number k can be derived by collision

Process: The hackers found that AnySwap Multichain Router V3 has two transactions with the same R-value signature under the MPC account on the BSC chain. They then derived the private key of the MPC account reversely.

Main problem: Vulnerability in the design of MPC

Meter Bridge

Time: February 2022

Amount：$4.3m

Background

Meter has two deposit channels, the underlying deposit function of ETH20 and depositEth
When depositing the native wrapped cryptocurrency on the chain, Meter will not destroy/lock the wrapped cryptocurrency, but will un-wrap it and give it to the relevant contract
When the depositEth function is called to make a deposit, the contract verifies if ~~that~~ the value of the cryptocurrency matches the amount in the calldata and passes the valueit to the deposit function
When the underlying deposit function of ETH20 is used, whether the amount is correct won’t be verified

Process: The hacker retrieved the underlying deposit function of ETH20, filled in the calldata with a number that did not match the value of the cryptocurrency and sent it to the deposit function

Main problem: Lack of validation of the calldata

Summary and Outlook

Summary

Overall at this stage, the cross-chain bridge needs to be further improved due to potential security issues, so that users will be able to have more confidence about the security of their assets when using cross-chain bridges. From the users' point of view, in addition to security, they also need smoother cross-chain experience, including one-click cross-chain, convenient cross-chain speed, direct native assets swaps, etc. Multi-chain ecology is an irreversible trend for in the future; with cross-chain bridges as the underlying fundamental infrastructure of it, we look forward to the further development of the cross-chain bridges.

Outlook

If solely focusing on providing cross-chain asset swaps, cross-chain bridges projects will likely have a low ceiling. Seeing from the current competition landscape, few of the top 100 projects are only doing cross-chain bridges. It is important for cross-chain bridges to expand its future boundary into spaces such as information cross-chain and NFT cross-chain.

Liquidity pool will become the main asset cross-chain approach for cross-chain bridges. Deploying liquidity pools on each blockchain to provide common assets of the target chain bypasses the lock-in minting mechanism and improves cross-chain speed while mitigating the impact of poor liquidity of the wrapped assets.

Other services be embedded in cross-chain bridges, such as cross-chain + Defi, to improve capital utilization. For example, Aave has proposed a cross-chain + lending solution in V3, and Li.Finance is also implementing a cross-chain + trading solution. Furthermore, cross-chain + NFTfi sends NBA TopShot (NFTs) from the Flow Network to Ethereum's NFT borrowing marketplace for collateralized loans.

A single application deploys its different parts on multiple chains, so that each part runs on the most efficient chain. The back-end packages of these different chains will communicate with each other to ensure continuity of user experience. Application such as Gamefi, embed cross-chain functionality into the GameFi to allow senselessly smooth user triage and optimize user experience when traffic is heavy/ congestion occurs.

This article is not related to institutional interests and has no investment advice.

Reference

https://www.panewslab.com/zh_hk/articledetails/q03nee18.html

https://www.defidaonews.com/article/6754150

https://zhuanlan.zhihu.com/p/409342805

https://blog.dodoex.io/跨链漫谈-深度解析16个跨链方案权衡-a4e98d248eb2

https://mp.weixin.qq.com/s/8_KVHvupPKlhnjPFOYUhYg

https://www.defidaonews.com/article/6749182

https://www.coinonpro.com/web3/228616.html

Bridge Documents

cBridge: https://cbridge-docs.celer.network/introduction/sgn-and-cbridge

Stargate: https://stargateprotocol.gitbook.io/stargate/