By Dr. Andreas Freund (Co-Chair) on behalf of the EEA Community Projects L2 Standards Working Group
We live in a multi-chain world, with billions of USD in asset value locked in 100+ chains. And the owners of those blockchain assets behave just like they would with assets in traditional finance: they are looking for arbitrage opportunities to make money. However, in contrast to the world of traditional finance where assets in one country can be utilized in arbitrage plays in another country without moving assets by using trusted intermediaries, the same approach did not work for blockchains for a long time for three reasons:
- blockchains cannot talk to one another,
- arbitrage plays on a particular blockchain require that all involved assets are present on that blockchain because of the trustless nature of public blockchains,
- and there was no equivalent to the trusted intermediary as in traditional finance between trustless blockchains.
To solve the problem of capital inefficiency on blockchains, and make money in the process, enterprising individuals created blockchain bridges that addressed those three challenges and started to link the blockchain ecosystem together – yes, you can now trade bitcoin on Ethereum. Of course, bridges can be used for other types of functionality too; however, the primary function is to improve capital efficiency.
At a high level, a blockchain bridge connects two blockchains facilitating secure and verifiable communication between those blockchains through the transfer of information and/or assets.
This allows for a multitude of opportunities such as
- cross-chain transfer of assets,
- new decentralized applications (dApps), and platforms that allow users to access the strengths of various blockchains – thus enhancing their capabilities,
- and developers from different blockchain ecosystems can collaborate and build new solutions.
There are two basic types of bridges:
| Trusted Bridges | Trustless Bridges |
| Depend upon a central entity or system for their operations. | Operate using decentralized systems such as smart contracts with embedded algorithms. |
| Trust assumptions concerning funding custody and bridge security. Users mostly rely on the bridge operator’s reputation. | The security of the bridge is the same as that of the underlying blockchain. |
| Users need to give up control of their crypto assets. | Enable users to remain in control of their funds through smart contracts. |
Within both sets of trust assumptions one can distinguish different, common types of bridge designs:
- Lock, mint, and burn token bridges: Instant guaranteed finality as minting assets on the destination blockchain can occur whenever required without the possibility of a failed transaction. Users receive a synthetic, often called a wrapped asset, on the destination blockchain, not the native asset.
- Liquidity networks with pools of native assets with unified liquidity: A single asset pool on one blockchain is connected with additional asset pools on other blockchains with shared access to one another’s liquidity. This approach does not enable instant, guaranteed finality since transactions can fail if there is a lack of liquidity in the shared pools.
However, all designs, and under whatever trust assumptions, have to address two trilemmas that blockchain bridges face.
Bridging Trilemma as posited by Ryan Zarick, Stargate
Bridging protocols may only have two of the three properties below:
- Instant Guaranteed Finality: Guarantee to receive assets on the target blockchain immediately after transaction execution on the source blockchain and transaction finality on the target blockchain.
- Unified Liquidity: Single liquidity pool for all assets between source and target blockchains.
- Native Assets: Receive target blockchain assets instead of assets minted by the bridge representing the original asset on the source blockchain.
Interoperability Trilemma as posited by Arjun Bhuptani, Connext
Interoperability protocols may only have two of the three properties below:
- Trustlessness: Same security assurances as the underlying blockchain without new trust assumptions.
- Extensibility: Ability to connect different blockchains.
- Generalizability: Allows for arbitrary data messaging
Besides the trilemmas which can be addressed with clever design, the biggest challenge for blockchain bridges is security as the many hacks in 2021 and 2022 have demonstrated; be it the Wormhole, Ronin, Harmony, or Nomad incidents. And fundamentally, a bridge between blockchains is only as secure as the least secure blockchain used in the (chain of) bridge(s) for an asset. However, this latter issue is not a problem for bridges between Layer 2 platforms that are anchored on the same Layer 1 (L1) blockchain as they share the same security guarantees from their shared L1 blockchain.
Until this point, we have not specifically talked about L2 platforms that are designed to scale L1 blockchains while inheriting the L1 security guarantees, since L2s are strictly speaking a particular type of bridge: a native bridge. There are, however, several idiosyncrasies of L2 platforms when creating a bridge between L2s e.g. optimistic rollups vs. zk-rollups vs Validium rollups vs Volition rollups. These differences make them special because of the difference in trust assumptions and finality for L2s versus L1s and between different L2s.
The reason why bridges between L2s are important is the same as for L1s: L2 assets are looking for capital efficiency on other L2s, as well as portability and other functionalities.
The difference in native trust assumptions on L2 platforms can be overcome if bridged L2s are, as remarked already, anchored on the same L1. And that the bridge does not require additional trust assumptions. However, differences in L2 transaction finality on the anchor L1 make it challenging to bridge assets between L2s in a trust-minimized manner.
Digging a bit deeper into L2 bridges, we see that L2-to-L2 bridges ideally should satisfy the following criteria:
- Clients must be abstracted away from each L2 protocol they interface with through an abstraction layer – loose-coupling paradigm.
- Clients must be able to verify that the data returned from the abstraction layer is valid, ideally without changing the trust model beyond the one used by the targeted L2 protocol.
- No structural/protocol changes are required from the interfacing L2 protocol.
- Third parties must be able to independently build an interface to a targeted L2 protocol – ideally a standardized interface.
When looking at the current landscape, one sees most L2 bridges are treating L2s just like another blockchain. Note that fraud proofs as used in Optimistic rollups, and validity proofs as used in zk-rollups solutions, take the place of block headers and Merkle proofs as used in “normal” L1-to-L1 bridges.
Below we summarize the current and very varied landscape of L2 bridges with a name, brief summary, and bridge design type:
| Bridge Name | Description | Type of Design |
| Hop Exchange | Rollup-to-rollup general token bridge. It allows users to send tokens from one rollup to another almost immediately without having to wait for the rollup’s challenge period. https://hop.exchange/whitepaper.pdf | Liquidity Network (using an Automated Market Maker) |
| Stargate | Composable native asset bridge, and dApp built on LayerZero. DeFi users can swap native assets cross-chain on Stargate within a single transaction. Applications compose Stargate to create native cross-chain transactions at the application level. These cross-chain swaps are supported by the community-owned Stargate unified liquidity pools. https://www.dropbox.com/s/gf3606jedromp61/Delta-Solving.The.Bridging-Trilemma.pdf?dl=0 | Liquidity Network |
| Synapse Protocol | A token bridge leveraging a validator between chains and liquidity pools to perform cross-chain and same-chain swaps. | Hybrid (Token Bridge/Liquidity Network) |
| Across | A cross-chain optimistic bridge that uses actors called Relayers to fulfill user transfer requests on the destination chain. Relayers are later reimbursed by providing proof of their action to an Optimistic Oracle on Ethereum. The architecture leverages a single liquidity pool on Ethereum and separate deposit/reimburse pools on destination chains that are rebalanced using canonical bridges. | Liquidity Network |
| Beamer | Enables users to move tokens from one rollup to another. The user requests a transfer by providing tokens on the source rollup. Liquidity providers then fill the request and directly send tokens to the user on the target rollup. The core focus of the protocol is to be as easy to use as possible for the end user. This is achieved by separating two different concerns: the service provided to the end user, and the reclaiming of funds by the liquidity provider. The service is provided optimistically as soon as the request arrives. Being refunded on the source roll-up is secured by its own mechanism and decoupled from the actual service. | Liquidity Network |
| Biconomy Hyphen | Multi-chain relayer network utilizing smart contract-based wallets for users to interact with liquidity providers to transfer tokens between different (optimistic) L2 networks. | Liquidity Network |
| Bungee | The bridge is built on the Socket infrastructure and SDK with the Socket Liquidity Layer (SLL) as its main component. The SLL aggregates liquidity across multiple bridges and DEXs and also allows for P2P settlements. This is different from a Liquidity Pool network since this single meta-bridge allows dynamical selection and routing of funds via the best bridge as per a user’s preferences such as cost, latency, or security. | Liquidity Pool Aggregator |
| Celer cBridge | A decentralized and non-custodial asset bridge that supports 110+ tokens across 30+ blockchains and layer-2 rollups. It is built on top of the Celer Inter-chain Message Framework which is built on the Celer State Guardian Network (SGN). The SGN is a Proof-of-Stake (PoS) blockchain built on Tendermint that serves as the message router between different blockchains. | Liquidity Network |
| Connext | Dispatches and handles messages related to sending funds across chains. Custodies funds for canonical assets, fast liquidity, and stable swaps. The Connext contract uses the Diamond pattern so it comprises a set of Facets that act as logical boundaries for groups of functions. Facets share contract storage and can be upgraded separately. | Hybrid (Token Bridge/Liquidity Network) |
| Elk Finance | Uses ElkNet with features such as
|
Hybrid (Token Bridge/Liquidity Network) |
| LI.FI | A bridge and DEX aggregator that routes any asset on any chain to the desired asset on the desired chain made available on the API/Contract level through an SDK, or as an embeddable widget in a dApp | Liquidity Pool Aggregator |
| LayerSwap | Bridge for tokens from a centralized exchange account directly to a Layer 2 network (both optimistic and zk- rollups) with low fees. | Liquidity Network (using an Automated Market Maker) |
| Meson | An atomic swap application using Hash Time Lock Contracts (HTLC) using secure communications between users combined with a liquidity provider relayer network for the supported tokens. | Liquidity Network |
| O3 Swap | The O3 cross-chain mechanisms of Swap and Bridge aggregating multiple liquidity pools across chains allow for simple one-time confirmation transactions with a planned Gas Station solving the gas fee demand on each chain. | Liquidity Pool Aggregator |
| Orbiter | A decentralized cross-rollup bridge for transferring Ethereum-native assets. The system has two roles: Sender and Maker. The ‘Maker’ is required to deposit excess margin to Orbiter’s contract before they can qualify to be a cross-rollup service provider to the ‘Sender’. In the usual process, the ‘Sender’ sends assets to the ‘Maker’ on the ‘Source Network’, and the ‘Maker’ sends them back to the ‘Sender’ on the ‘Destination Network’. | Liquidity Network |
| Poly Network | Allows users to transfer assets between different blockchains using a Lock-Mint swap. It uses a PolyNetwork chain to verify and coordinate message passing between Relayers on supported chains. Each chain has a set of Relayers, while the PolyNetwork chain has a set of Keepers that sign cross-chain messages. Chains integrated with Poly Bridge need to support light client verification since validation of cross-chain messages includes verifying block headers and transactions via Merkle proofs. Some of the smart contracts used by the bridge infrastructure are not verified on Etherscan. | Token Bridge |
| Voyager (Router Protocol) | The Router Protocol uses a pathfinder algorithm to find the most optimal route to move assets from the source chain to the destination chain utilizing the Router network which is similar to Cosmos’ IBC. | Liquidity Network |
| Umbria Network | Umbria has three major protocols working together:
Both protocols work in tandem to provide asset migration between cryptocurrency networks |
Liquidity Network (using an Automated Market Maker) |
| Via Protocol | The protocol is an aggregator of chains, DEXs, and bridges to optimize asset transfer routes. This allows asset bridging in three ways:
|
Hybrid (Token Bridge/Liquidity Network) |
| Multichain | Multichain is an externally validated bridge. It uses a network of nodes running SMPC (Secure Multi-Party Computation) protocol. It supports dozens of blockchains and thousands of tokens with both Token Bridge and Liquidity Network. | Hybrid (Token Bridge/Liquidity Network |
| Orbit Bridge | Orbit Bridge is part of the Orbit Chain project. It is a cross-chain bridge that allows users to transfer tokens between supported blockchains. Tokens are deposited on the source chain and “representation tokens” are minted on the destination chain. Deposited tokens are not precisely locked and can be used in DeFi protocols by Orbit Farm. Accrued interest is not passed directly to token depositors. Bridge contract implementation and farm contract source code are not verified on Etherscan. | Token Bridge |
| Portal (Wormhole) | Portal Token Bridge is built on top of Wormhole, which is a message-passing protocol that leverages a specialized network of nodes to perform cross-chain communication. | Token Bridge |
| Satellite (Axelar) | Satellite is a token bridge powered by the Axelar network | Liquidity Network |
The L2Beat project maintains an active list of bridges relevant to L2s with the Total-Value-Locked (TVL) in the bridge as well as a description and brief risk assessment, if available.
L2 Bridges Risk Profiles
Lastly, when users utilize L2 Bridges, in fact, any bridge, care needs to be taken, and the following risks need to be evaluated for a given bridge:
Loss of Funds
- Oracles, relayers, or validators collude to submit fraudulent proofs (e,g, block hash, block header, Merkle proof, Fraud proof, Validity proof) and/or relay fraudulent transfers that are not mitigated
- Validator/Relayer private keys are compromised
- Validators maliciously mint new tokens
- False claims are not disputed in time (optimistic messaging protocols)
- A destination blockchain reorganization occurs after optimistic oracle/relayer dispute time passes (optimistic messaging protocols).
- Source code of unverified contracts involved in or used by a protocol contains malicious code or functionality that can be abused by a contract owner/administrator
- Token Bridge owners behave maliciously, or initiate time-sensitive emergency actions that impact user funds, and do not properly communicate to the user base
- Protocol contract(s) paused (if functionality exists)
- Protocol contract(s) receive a malicious code update
Freezing of Funds
- Relayers/Liquidity Providers do not act on user transactions (messages)
- Protocol contract(s) paused (if functionality exists)
- Protocol contract(s) receive a malicious code update
- Insufficient liquidity in the target token on the bridge
Censoring Users
- Oracles or relayers on either destination or target L2s or both fail to facilitate a transfer (message)
- Protocol contract(s) paused (if functionality exists)
While this list is not exhaustive, it gives a good overview of the current risks associated in using bridges.
There are new developments underway using zero-knowledge-proof (zkp) technologies designed to mitigate some of the above risk factors and address the two bridge trilemmas. In particular, the use of zkps allows for the following bridge design characteristics:
- Trustless and Secure because the correctness of block headers on the source and target blockchains can be proven by zk-SNARKs which are verifiable on EVM-compatible blockchains. Hence, no external trust assumptions are required, assuming the source and target blockchains and the utilized light-client protocols are secure and we have 1-of-N honest nodes in the relay network.
- Permissionless and Decentralized because anyone can join the bridges’ relay network, and PoS-style or similar validation schemes are not needed
- Extensible because applications can retrieve zkp-verified block headers, and execute application-specific verification and functionality
- Efficient because of new, optimized proof schemes with short proof generation and fast proof verification times
Albeit early, these types of developments promise to accelerate the maturation and security of the bridge ecosystem.
We can summarize the above discussion and overview of L2 Bridges as follows:
- L2 Bridges are an important glue of the L2 ecosystem to further L2 interoperability and efficient use of assets and applications across the ecosystem.
- L2 bridges used on L2s anchored on the same L1, such as Ethereum Mainnet, are safer than bridges between L1s – assuming the source code is safe, which is often a big if.
- As with all distributed system architectures, there are significant tradeoffs to be made, as expressed in the two posited Trilemmas – Bridging Trilemma and Interoperability Trilemma.
- L2 Bridges have very different trust assumptions, e.g., trusted vs. trustless bridges, and very different design choices, e.g., lock-mint-burn vs. liquidity networks.
- The L2 Bridges ecosystem is still nascent and in a state of flux.
- Users are advised to do their due diligence to assess which L2 bridges offer the best risk-reward profile for their needs.
- There are new developments underway using recent zkp-technologies that are effectively addressing the two bridge trilemmas, and help to increase the security of bridges overall.
While still early in the journey towards a standardized L2 interoperability framework, these are important developments, and need to be taken seriously as any one of those projects might become “THE” bridge framework – it is not yet VHS vs Betamax, but we are getting there.
The L2 WG would like to gratefully acknowledge Tas Dienes (Ethereum Foundation), Daniel Goldman (Offchain Labs), Bartek Kiepuszewski (L2Beat) for a careful reading of the manuscript and invaluable content suggestions.
