Comprehensive analysis of cross-chain bridges: design, trade-offs and opportunities
This article is from Amber Group, and Odaily is authorized to reprint and publish it.
Last year, Ethereum’s dominance as the dominant smart contract blockchain was challenged by an alternative L1 blockchain. The multi-chain world has become an indisputable fact. With the introduction of these new chains, their heterogeneous consensus mechanism, smart contract language, and community value split Web3 into various ecosystems.
image description
source:Defi Llama
source:
These separate ecosystems create value for their respective communities, but the lack of interoperability between each other makes most of the cross-chain synergy value lost. This fragmentation also leads to increased tribalism, more attack vectors, and a worse user experience.
This report will cover the definition of cross-chain bridges, the classification of different cross-chain bridge architectural designs, the trade-offs between different designs, the risks associated with cross-chain bridges, and our views on the prospects of the cross-chain bridge ecosystem.
first level title
Definition and classification of cross-chain bridgesIn the most general terms, a cross-chain bridge transfers information between two or more blockchains. This feature is most commonly used to exchange assets on one blockchain (the "source" chain) for assets on another chain (the "target" chain). At the same time, the cross-chain bridge can also be used to transfer data or messages from the source chain to the target chain. At the time of writing, there are currently more than100 blockchain cross-chain bridgesArjun ChandUsed to transmit information in the ecosystem of Layer1 and Layer2. This increasingly complex environment makes it difficult for new players to understand the plate, so simplifying the various designs by establishing an overall framework may help. recent,
A useful framework is constructed to organize the various types of cross-chain bridges into different categories. We also use a similar approach to classify various cross-chain bridges.
We think the most important feature is how cross-chain bridges transfer data from one chain to another.
first level title
Cross-chain mechanism
To understand how the flow pool bridge works, let's imagine a user who wants to transfer USDT from Ethereum to Polygon. The user first needs to deposit the Ethereum version of USDT into the specified contract address (flow pool) on Ethereum, and specify the receiving address of the USDT on Polygon, which is the address where USDT will be credited on Polygon. The cross-chain bridge uses this information to transfer the Polygon version of USDT to the specified Polygon address.
image description
The bridging mechanism of the flow pool mode cross-chain bridge
A major flaw of this design is that the cross-chain bridge must ensure that there are enough assets in the unilateral liquidity pool held on the target chain for the user to actually complete the fund transfer. In the above example, if the cross-chain bridge's USDT flow pool on Polygon is empty, the USDT stored in the Ethereum flow pool will be "stuck" until another user requests a reverse transfer of USDT from Polygon to Ethereum , and enough USDT is replenished into Polygon's USDT liquidity pool. Additionally, this type of cross-chain bridge only allows cross-chain transfers of a single type of asset (for example, only transferring USDT from Ethereum to Polygon). If you want to exchange USDT on Ethereum for MATIC on Polygon, you can only exchange after receiving USDT on Polygon.
The main advantage of this design is that users no longer need to rely on the security of a one-sided liquidity pool after receiving tokens on the target chain. The assets received by users are the original assets on the target chain, so there is no need to rely on the redemption ability of the underlying assets to ensure their asset value. This is in stark contrast to another commonly used bridge design of "Lock & Mint / Burn & Redeem".
Lock & Mint/ Burn & Redeem"mechanism, and then mint or redeem respectively. Let's use again the example of transferring USDT from Ethereum to Polygon in the previous section to describe how the mechanism works. As before, the user first deposits the Ethereum version of USDT into the specified contract address held by the cross-chain bridge, and specifies the receiving address on Polygon. This step is called "locking". However, unlike before, this type of cross-chain bridge "mints" or issues a Polygon version of the deposited asset on Polygon and credits it to the receiving account. These minted tokens are often referred to as “wrapped” tokens, and their value depends on the ability to eventually redeem them for the underlying asset on the source chain. When a user wants to transfer back to Ethereum, the wrapped tokens are simply sent to the cross-chain bridge contract address on Polygon and "burned". This enables the underlying asset on Ethereum to be redeemed and sent to the specified receiving address.
Lock USDT to mint encapsulated USDT
Destroy encapsulated USDT to unlock USDT
image description
(i.e., the inverse of the minting transaction)Because wrapped tokens rely on their redeemability to maintain their value, holders of wrapped assets are exposed to smart contract risk. If the liquidity pool on the source chain is stolen and the underlying asset is emptied, the wrapped token will become worthless. This is exactly what happened to the recent Wormhole cross-chain bridgeattack event
, which resulted in losses of more than $320 million.
Nevertheless, the advantage of the lock/burn & mint mechanism is that such cross-chain bridges always fluidly allow the transfer of assets from the source chain to the target chain and vice versa. This is because they do not require a liquid token pool on the target chain to be deployed in the cross-chain bridge contract. This makes this type of cross-chain bridge have advantages in terms of scalability.
Native cross-chain exchange bridge (with decentralized intermediate chain)
To briefly explain how it works, let's look at an example of converting native BTC to native ETH, we will use the base version of the THOR chain architecture as a reference.
image description
Convert native BTC to native ETH through a decentralized intermediate chain and built-in AMM
In this example, a user holding BTC first sends BTC (along with an Ethereum receiving address) to a Bitcoin Vault address. The vault is controlled and monitored by multiple nodes that observe incoming transactions and record status updates of the Bitcoin vault on intermediate chains (such as the THOR chain). Once the node confirms that the vault has received the BTC, the node calculates the appropriate amount of ETH to be credited to the user on the Ethereum blockchain. Similar to any other AMM swap, the execution price of a cross-chain swap is determined by the swap amount, which is related to the corresponding amounts of BTC and ETH available in the vaults on both chains. A large exchange that "uses up" a large amount of liquidity will execute at a higher price than a small exchange that uses a small amount of liquidity. Once the exchange amount is calculated, the intermediate chain sends a message to the Ethereum network, causing it to send the appropriate amount of ETH from the vault address to the user's receiving address.
Compared with the flow pool mode cross-chain bridge, the native cross-chain exchange bridge with the intermediate chain has a higher level of decentralization and anti-censorship capabilities. For cross-chain bridge users, although liquidity providers can still steal assets from AMM's liquidity pool through hackers or loopholes, it can avoid the smart contract risks brought about by encapsulating assets.
Despite these advantages, the architectural design of such cross-chain bridges is far more complex than other cross-chain bridges. Creating a trusted decentralized native cross-chain swap bridge requires a significant investment of capital and time. For example, in order to achieve a native exchange from BTC to ETH, each node on the THOR chain must run a full Bitcoin network node and a full Ethereum network node. In addition, every node on the THOR chain must be incentivized to be honest and reliable. In order to achieve a single exchange, all of the above must be done.
This type of cross-chain bridge aims to learn from the simple architecture of the flow pool model cross-chain bridge, and on this basis provide the convenience of exchanging native assets. Essentially, this type of cross-chain bridge works much like a liquidity pool model cross-chain bridge, but with an extra step that allows users to receive assets on the target chain that are compatible with the assets they deposited on the source chain. are different types of assets. LayerZero Labs’ Stargate cross-chain bridge is an example of this type. We'll use an example again to explain how it works. This time, let's consider exchanging native SOL for native ETH.
image description
Convert native SOL to native ETH by using two AMMs and a cross-chain stable exchange bridge
Again, the user first deposits its asset SOL into the specified contract address on Solana, which is held by the cross-chain bridge. However, unlike the previous example, this deposit actually triggers the AMM to exchange SOL for a stablecoin on Solana. For example, it might exchange SOL for USDC. From this step, the function of the cross-chain bridge will be very similar to that of the flow pool mode cross-chain bridge. The stablecoin balance in the Solana contract address is transferred from the cross-chain bridge provider to the user's contract address in Ethereum. Finally, once the USDC is credited to the user name on Ethereum, the cross-chain bridge will trigger the AMM to perform the exchange from USDC to ETH. This ETH is then credited to the receiving address specified by the user. In essence, the function of this type of cross-chain bridge is equivalent to that of the liquidity pool mode cross-chain bridge, except that only stablecoins are transferred across the chain, so as to provide better execution prices during the cross-chain transfer process. Typically, the AMM swap execution price on both chains is derived from a function that calculates the size of the swap, which is related to the liquidity available in the two sided pools.
This architecture avoids the smart contract risk of encapsulating assets and provides a simpler cross-chain communication mechanism than the intermediate chain architecture. However, since the execution price depends on the liquidity available for each AMM, there is a risk that the exchange execution price will not be ideal.
This particular type of cross-chain bridge utilizes two contract addresses on different chains (called the master contract and the replica contract) and four different off-chain participants who are incentivized to send messages across chains. Perhaps the most well-known protocol in this category is Nomad, which makes it easier for multi-chain applications to communicate across the blockchain ecosystem. Let's explain how it works with a simplified example of sending a message from Ethereum to Polygon:
image description
Master and replica contracts updated, monitored and propagated by incentivized off-chain participants to send messages across chains
A user on Ethereum will first submit a message to the main contract address on Ethereum. The main contract picks up this message and puts it on a queue along with other messages it receives. At this point, off-chain participants called "updaters" sign the message group to update the state of the main contract. In order to sign these messages, the updater must pledge a security deposit to the main contract, which will be forfeited if the updater later proves to have acted maliciously. The second off-chain participant is an "observer", which monitors the master contract and the replica contracts on Polygon to ensure that all messages are recorded and sent correctly. Since the cross-chain bridge relies on optimistic fraud proofs, in order to prevent malicious behavior from being executed and punish malicious updaters, observers are responsible for submitting malicious behavior proofs. In the absence of evidence of malicious behavior, the cross-chain bridge will assume that the message was recorded and sent correctly (hence the name "optimistic"). Assuming the observers do not detect an operational problem with the updater, a third off-chain participant, a "relay", will transmit the message to a replica contract on Polygon. Finally, a fourth off-chain participant, the "processor", propagates the message from the replica contract to the final recipient of the message.
A major drawback of this bridge design is the existence of a Fraud Proof Delay (DTD) that lasts about 30 minutes, providing a window for observers to scan for suspicious behavior and question malicious transactions.Connext and Hop These two protocols reduce the waiting time by allowing other market participants to send tokens directly to the final recipient before the fraud proof window expires. In effect, the two protocols take the risk associated with malicious transactions on behalf of recipients in order to collect fees from recipients who desire higher liquidity.
first level title
Trust required vs. no trust required
In this classification, cross-chain bridges are divided into two categories. They are either 1) trustworthy or 2) trustless. In other words, users either trust some third party to operate the cross-chain bridge and keep it secure, or rely on software designed and run in a distributed manner so that no single entity can change its state or operate on it. Trusted cross-chain bridges include xPollinate, Matic Bridge, and Binance Bridge. Trustless cross-chain bridges include THOR Chain, Ren, and Cosmos IBC.
Importantly, the difference between trusting and not trusting is not black and white, but gradual. A distributed software protocol with a smaller or more geographically concentrated set of operators will be more susceptible to a single point of failure than a system with a larger, more heterogeneous set of operators. Similarly, cross-chain bridges that require users to lock assets in contract addresses in exchange for encapsulated assets also require users to trust that the code is written in a way that prevents attacks or theft. Non-custodial cross-chain bridges do not require this trust, even though they are usually run by a centralized entity.
What is the connection object
From Layer 1 to Layer 1The cross-chain bridge from Layer 1 to Layer 1 allows users to transfer funds between the two L1 ecosystems. For example,Wormhole's Portal cross-chain bridge
Supports asset transfers from Solana to Ethereum. By promoting interoperability between Layer 1 ecosystems, web3 users are free to spend time and resources on their preferred chain, while maintaining the flexibility to switch chains at any time.
From Layer 1 to Layer 2AcrossThe cross-chain bridge from Layer 1 to Layer 2 allows the L1 chain such as Ethereum to communicate with the L2 chain built on the L1 chain. For example, a user may wish to transfer ETH from the Ethereum mainnet to Arbitrum, Optimism, or ZkSync. Users can transfer their tokens by using each L2's native cross-chain bridge, or they can use such asthird-party cross-chain bridge. As the L2 ecosystem continues to grow, such cross-chain bridges will play a role in moving Ethereum's mainnet activity to L2.。
important role
From Layer 2 to Layer 2Orbiter FinanceA number of projects, including , are actively working towards this goal.
first level title
Tradeoffs in cross-chain bridge designAlthough there are dozens of cross-chain bridge architecture designs, none of the cross-chain bridges can have"The Interoperability Trilemma"
all three properties of . The interoperability trilemma is a term coined by Arjun Bhuptani, which states that cross-chain bridges can only have two of the following three properties: universality, scalability, and trustlessness.1. Versatility:
The ability to pass arbitrary data between the two chains2. Scalability:
The ability to quickly deploy on heterogeneous chainsMinimize trust assumption
and
source:Arjun Bhuptani
andThe scalability trilemmaThe scalability trilemmaZetaChainSimilarly, when a cross-chain bridge chooses two of these properties, the last property will be difficult to satisfy. For example, Connext is a trustless cross-chain bridge that transfers tokens between two EVM-compatible chains. Currently, it cannot pass arbitrary data, which means it prioritizes scalability and trustlessness over generality. like
Other cross-chain bridges prioritize scalability and versatility, but need to provide an additional layer of trust through the validator set of the cross-chain bridge, thus sacrificing trustlessness.
To describe the extension of cross-chain bridges from token transfer mechanisms to application platforms, we can use an analogy that cross-chain bridges are similar to toll roads connecting two highly congested cities. Toll roads charge a toll every time a user wants to drive from city A to city B. Cross-chain bridges have been slowly turning this toll road model into a town model, where developers build applications on cross-chain bridges, like creating a town between city A and city B.
image description
Because some cross-chain bridges have tens of thousands of unique users and have achieved billions of dollars in transfer volume, they can leverage existing user activity to incentivize developers to build applications on top of their cross-chain bridges. Continuing with the toll road analogy, developers are like ambitious entrepreneurs who decide to move to the town after seeing the influx of wealthy people (users) into the area. After seeing more movement in the town, other entrepreneurs also moved into the town and started creating larger scale businesses (apps). Soon the town developed and the road tollbooth that once served as an intermediary between the two big cities is now the gateway to this thriving town.
first level title
Cross-chain bridges or "Layer Zeros" as application platforms
RenVM
There are some noteworthy projects that are trying to become the thriving towns shown in the previous analogy. These projects focus on developing new ways to connect data across chains while providing the foundation for the dapp ecosystem. These items include:"renBTC"RenVM and the Catalog protocol are likened to the toll road and town in the above example. RenVM supports cross-chain transactions using the "lock and mint/burn and redeem" mechanism described earlier. Currently, it allows users to wrap BTC tokensCatalogAs a medium, move BTC in and out of Ethereum and Polygon. The cross-chain bridge can be thought of as an application built on top of RenVM. On top of this,
LayerZero
LayerZero is a communication primitive that allows data and information to be sent on the EVM chain with LayerZero endpoints. A LayerZero endpoint is essentially an on-chain client. Any chain with a ZRO endpoint can conduct cross-chain transactions. A third-party oracle service such as Chainlink needs to be used between endpoints to act as a secure mechanism for transactions and messaging.
image description
source:source:
LayerZero white paper
Applications deployed on various L1 blockchains will find this a very simple approach. For example, if a Dapp is built on Polygon, it is a fairly simple task to quickly load this dapp into LayerZero using an endpoint. DApps like Stargate leverage the communication standards developed by LayerZero to create decentralized exchanges/cross-chain bridges.
Zeta chain
The Zeta chain is a Layer 1 blockchain, which neither needs to encapsulate assets to transfer assets across chains, nor does it require cross-chain bridges for each pair of blockchains. This is achieved through the Zeta chain's ability to pass messages across chains, which allows data and values to be sent across chains and layers. Using full-chain smart contracts, developers can program the Zeta Chain to listen to events on connected blockchains and act accordingly. The Zeta chain relies on validating node consensus to ensure its own security, and a distributed threshold signature scheme to ensure the security of private keys on connected chains, thereby avoiding single points of failure. PoS incentivizes validators to behave correctly.
These cross-chain bridge platforms enable interoperability between chains and allow new ecosystems to be built on top of it. In addition to sending tokens from chain A to chain B, new application scenarios are unlocked. Nonetheless, each unique mechanism of a cross-chain bridge/cross-chain bridge platform has some level of risk.
first level title
image description
Cross-chain bridge risk
Cross-chain bridge risk
The two main attack vectors that compromise the security of cross-chain bridges are 1) smart contract vulnerabilities and 2) root-of-trust vulnerabilities.
image description
Two main attack vectors for cross-chain bridges
Malicious actors exploit smart contract vulnerabilities when successfully attacking cross-chain bridges at the application layer. Since most cross-chain bridges must deploy secure smart contracts on all chains they connect to, newer blockchains are easier targets. While languages like Rust, CosmWasm, and Substrate all have growing developer communities, they don’t have as many developer tools and auditing companies as mature languages like Solidity, and thus have a higher chance of mainnet vulnerabilities. Considering that the team will consider factors such as development speed and market competition when developing a cross-chain bridge, it is easy to understand why smart contract vulnerabilities have become the most common hacker attack vector.
As one can see, externally these vulnerabilities are not easy to detect, but the costs associated with poor security systems can be enormous. Last year, the cumulative cost of cross-chain bridge attacks exceeded $1.5 billion.
image description
source:Decrypt, Kudelski Security Research, The Verge, VentureBeat
source:
Therefore, when transferring funds, it should be considered to understand the underlying security system used by cross-chain bridges. Security is irrelevant if retail traders need to send 0.5 ETH quickly to ensure the NFT minting is complete. However, if the DAO plans to transfer 10,000 ETH to a contract on a different chain, it is necessary to carefully examine the underlying security of the cross-chain bridge.
epilogue
With the continuous development of the encryption industry, new cross-chain bridge designs will be explored, new security models will be tested, and new applications based on cross-chain bridges will also emerge. The successful emergence of cross-chain bridges that combine security, flexibility, and efficiency will allow for broader interconnection between protocols and communities. Because we are in the period of filtering and eliminating unsafe cross-chain bridges, there will be short-term pains, but the future of the cross-chain bridge industry will be bright.
disclaimer
Amber Group has invested in Nomad, Orbiter, Catalog, Zeta Chain, and we provide routing/bonding/liquidity services for many of the protocols listed above. The information contained herein (“Information”) is provided for informational purposes only, in summary form and is not exhaustive. These materials are not, and are not intended to be, an offer or the solicitation of an offer to sell or buy any securities or products. Such information is not provided and should not be considered as providing investment advice. These materials do not take into account the specific investment objectives, financial situation or particular needs of any potential investor. No promises or warranties, express or implied, are made regarding the fairness, correctness, accuracy, rationality or completeness of the Materials. We make no commitment to update this material. It should not be considered by potential investors as a substitute for their own judgment or research. Potential investors should consult their own legal, regulatory, tax, business, investment, financial and accounting advisors, to the extent they deem necessary, and make any investment decisions based on their own judgment and the recommendations of such advisors.
