Ramble on cross-chain: An in-depth analysis of trade-offs for 16…

Ramble on cross-chain: An in-depth analysis of trade-offs for 16 cross-chain schemes

May 25th, 2022

TL; DR

💡 The cross-chain bridge (otherwise known as blockchain bridge) is not a new topic. Still, the articles on the market have comprehensively classified and interpreted the cross-chain bridge from the fundamental elements of the bridge and the cross-chain technology. However, the classification of cross-chain bridges in current papers is dizzying and hinders people from understanding the performance of cross-chain bridges from the macroscopic angle.
💡 Dr. DODO aims to analyze and compare the performance of all aspects of the "bridge" based on the investigation of 16 cross-chain bridges. By comparison, people can intuitively understand the differences between bridges and the problems they are committed to solving, reflecting adof cross-chain bridges. The focus of this article is to compare the performance of the cross-chain bridges rather than to give an in-depth explanation of the cross-chain technology itself. Readers can use the references cited in this article to popularize knowledge of cross-chain technology.

01 Literature review

The emergence of cross-chain bridges
What is a cross-chain bridge?
The classification of cross-chain bridges
The performance of cross-chain bridges

02 Comments on the cross-chain bridges

The product survey forms of cross-chain bridge
Summary/comments on 16 Bridges in this survey

03 Development of cross-chain Bridges

What problems are cross-chain Bridges solving
View of the development of cross-chain bridges

01 Literature review

The emergence of cross-chain Bridges

According to the statistics of Blockchain Comparison, there are 115 public chains in existence. Different blockchains have different communication protocols, consensus rules, and governance models. Haseeb Qureshi, a managing partner of Dragonfly Capital, compares each public chain to a city. No matter how many skyscrapers (Rollups) can stand on Ethereum or how many other cities need to be connected, it makes sense to have a bridge between them. Meanwhile, the flourishing DeFi, NFT, and GameFi on the new public chain encourage users to transfer funds between different public chains, making the cross-chain bridge inevitable.

As a bridge tool between chains, cross-chain bridges enable users to transfer assets and information between chains, promoting communication and compatibility between multichain ecosystems.

According to DeFi Llama, as of March 2022, $21.8M of cryptocurrencies are locked in cross-chain bridges. Wrapped Bitcoin has the largest market share with a TVL of $10.2B, followed by Multichain with a TVL of $7B. Arbitrum is the bridge with the highest TVL in Ethereum ecology, accounting for about $6B, followed by Polygon, accounting for about $5B.

However, the cross-chain bridge has simultaneously become the target of fierce attacks by hackers. On March 23, hackers stole 173,600 Ethereum and 25.5M USDC with over $600M TVL from Ronin Bridge. Ironically, it took six days for the team to discover the significant loss. Then, a significant security breach was discovered in the underlying protocol of LayerZero's hit project Stargate bridge when the stablecoin TVL hit $3.6B.

These incidents are worrying, and not everyone is indeed excited about cross-chain bridges. Vitalik Buterin wrote on Reddit that:

“The future would belong to "multichain." Still, it will not be "cross-chain," because there are fundamental limits to the security of bridges that hop across multiple "zones of a sovereign."

It is worth further discussing how cross-chain bridges will develop in the future and whether there will be a multichain vs. multi-bridge game. However, at this stage, the need for cross-chain exists for three reasons:

Increasing the utilization of assets
Expanding the boundaries of the protocol and the possibility of developing new features
Unlocking more gameplay for users and developers.

Let's look at what a cross-chain bridge is and how it meets these three needs.

What is a cross-chain bridge?

💡 In most cases, when a user wants to transfer an asset from chain A to chain B, the asset needs to be stored in the designated address of the bridge in chain A. Then, when a bridge validator receives this information, an equivalent amount of wrapped token is minted in chain B. Alternatively, by establishing a capital pool in the destination chain, the cross-chain assets can be converted into the underlying assets of the destination chain. Finally, the user received the money in the user's account in chain B.

As described above, a cross-chain bridge is a tool to help users transfer assets between blockchains with two different protocols. The current cross-chain technology involves two various aspects: asset and data cross-chain, but this article will focus on the interpretation of asset cross-chain. Next, let's look at some important roles and steps in the asset cross-chain process:

Validator: Who checks the status of the original and destination chains and is responsible for the transmission of information? It can be a Validator or group of Validators, Relayer/Light-client, or Oracle, as some articles call it.
Consensus mechanism: How to reach consensus among validators? How do they encrypt the signing of assets to transfer to the destination chain? Multi-sig or more secure MPC threshold signature mechanism?
Mechanisms of rewards and punishments: What incentives for the validator to deliver information correctly? Some cross-chain bridges reward the validator with part of the transaction fee or require the validator to stake governance tokens, and cut off the staked assets in the wrong message.
Are users' assets managed on the bridge?: When a user deposits an asset at a specified address in the source chain, the address may be overseen by the bridge's validator or controlled by a smart contract (i.e., without human intervention). In addition, a cross-chain bridge may also enable assets to cross the chain by deploying liquidity pools in the destination chain. When an asset is controlled by a smart contract or a storage and liquidity pool, we call it unmanaged in this paper.
Cross-chain model of assets: Since each public chain has its accounting book of underlying assets, how do users transfer assets from the original book to different accounting systems? 0x76@BlockBeats, the author of BlockBeats, points out that what crosses the chain is not the asset itself but the value represented by the asset. This paper calls the asset cross-chain model "Transfer Mechanism."

The classification method of cross-chain bridges

Current articles on the market classify cross-chain bridges based on the following methods:

1. Dmitriy Berenzon, a research partner of @1KXNetwork, divides cross-chain bridges into four types according to the service purpose of bridges: those focusing on assets-specific, those connecting two chains, those focusing on application-specific, and those generalized.

2. Dmitriy is also based on the mechanism/technology used to validate the cross-chain transactions: External validator & Federations(multi-validation and single-validation), Light clients and Relays/Origin validation, and Liquidity networks.

3.Articles on the market have a variety of classifications of the transfer mechanism. This paper selects Arjun Chand and Andre Cronje's explanation of the transfer mechanism:

Arjun Chand's article divides transferring mechanism into three categories:

Lock + Mint: This type of bridge locks assets on the original chain and mints an equal amount of assets on the destination chain.
Burn + Mint: This type of bridge burns assets on the original chain and mints an equal amount of assets on the destination chain.
Atomic Swap: Relying on self-executing smart contracts to exchange assets, Atomic Swap has the highest trustless degree of the three types.

According to Andre Cronje's classification, there are four types of transfer mechanisms:

Balance Float: After the user locks the asset into the smart contract of the source chain, the Oracle notifies the cross-chain contract on the destination chain, which causes the destination chain to transfer the asset to the user's receiving address.
Lock + Mint/Burn: When the user locks an asset in the address or smart contract specified by the bridge, the bridge will mint the same amount of assets in the destination chain and transfer them to the user's account in the destination chain.
Liquidity swap(Two-way assets pool model): Use the bridge to establish a pool of assets in the destination chain, and cross the chain through the bridge's cross-chain assets. For example, swap USDC (Ethereum)> anyUSDC > USDC (Fantom).
Wrapped + Mint/Burn: Use the bridge to establish a pool of assets in the destination and source chains, and swap twice to cross the chain through the bridge's cross-chain assets. For example, swap USDC > anyUSDC (Ethereum) > anyUSDC > USDC (Fantom).

To unify the classification of the transfer mechanism, we divide the transfer mechanisms into three categories by summarizing the technical documentation of cross-chain Bridges:

Liquidity swap(requiring the deployment of liquidity pools)
Lock + Mint/Burn (requiring the deployment of liquidity pools)
Atomic swap

4.Security of bridge: As mentioned in Dmitriy Berenzon's article, the "trustless" bridge refers to the bridge whose security is based on the underlying public chain, which is the bridge with the highest security, such as Arbitrum and BOBA bridge, which is essentially a capacity expansion scheme on Ethereum - Optimistic Rollup. The "insured" bridge, as the second safest bridge, uses its collateral assets to return to the user as compensation if the validator makes a mistake. This mechanism gives users a better experience than the "bonded" bridge, which destroys the validator's staking assets without providing compensation. Finally, Bridges that are "trusted" typically involve centrally validating transactions and managing user assets.

In this paper, the safety sequence of bridges from good to bad is trustless, insured, bonded, and trusted bridges.

5.Others: Arjun Chand has further subdivided bridges according to their functions, but this paper will not go into detail.

The performance of chain bridge

Now that we understand the bridge’s fundamental elements and the classification of the bridge according to its service purpose, validation method, transfer method, and security, we can see that different cross-chain bridges have other development cores. Dmitriy Berenzon evaluated the performance of the bridge from the following perspectives:

Security: We judge that the security falls in order of relay, multi-validation, and single-validation; In multi-validation, PoS(Proof-of-stake) requiring the validator to stake is more secure than PoS without staking. In addition, security decreases when a bridge manages assets.
Speed: Refers to the delay in completing the transaction and the guarantee of finality. Some bridges focus on cross-chains between specific ecosystems (such as Hop Bridges that support layer-2 cross-chains) to facilitate faster cross-chain trading.
Connectivity: Developers integrate additional destination chains at different levels of difficulty.
Capital Efficiency: Refers to the transaction cost of capital and asset transfer required to ensure system security. For example, the upgrade of cBridge 2.0 aims to lower the threshold provided by liquidity and improve liquidity depth.
Statefulness: The ability to transfer specific assets, more complex states, and/or execute cross-chain contract calls.

02 Comments on cross-chain bridges

Cross-chain bridge product research

According to the document on the official website of cross-chain bridges, we summarize the commonalities of 16 bridges in this study and compare their performance of bridges. We should note that anyone reading whitepaper and bridge documents should think critically. Sometimes a newly launched cross-chain bridge project may use more complex language to describe existing technologies and mechanisms to highlight their "characteristics." This section aims to filter out the complex language and compare the differences between the characteristics of cross-chain bridges directly.

Synapse: this phase is multi-validation, where multi-party computation (MPC) validators run threshold signature scheme(TSS) consensus. Currently, anyone or project can apply to the Synapse community to become a validator, and the next phase will introduce PoS to improve security further. In transferring, Synapse bridge ensures that users access underlying assets by deploying pools of capital on the destination chain. Assets are controlled by Synapse smart contracts, making them unmanaged.
Multichain: multi-validation, the consensus is guaranteed by multi-party computing( MPC) based on threshold signature scheme(TSS), there is no staking mechanism at present, the transfer mechanism is Lock + Mint/Burn, and the bridge does not manage assets. In addition, multichain V3 adds a multichain cross-chain model, which uses the deployment of liquidity pools on multiple chains to complete asset cross-chain.
deBridge: multi-validation, the consensus is reached by multi-sig, and security is further ensured by its staking mechanism. The transfer mechanism is "Lock + Mint/Burn." Assets are locked in deBridge's smart contract and judged to be unmanaged.
ShuttleFlow: the alliance node carries out multi-validation, and the consensus is reached through multi-sig. The transfer mechanism is "Lock + Mint/Burn." Assets are held in escrow at a collection address supervised by a member of the Alliance.
Wormhole: 19 Guardians participate in multi-validation, reaching consensus through multi-sig, and the guardian's reputation guarantees security. The transfer mechanism is "Lock + Mint/Burn." Assets are judged to be unmanaged.
cBridge：multi-validation (Celer State Guardian Network), whereby multi-sig and staking reach consensus and ensure security; The transfer mechanism for the atomic swap. Assets are judged to be unmanaged based on the mechanism of the atomic swap.
ThorChain：multi-validation, the validator needs to bond enough governance token RUNE to run a node, and the verifier is replaced periodically to ensure security. Transfer of assets through the liquidity pool, with RUNE as the intermediate asset. Assets are not managed.
Hop: Bonder runs a node to perform multi-validation, and Bonder participates in validation transactions by staking assets. Hop bridge ensures users obtain underlying assets by deploying a capital pool in the destination chain. Assets are judged to be unmanaged.
Polygon/Matic PoS Bridge: multi-validation, where multi-sig consensus is reached, security is guaranteed by stake, and the transfer mechanism is "Lock + Mint/Burn." Predicate Contract oversaw for user assets of Polygon. Assets are judged to be managed.
Rainbow: validation is completed by light client + relay, and security is guaranteed simultaneously. The transfer mechanism is "Lock + Mint/Burn." User assets are stored in the TokenLocker contract and are unmanaged.
BOBA: BOBA acts as an Optimistic Rollup, validating transactions is performed by smart contracts and transferred through liquidity swaps. The security of BOBA is equivalent to the underlying network, Ethereum. User assets are managed at a BOBA network supervised address.
Arbitrum: Arbitrum is one of the expansion schemes of Ethereum - Optimistic Rollup, and transaction validation is performed by its smart contract. Its security is equivalent to the underlying network, Ethereum. User assets are managed at the address administered by Arbitrum.
xDai bridge: Controlled by TokenbridgeDAO members, multi-sig reach consensus. The transfer mechanism is "Lock + Mint/Burn." Assets are held in managed.
Binance bridge: Acting as a centralized exchange, Binance transfers users' assets onto different chains via changing balances, requiring users to host their assets in Binance.
wBTC：wBTC acts as a central DAO for authenticating user information and performing transactions. The transfer mechanism is Lock + Mint/Burn.User assets are hosted in wBTC.
Stargate: A cross-chain bridge built on LayerZero, where two roles assume the "validator": an Oracle and a Relayer, which communicate validation/cross-chain success when their messages match the destination chain. The transfer mechanism is a unified liquidity pool for liquidity swaps. Assets are not managed.

The performance comparison of different cross-chain bridges

Everyone's interpretation of the bridge technical documentation may be somewhat different, so the classification of the bridge in this article differs slightly from Dmitriy Berenzon's table. However, the logic of judging the validation mechanism of the cross-chain bridge is consistent. Readers can judge the validation mechanism and safety of the bridge step by step according to the following questions:

Does the cross-chain bridge centrally manage multi-validation, or use relay + light client to verify cross-chain information?
In the case of multi-validation, does the validator need some stake to provide services? Furthermore, if the verifier frauds or breaches the contract, should the staked assets be burned or compensated to the user to protect the user from loss?
Is the asset deposited by the user in the original chain managed by the address of the cross-chain bridge or stored in the smart contract or liquidity pool?

Based on the above problems and ideas, this paper reviews and compares the performance of 16 cross-chain bridges:

Among the 16 Bridges, Synapse, Multichain, deBridge, ShuttleFlow, Wormhole, cBridge, ThorChain, Hop, and Polygon PoS Bridges are multi-validation. In the consensus mechanism of multi-validation, the difference between multi-party computation (MPC) and multi-sig lies in the formation of a "private key." The multi-sig mechanism requires several validators to have complete private keys to sign transactions. On the other hand, multi-party computation eliminates the concept of a single private key and requires validators to form a private key together to complete transaction validation. In this way, the validators do not have complete private keys independently to ensure security. The comparison diagram in Alice Klocko's article is even more intuitive in describing the difference between the two mechanisms.

Among the 9 Bridges, deBridge, cBridge, ThorChain, Hop, and Polygon all require validators to stake before running the node to provide services for transaction validation. Compared with the others, which have no staking mechanism or use validators' "reputation" to guarantee, they have higher security. CBridge, deBridge, and ThorChain are called "insured" bridges to improve user experience further and protect user assets from loss. It means that the assets staked by the validator are not burned but returned to the user as compensation when a node is fraud or breaches the contract. From the user's point of view, such bridges provide a more reassuring cross-chain experience than verifying that the staked assets are only burnt when people commit fraud or breach the contract.

Unlike multi-validation, where users still need to trust the validator, Rainbow Bridge's light client + relay chain is a perfect decentralization. However, in achieving decentralization, the Rainbow Bridge sacrificed Connectivity. Due to the high development costs of deploying light clients on each chain, Rainbow can currently only serve asset cross-chains between Ethereum and Near. BOBA and Arbitrum, the two "Bridges" are relatively special because they are both layer-2 expanded schemes of Ethereum -Optimistic Rollup, so the security of the underlying Layer is equal to Ethereum. Such Bridges have higher security but require a 7-day challenge when the user wants to cross the chain from Layer-2 back to Layer-1.

In contrast, xDAI, Binance, and wBTC differ from the other 13 Bridges in their centralization: from transaction validation to the hosting of user assets. It's hard to believe that Binance would deliberately fraud or breach the contract against its reputation. However, the centralization of management somewhat contradicts the desire for decentralization in Web 3.

Stargate has been a hot cross-chain project based on the LayerZero base protocol since March. To make things more familiar to the reader, Stargate is similar to Rainbow Bridge in terms of the validation method, with the deployment of light clients and the use of a relay chain to cross the asset/information chain. But Stargate's innovation introduces two validation bodies, Oracle and relay chain, and there is no subjective agreement between the two but objective - when the transaction information provided by the two matches, it indicates cross-chain success. At the same time, its proposed "ultralight client" greatly reduces the difficulty and cost of deployment. Further, 0xivecott explains that Stargate addresses the pain points of receiving wrapped tokens by deploying a unified liquidity pool to provide customers with underlying assets, improving capital efficiency.

According to the above, we cannot judge the advantages and disadvantages of the cross-bridge from a single aspect. Some bridges focus on security and decentralization and relatively slow transfer of assets and connectivity requirements across the chain. On the contrary, other bridges for service transfer in small sums needs of users will prioritize the number of public chain transfer speed and access.

03 Development of cross-chain Bridges

Cross-chain bridge projects may evolve around "interoperability can't be triangulated" or may be optimized based on the five features outlined earlier in this article: Security, Speed, Connectivity, Capital efficiency, and Statefulness. For example, the development of Multichain focuses on Connectivity. Currently, as many as 33 public chains are connected, and Multichain V3 optimizes the transfer mechanism. Deploy pools of capital to enable users to target underlying assets on the chain rather than wrapped tokens. Hop Bridges focus on asset transfer between Layer1 and Layer2 rather than competing with Multichain in Connectivity. We believe that each bridge has its development core. After the development goal is established, it will further optimize safety, speed, capital efficiency, and other aspects.

Vitalik's concerns about the future of the bridge are raised by the bridge's safety when it hops across zones of the sovereign, the article begins. Indeed, no matter what kind of trade-offs the bridge has in the purpose of service**, security is an important direction that the cross-chain bridge R&D team wants to optimize and upgrade constantly.** For example, Synapse proposed that as the project moved into phases 2 and 3, it would require the validator to stake to improve security; In addition, cBridge 2.0 processes node information through a decentralized State Guardian Network (SGN), which improves security over the unique Gateway role in version 1.0.

The transfer mechanism can also optimize the enhancement of security: most asset cross-chains adopt "Lock + Mint/Burn" mode, so users usually get cross-chain assets on the destination chain, such as deBridge's deUSDT. Since the issuance of wrapped tokens involves three phases, the underlying asset also superimposes the risk factor, the security of the bridge, and the stability of wrapped tokens. In this way, users who switch to wrapped tokens assume more risk and have fewer liquid assets.

The realization of bridging through the liquidity pool can be understood as a step beyond the Lock + Mint/Burn mode. The liquidity pool is deployed on the destination chain to change the wrapped token of the bridge into common assets of the destination chain. This mechanism avoids the efficiency problem in the Lock/Mint mechanism and helps the cross-chain speed up. For example, Hop Bridge helps users convert the wrapped token (Hop ETH) of Hop bridge into common assets (L2 ETH) of Rollup by deploying a pool of assets on Rollup.

It seems convenient to bridge through liquidity, but there are also some problems. Potential problems with asset transfer through liquidity pools may lie in the depth of liquidity and the fragmentation of liquidity pools. For example, in the upgrade of cBridge 2.0, liquidity providers do not need to operate nodes by themselves but allow liquidity providers to entrust assets to SGN and obtain cross-chain fee income. This mechanism lowers the threshold of liquidity provision and thus improves capital efficiency.

From the user's point of view, the ultimate optimization of the cross-chain bridge depends on whether it can provide a smooth cross-chain experience: whether the cross-chain speed is fast enough, whether there is an upper transfer, whether it can achieve a one-button cross-chain, whether it helps users reserve/settle gas fees, whether the assets obtained are common assets of the destination chain, etc. By viewing the cross-chain bridge product comparison diagram, users can choose the corresponding cross-chain bridge according to their cross-chain needs.

So, what is the future development of cross-chain Bridges? Instead of focusing on making up the shortboard of the cross-chain bridge, it is better to make forward-looking thinking from the perspective of the purpose of users to do cross-chain assets:

Cross-chain aggregation: Imagine if you want to bridge assets from Ethereum to Arbitrum. Through the comparison diagram of cross-chain bridge products, you know that deBridge and Synapse are connected to Arbitrum. But you can't determine which cross-chain bridge is cheaper and faster to use in real-time cross-chain. Cross-chain aggregators, then, may have a promising future - eliminating DYOR (Do Your Own Research) and providing services that screen out optimal cross-chain paths and costs in seconds. Stay tuned for a detailed comparison of cross-chain aggregator products in Dr.DODO's next article.
Developers can also consider embedding other financial services into the bridge, either via a "Bridging + transaction" that Li.Finance is doing, or a "cross-chain + load" scheme proposed by DeFi protocol Aave in version V3. Or Sushi's proposal to integrate LayerZero's Stargate bridge. It allows users to complete DeFi related activities while crossing chains without switching to a third-party platform.
In addition, cross-chain project Multichain recently launched anyCall, which also looks practical and eye-catching. AnyCall is A generic cross-chain messaging protocol which can send cross-chain messages from chain A to chain B by calling the original contract on the destination chain. In practice, Curve has taken advantage of this opportunity by integrating anyCall to help veCRV holders on different blockchains more effectively distribute the benefits of CRV rewards. Specifically, when Curve connects to anyCall, it can timely calculate the reward weight of users on the destination chain and mint the corresponding reward. It eliminates the need to deploy CRV-rewarded liquidity pools in advance, significantly improving capital efficiency.

In summary, we believe that cross-chain will continue to be a focus for users and developers alike despite Vitalik's negative attitude towards cross-chain. After all, if a closed public chain ecosystem is established because of security issues, it will shrink. In addition, based on users' enthusiasm for Stargate, a cross-chain infrastructure project launched by LayerZero (currently, TVL reaches $2.5B). A cross-chain bridge may combine the above two functions to develop Layer-0. As the underlying foundation of the public chain, it has strong integration. It also provides users with underlying assets and cross-chain timeliness through a unified liquidity pool.