As the cryptographic industry continues to evolve, new bridge designs will be explored, new security models will be validated, and new bridge-based applications will continue to emerge.
Over the past year, Ethereum’s dominance as the primary smart contract blockchain has been challenged by other Layer 1s. The multi-chain world is no longer a doubt; it is a reality. As these new chains are adopted, their consensus mechanism, smart contract language, and community value “smash” Web3 into various ecosystems.
L1 market share (% of TVL)
These ecosystems create value for their respective communities, but lose a lot of cross-chain synergy value due to lack of interoperability. Fragmentation has also led to increased tribalization, more attack vectors, and a worse user experience.
Friction between these chains must be minimized for the industry to grow and gain billions of new users. This is the main goal of the encryption bridge.
This report will cover the definition of bridges, the classification of different bridge designs, the trade-offs between different designs, the risks associated with bridges, and our views on the future of the bridge ecosystem.
Definition and Classification of Bridges
The most abstract understanding is that a bridge transfers information between two or more blockchains. The main purpose of bridges is to exchange assets on one blockchain for assets on another chain. Not only that, bridges can also be used to pass data or messages from a source chain to a destination chain. There are currently over 100 blockchain bridges used to transfer information between layer 1 and layer 2 ecosystems. This growing complexity makes it difficult for new entrants to understand the field, so it may be helpful to use frameworks to simplify various designs. More recently, Arjun Chand created a useful framework that divides many types of bridges into different categories. We employ a similar approach to classify various forms of bridges.
Bridges can be classified according to many characteristics. This includes how they pass information across chains, their trust assumptions, and the type of chain they connect to.
In our opinion, the most important factor is how they transfer data from one chain to another.
Pool Based Bridge
To understand how pool-based bridges work, let’s now take an example: a user who wants to transfer USDT from Ethereum to Polygon. The user first deposits the Ethereum version of USDT into the designated contract address (that is, the pool) on Ethereum, and specifies the receiving address on the Polygon network to which the USDT should belong. The bridge uses this information to transfer the Polygon version of USDT to the specified Polygon address.
Pool based bridge mechanism
A major limitation of this design is that the bridge must have sufficient assets in the target chain’s pool for users to be able to move funds. In the above example, if Polygon’s USDT pool is empty, USDT deposited in the Ethereum pool will be “stuck” until another user replenishes Polygon’s USDT pool with enough USDT, and there is a transfer from Polygon to The need for reverse transfers in Ethereum. Additionally, these types of bridges only allow cross-chain transfers of one type of asset. If you want to exchange USDT on Ethereum to MATIC on Polygon, you can only complete the operation after receiving USDT on Polygon.
The main advantage of this design is that users do not need to rely on the security of the pool after receiving tokens on the new chain. The assets they receive are native versions of the new on-chain assets and therefore do not depend on redeeming the underlying asset to maintain its value. This is the opposite of another commonly used bridge design: lock & mint/destroy & redeem.
Lock & Mint / Destroy & Redeem
Another common bridge uses a mechanism called “locking” or “destroying”. We will again use the Ethereum USDT to Polygon USDT example from the previous section to describe how the mechanism works. As before, the user first stores the Ethereum version of USDT to a designated contract address owned by the bridge, and designates the receiving address. This step is called “locking”. Unlike before, however, this type of bridge “mints” or issues its own version of the storage asset on Polygon and credits it to the recipient’s account. These minted tokens are often referred to as “wrapped” tokens, and their value depends on the ability to eventually redeem them as the underlying asset on the source chain. When the user wants to go back to Ethereum, the wrapped tokens are simply sent to the bridge contract address on Polygon and “burned”. This allows the underlying asset on Ethereum to be redeemed and sent to a designated receiving address.
Lock USDT to minted packaged USDT
Destroy the packaged USDT to unlock the USDT
Since packaged tokens rely on their redeemability to maintain their value, holders of packaged assets are exposed to smart contracts. If the pool on the source chain is utilized and the underlying assets are depleted, the wrapped tokens will become worthless. That’s exactly what happened on the Wormhole bridge recently, causing more than $320 million in damage.
That said, the lock & mint/destroy mechanism has the advantage that these bridges can always allow asset transfers from the source chain to the target chain and vice versa. This is because there does not need to be a pool of tokens available in the bridge contract on the target chain. These types of bridges have advantages in terms of scalability.
Native exchange bridge (with decentralized intermediary chain)
This type of bridge has become more and more popular in the past year or so, most likely due to the gradual expansion of THORChain. A native swap bridge allows users to exchange a native token on the source chain for another native token on the target chain. For example, users can exchange native BTC for native ETH on their respective chains without needing to package assets. This is achieved through the use of cross-chain automated market makers (AMMs), as well as the use of intermediary chains that monitor and record the state of the source and destination chains. Although the ability to exchange different native assets across chains is very useful, this type of bridge uses the most complex transfer mechanism.
To briefly explain how it works, let’s look at an example from BTC to ETH, using the basic version of the THORChain architecture as a reference.
Swap native BTC for native ETH through a decentralized intermediary chain and built-in AMM
In this example, a user who holds BTC first sends this BTC to a Bitcoin address, which is called a vault. This vault will be controlled and monitored by a number of nodes that observe incoming transactions and record the updated status of the Bitcoin vault on the intermediate chain (such as THORChain). Once the node confirms that the vault has received the BTC, the node calculates the appropriate amount of ETH to credit the user on the Ethereum blockchain. As with any other AMM exchange, the price at which a cross-chain swap is executed depends on the size of the swap, which is relative to the respective amounts of BTC and ETH available in the vaults on both chains. Larger exchanges that “consume” a lot of available liquidity will execute at a more unfavorable price than small exchanges that use little available liquidity. Once the exchange amount is calculated, the intermediary chain sends a message to the Ethereum network sending the appropriate amount of ETH from the vault address to the user’s receiving address.
Native exchange bridges with intermediary chains provide a higher level of decentralization and censorship resistance than pool-based bridges. For bridge users, it also avoids the smart contract risk of packaged assets, but liquidity providers’ assets can still be stolen from AMM’s liquidity pools due to hacks or vulnerabilities.
Despite these advantages of this type of bridge, their structure is much more complex than other bridge designs. Creating a trusted decentralized native swap bridge is highly capital-intensive and time-consuming. For example, to enable native exchange from BTC to ETH, each THORChain node must run a full Bitcoin node and a full Ethereum node at the same time. Furthermore, each THORChain node must be incentivized to act honestly and reliably.
Native exchange bridge (exchange via stablecoin)
This type of bridge is designed to provide the convenience of a native exchange combined with the simplicity of a pool-based bridge architecture. Essentially, these bridges work much like pool-based bridges, but add an extra step that allows users to receive assets on the target chain that are different from what they deposited on the source chain. An example of such a bridge is LayerZero Labs’ Stargate bridge. We’ll use an example again to explain how they work. Now take an example of a native exchange from SOL to ETH.
Swap native SOL and native ETH by using two AMMs and a cross-chain Stableswap bridge
Likewise, users first deposit their assets SOL into Solana’s designated contract address, which belongs to the bridge. However, unlike the previous example, this deposit actually triggers an AMM swap of SOL to stablecoins on Solana. For example, it can exchange SOL for USDC. From here, the bridge functions like a pool-based bridge; the bridge provider credits the stablecoin balance in the Solana contract address to the user’s Ethereum contract address. Finally, once USDC is credited to the user on Ethereum, the bridge performs another AMM swap from USDC to ETH. This ETH is then credited to the receiving address specified by the user. Essentially, these bridges function as pool-based bridges that only transfer stablecoins on-chain in order to provide better price execution during cross-chain transfers. As always, the AMM swap execution price on both chains is a function of the swap bridge relative to the liquidity available in both pools.
This architecture avoids the smart contract risk of packaged assets and provides a simpler mechanism for cross-chain communication than intermediate chain architectures. However, depending on the liquidity of each AMM, it is also possible to get an unfavorable exchange price.
Home/Replica Contract Messaging (via Optimistic Fraud Proofs)
This particular type of bridge utilizes two contract addresses on separate chains, called the Home contract and the Replica contract, and four different incentivized off-chain participants to send messages across blockchains. Perhaps the most notable of such protocols is Nomad, which allows multi-chain applications to more easily communicate across the blockchain ecosystem. Let’s explain how it works with another simple example, sending a message from Ethereum to Polygon:
Send messages across chains via Home and Replica contracts that are updated, monitored, and propagated by incentivized off-chain participants
A user on Ethereum begins the entire journey by submitting a message to the Home contract address on Ethereum. The Home contract collects this message and puts it in a queue along with other messages it receives. At this point, an off-chain participant called the “updater” signs this message group to update the state of the Home contract. In order to sign these messages, the updater must post the Home contract’s collateral, which will be slashed if it later proves that any malicious behavior has occurred. A second off-chain participant, the “watcher”, monitors the Home contract and the Replica contract on Polygon to ensure that all messages are logged and sent correctly. Since bridges rely on optimistic fraud proofs, observers are responsible for submitting proofs of malicious activity to prevent it from being processed and penalize malicious updaters. Otherwise, the message will be considered by the bridge to be correctly recorded and sent (hence the name “optimistic”). Assuming that the observer does not detect a problem with the updater’s operation, a third participant off-chain, the “relayer”, will transmit the message to the Replica contract on Polygon. Finally, the fourth off-chain actor, the “processor,” propagates the message from the Replica contract to the final recipient of the message.
This architecture is more suitable for message/data transfer between blockchains, but could theoretically also be used to transfer assets, since asset transfers are ultimately just data describing changes in account balances.
A major disadvantage of this bridge design is that there is a dispute time delay (DTD) lasting about 30 minutes during which observers detect suspicious behavior and compete for malicious transactions. Two protocols, Connext and Hop, can reduce wait times by allowing other market participants to send tokens directly to the final recipient before the fraud proof window expires. In effect, both protocols take on the risks associated with malicious transactions in order to charge fees to takers who want faster liquidity.
Trusted and untrusted
In this classification, bridges are divided into two categories. They are either a) trusted or b) untrusted. In other words, users either trust a third party to maintain the security and operation of the bridge, or rely on software designed and run in a distributed fashion so that a single entity cannot change its state or operations. Some examples of bridges that require trust include xPollinate, Matic Bridge, and Binance Bridge. Some examples of trustless bridges include THORchain, Ren, and Cosmos IBC.
Importantly, the distinction between trusted and untrusted is not as clear-cut as black and white. A distributed software protocol with a smaller or more centralized set of operators will be more susceptible to a single point of failure than a system with a larger, more heterogeneous set of operators. Likewise, bridges that require users to lock assets in contract addresses in exchange for packaging assets also require users to trust that the code is written in a way that prevents exploits or theft. Non-custodial bridges do not require this trust, as they are usually run by centralized entities.
What do they connect to?
From Tier 1 to Tier 1
Layer 1 to Layer 1 bridges allow users to transfer funds from one L1 ecosystem to another. For example, Wormhole’s Portal bridge can enable the transfer of assets from Solana to Ethereum. By increasing interoperability between these layer 1 ecosystems, Web3 users are free to spend their time and resources on the chains they prefer, while maintaining the flexibility to switch chains at any time.
From Tier 1 to Tier 2
Layer 1 to Layer 2 bridges allow L1 chains (like Ethereum) to communicate with L2 chains built on top of the Layer 1 chain. For example, a user might want to connect ETH from the Ethereum mainnet to Arbitrum, Optimism or ZkSync. They can transfer their tokens by using each L2’s native bridge, or they can use a third-party bridge such as Across. These bridges will play an important role in the transition of Ethereum mainnet activity to L2 as the L2 ecosystem continues to grow.
From Tier 2 to Tier 2
As the first half of 2022 draws to a close, the roadmap for the second layer is also becoming clearer. Various Layer 2 scaling solutions from Polygon (Miden, Hermez, Nightfall), Starkware’s ZK-rollup Starknet, and Matter Lab’s ZkSync 2.0 will provide developers with the necessary core building blocks to build without being overcharged with gas Fees interfere with applications. However, these different L2s are not inherently compatible, so it is possible for them to evolve into the kind of “fragmented” scenario we see in L1. The goal of the L2-to-L2 bridge is to ensure that the L2 ecosystem maintains the advantages of high throughput, low gas fees, and high security, while reducing the potential for fragmentation of the L2 ecosystem. Some projects actively working towards this goal include Hop Protocol and Orbiter Finance.
Although there are dozens of bridge designs, no bridge can achieve all the properties of the interoperability trilemma. The Interoperability Trilemma, a term coined by Arjun Bhuptani, states that bridges can only have two of the following three properties: universality, scalability, and trustlessness.
- Versatility: Ability to pass arbitrary data between two chains
- Scalability: Ability to quickly deploy on heterogeneous chains
- Trustlessness: Minimizing Trust Assumptions
The Interoperability Trilemma
Similar to the scalability trilemma, when a bridge chooses two of the properties, the last property is affected. For example, Connext is a trustless bridge that enables token transfers between two EVM-compatible chains. Currently, it cannot pass arbitrary data, which means it prioritizes scalability and trustlessness over generality. Other bridges, such as ZetaChain, prioritize scalability and generality at the expense of trustlessness, so they require an additional layer of trust.
Since the primary use case for bridges is the transfer of tokens between two blockchains, most projects opt for generality and scalability to quickly deploy on heterogeneous chains and maintain the flexibility to pass arbitrary data. This allows these types of bridges to be deployed faster than many competitors and meets market demand for token transfers. While this is an unknown cost to many users (covered in the risk section), these types of bridges can expand their use cases from performing simple token transfers to more comprehensive developer platforms.
We can illustrate the bridge’s transition from a token transfer mechanism to an application platform by comparing it to a toll road connecting two highly congested cities. Every time a user wants to go from city A to city B, the toll road collects tolls. Bridges have slowly moved from a toll road model to a town model, where developers build applications on bridges, creating a town between City A and City B.
Huge towns (ecosystems) will eventually develop on toll gates (bridges) connecting different cities (blockchain)
Because some bridges have thousands of users and have transferred billions of dollars in traffic, they can leverage existing user activity to incentivize developers to build applications on their bridges. Continuing with the example of a toll road, we can compare a developer to an ambitious entrepreneur who decides to move into a small town after witnessing an influx of citizens (users). After seeing more activity happening in this town, other entrepreneurs also move to this town and start creating bigger businesses (apps). Soon the town got bigger, and the toll road that formerly served as a means of transportation between the two big cities is now the gateway to this thriving town.
Bridge as an application platform or “layer zero”
In the previous analogy, there are some notable projects that are trying to become thriving “towns”. These projects focus on creating new ways to connect data across chains while providing the foundation for the dapp ecosystem. They include:
An example of the toll road and town analogy mentioned earlier is the RenVM and Catalog protocols. RenVM supports cross-chain transaction transactions using the lock & mint/destroy & redemption mechanism described earlier. This allows users to transfer BTC between Ethereum and Polygon using packaged BTC tokens called “renBTC”. Bridging can be thought of as an application built on top of RenVM. Among other things, Catalog is a protocol that takes the first steps in promoting the RenVM module to build automated market making (AMM) solutions within RenVM itself. The Catalog was the first to use the “unlimited liquidity” mechanism. Regardless of which chain they exist on, this AMM design uses not only Catalog’s own liquidity pools, but also those of third-party DEXs. Catalog works with RenVM and its existing user ecosystem to support more complex transaction types within a familiar user experience.
LayerZero is a communication primitive that allows data and information to be sent across EVM chains with LayerZero endpoints. LayerZero endpoints are essentially on-chain clients. A chain with a ZRO endpoint can transact with any other chain with a ZRO endpoint. A third-party oracle service, such as Chainlink, needs to sit between the endpoints and act as a transaction and messaging security mechanism.
LayerZero ensures the validity of cross-chain communication by requiring two separate entities, Oracle and Relayer, to verify transactions
Applications deployed on various layer 1 blockchains will find this approach very simple. For example, if the Dapp is built on Polygon, using the endpoint and quickly loading the Dapp onto LayerZero is a fairly straightforward task. Decentralized applications such as Stargate use the communication standards set by LayerZero to create decentralized exchanges/bridges.
ZetaChain is a layer 1 blockchain that does not require packaged assets to transfer value across chains, nor does it require bridges for each pair of blockchains. This is achieved through Zetachain’s use of cross-chain messaging, which allows data and value to be sent across chains and layers. Utilizing full-chain smart contracts, developers can program ZetaChain to listen for and act on events on connected blockchains. ZetaChain relies on the consensus of validator nodes to protect itself and protects the private keys on the connected chain through a distributed threshold signature scheme to avoid single points of failure. PoS provides validators with an incentive to operate correctly.
What differentiates Zetachain from other competitors like LayerZero is that even blockchains without smart contracts, like Bitcoin, can be incorporated into multi-chain networks.
These bridge platforms allow for interoperability between chains and allow new ecosystems to be built on top of them. This enables new use cases other than sending tokens from Chain A to Chain B. That said, each unique mechanism of a bridge/bridge platform carries a certain level of risk.
Risks associated with bridges
Considering the technical complexity involved in cross-chain messaging, there are various risks when using bridges. Some of the main risks include:
To reduce the risk of censorship and discontinuation, users can simply limit the use of Trusted Bridges and Optimistic Bridges. However, security risks can never be completely avoided, so it is important to understand possible attack vectors to assess which security systems are healthier than others.
The two main attack vectors used to compromise bridge security are:
- Smart contract vulnerabilities;
- Root of trust vulnerability.
Bridge’s two main attack vectors
A smart contract vulnerability occurs when a malicious actor successfully attacks the application layer of the bridge. Since most bridges must deploy secure smart contracts on all chains they connect, newer blockchains are easier targets for attacks. Languages like Rust, CosmWasm, and Substrate all have growing developer communities, but they don’t have the same number of developer tools and auditing firms as mature languages like Solidity, so there’s a higher chance of bugs making it to the mainnet. When developing a bridge, if speed and competition are taken into account, it is easy to see why smart contract vulnerabilities are the most common attack vector for hackers.
As for exploiting a trusted source, these hackers need a malicious actor to successfully attack the underlying authentication method used by the bridge. In Ronin, malicious attackers attack the honest majority assumption by accessing 5 of Sky Mavis’ 9 private keys. Once hackers breached Sky Mavis’ security system, what happened next was history.
As one can see, these vulnerabilities are difficult to see from the outside, but the costs associated with security systems can be substantial. Over the past year, the cumulative cost of bridge vulnerabilities has exceeded $1.5 billion.
Notable Bridge Vulnerability Events in the Past Year
To make matters worse, unsuspecting web3 users can easily feel safer using higher TVL/TVB bridges, which appear to be powerful enough to handle a large number of token transfers; however, TVL/TVB has nothing to do with security There is no obvious correlation between them. In fact, one might argue that with an increase in TVL/TVB, there will be greater economic incentives for malicious actors to find vulnerabilities, and the security of the bridge will be at greater risk.
Therefore, understanding the underlying security system of the bridge used should be considered when transferring funds. If a retail investor needs to send 0.5 ETH quickly to secure NFT minting, then security does not need to be the highest priority. However, if a DAO plans to transfer 10,000 ETH to a contract on another chain, the underlying security of the bridge should be carefully checked.
As the cryptographic industry continues to evolve, new bridge designs will be explored, new security models will be validated, and new bridge-based applications will continue to emerge. The success of some bridges will allow for greater interconnection between protocols and communities. While there may be some short-term pain as unsafe bridges are filtered out, the future of the industry looks bright.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/detailed-explanation-of-cross-chain-bridge-mechanism-risks-and-opportunities-coexist/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.