Original title: The Current State of Layer 2 Bridges
By Andreas Freund
Original compilation: Kyle, the way of DeFi
We live in a multi-chain world, with billions of dollars of asset value locked in over 100 chains. And the owners of these blockchain assets behave just like they would in traditional finance: they are looking for arbitrage opportunities to make money. However, unlike the traditional financial world, where assets in one country can be used in arbitrage activities in another country without having to move assets through a trusted intermediary, the same approach has not worked for blockchain for a long time, for three reasons:
1) Blockchains cannot communicate with each other;
2) Due to the trustless nature of public blockchains, arbitrage on a specific blockchain requires all relevant assets to exist on that blockchain;
3) And there are no trusted intermediaries in traditional finance between trustless blockchains.
In order to solve the problem of capital inefficiency on the blockchain, and make money in the process, enterprising individuals created blockchain bridges to address these three challenges and began connecting blockchain ecosystems together - yes, you can now trade Bitcoin on Ethereum. Of course, cross-chain bridges can also be used for other types of functions; however, the main function is to improve capital efficiency.
What is a blockchain bridge?
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 opens up many opportunities such as cross-chain transfer of assets, new decentralized applications (dApps) and platforms that allow users to access the strengths of various blockchains — thereby empowering them, and developers from different blockchain ecosystems can collaborate and build new solutions.
There are two basic types of bridges:
1. Trusted Bridge
Reliance on a central entity or system to operate. Trust assumptions regarding custody of funds and security of the bridge. Users rely primarily on the reputation of the bridge operator. Users need to relinquish control of their crypto assets.
2. No need for a trusted bridge
Operates using decentralized systems such as smart contracts with embedded algorithms. The security of the bridge is the same as that of the underlying blockchain. Enables users to control their funds through smart contracts.
Within two sets of trust assumptions, we can distinguish different common types of cross-chain bridge designs:
Locking, Minting, and Destroying Token Bridges: Instant guaranteed finality, as minting assets on the target blockchain can occur when needed without the possibility of transaction failure. Users receive a synthetic asset, often called a wrapped asset, on the target blockchain, rather than a native asset. Liquidity Networks with Local Pools of Assets with Unified Liquidity: A single pool of assets on one blockchain is connected to other pools of assets on other blockchains, sharing access to each other's liquidity. This approach does not achieve instant, guaranteed finality, as transactions may fail if there is a lack of liquidity in the shared pool.
However, all designs, and under any trust assumptions, must address two challenges facing blockchain bridges.
The Bridging Trilemma by Ryan Zarick of Stargate
A bridge protocol may have only two of the following three properties:
Instant finality: Guaranteed receipt of assets on the target blockchain immediately after the transaction is executed on the source blockchain and finalized on the target blockchain.
Unified Liquidity: A single liquidity pool for all assets between source and target blockchains. Native Assets: Receive target blockchain assets instead of bridge-minted assets that represent native assets on the source blockchain.
The Interoperability Trilemma by Arjun Bhuptani of Connext
An interoperability protocol may have only two of the following three properties:
Trustless: Same security guarantees as the underlying blockchain, with no new trust assumptions.
Scalability: The ability to connect different blockchains.
Generality: Allows arbitrary data messaging
Aside from the trilemma, which can be solved through clever design, the biggest challenge for blockchain bridges is security, as evidenced by the many hacks that occurred in 2021 and 2022; be it the Wormhole, Ronin, Harmony, or Nomad incidents. Fundamentally, a bridge between blockchains is only as secure as the least secure blockchain used in the assets being bridged (chains). However, the latter issue is not a problem for bridges between Layer 2 (L2) platforms anchored on the same Layer 1 (L1) blockchain, as they share the same security guarantees from the shared L1 blockchain.
Why are cross-chain bridges important for L2?
So far, we haven’t specifically discussed L2 platforms that aim to extend L1 blockchains while inheriting L1 security guarantees, because L2 is strictly a specific type of bridge: a native bridge. However, when creating bridges between L2s, there are some peculiarities of L2 platforms, such as optimistic rollups vs. zk-rollups vs Validium rollups vs Volition rollups. These differences make them special because of differences in trust assumptions and finality between L2 and L1, and between different L2s.
Bridges between L2s are important for the same reasons as L1s: L2 assets are looking to other L2s for capital efficiencies, as well as portability and other features.
As mentioned earlier, differences in native trust assumptions on L2 platforms can be overcome if the bridged L2 is anchored on the same L1. And the bridge does not require additional trust assumptions. However, differences in L2 transaction finality on the anchored L1 make it challenging to bridge assets between L2s in a trust-minimized manner.
Types of L2 Blockchain Bridges: An Overview
Looking deeper into L2 bridges, we find that an L2-L2 bridge should ideally meet the following criteria:
Clients must be abstracted from each L2 protocol they connect to through an abstraction layer - a loosely coupled paradigm.
The client must be able to verify that the data returned from the abstraction layer is valid, ideally without having to change the trust model to that used by the target L2 protocol.
No architectural/protocol changes are required for interface L2 protocols.
Third parties must be able to independently build interfaces to target L2 protocols—ideally standardized interfaces.
As it stands, one will find that most L2 bridges treat L2 as just another blockchain. Note that fraud proofs used in optimistic rollups and validity proofs used in zk-rollups solutions replace the block headers and Merkle proofs used in "normal" L1 to L1 bridges.
Current L2 Bridge Landscape
Below we summarize the current and very diverse landscape of L2 bridges, including names, brief summaries, and bridge design types:
1.Hope Exchange
Description: Rollup-rollup universal token bridge. It allows users to send tokens from one rollup to another rollup almost instantly without waiting for the rollup's challenge period.
https://hop.exchange/whitepaper.pdf
Design type: Liquidity network (using an AMM)
2.Stargate
describe:
Composable native asset bridges and dApps built on LayerZero. DeFi users can swap native assets across chains on Stargate in a single transaction. Applications compose Stargate to create native cross-chain transactions at the application level. These cross-chain swaps are backed by the community-owned Stargate unified liquidity pool.
Design Type: Liquid Network
3.Synapse Protocol
describe:
A token bridge that leverages validators between chains and liquidity pools to perform cross-chain and same-chain swaps.
Design Type: Hybrid Design (Token Bridge/Liquidity Network)
4.Across
describe:
A cross-chain Optimistic bridge that uses participants called relayers to fulfill user transfer requests on the target chain. Relays are then compensated by providing proof of their actions to the Optimsitic oracle on Ethereum. The architecture utilizes a single liquidity pool on Ethereum and separate deposit/repayment pools on the target chain that are rebalanced using the canonical bridge.
Design Type: Liquid Network
5.Beamer
describe:
Enables users to move tokens from one rollup to another. Users request a transfer by providing tokens on the source rollup. Liquidity providers then fill the request and send the tokens directly to the user on the target rollup. The core focus of the protocol is to make it as easy as possible for the end user. This is achieved by separating two different concerns: the service provided to the end user, and the recovery of funds by liquidity providers. The service is optimistically provided as soon as the request arrives. Refunds to the source rollup are guaranteed by its own mechanism and are separated from the actual service.
6.Biconomy Hyphen
describe:
The multi-chain relay network utilizes a smart contract-based wallet for users to interact with liquidity providers and transfer tokens between different (Optimistic) L2 networks.
Design Type: Liquid Network
7. Bungee
describe:
The bridge is built on top of the Socket infrastructure and SDK, with the Socket Liquidity Layer (SLL) as its main component. The SLL aggregates liquidity from multiple bridges and DEXs, and also allows P2P settlement. This is different from a network of liquidity pools, as this single metabridge allows funds to be dynamically selected and routed through the best bridge based on user preferences (such as cost, latency, or security).
Design Type: Liquidity Pool Aggregator
8.Celer cBridge
describe:
A decentralized non-custodial asset bridge that supports more than 110 tokens across 30+ blockchains and L2 rollups. It is built on the Celer inter-chain messaging framework, which in turn is built on the Celer State Guardian Network (SGN). SGN is a Proof-of-Stake (PoS) blockchain built on Tendermint that acts as a message router between different blockchains.
Design Type: Liquid Network
9.Connext
describe:
Dispatching and processing messages related to sending funds across chains. Escrow funds for regulated assets, fast liquidity, and stable exchange. The Connext contract uses a diamond pattern, so it contains a set of Facets that act as logical boundaries for groups of functionality. Facets share contract storage and can be upgraded individually.
Design Type: Hybrid Design (Token Bridge/Liquidity Network)
10.Any Finance
describe:
Use ElkNet with the following features:
Cross-chain utility token ($ELK) for value transfer Secure and reliable transfers compared to traditional bridges Cross-chain value transfers in seconds via ElkNet between all blockchains supported by Elk Bridge-as-a-Service (BaaS) Provides infrastructure for developers to implement custom bridge solutions leveraging ElkNet Cross-chain swaps between all connected blockchains Indemnity Loss Protection (ILP) for our liquidity providers Non-fungible tokens with unique capabilities and properties (Moose NFTs)
Design Type: Hybrid Design (Token Bridge/Liquidity Network)
11.LI.FI
describe:
Bridge and DEX aggregator that routes any asset on any chain to the desired asset on the desired chain, available at the API/contract level via SDK or as an embeddable widget in a dApp
Design Type: Liquidity Pool Aggregator
12.LayerSwap
describe:
Bridge tokens from centralized exchanges directly to Layer 2 (L2) networks (Optimistic and zk-rollups) at low fees.
Design type: Liquidity network (using an AMM)
13.Meson
describe:
An atomic swap application using Hashed Time Lock Contracts (HTLCs) for supported tokens using secure communications between users combined with a liquidity provider relay network.
Design Type: Liquid Network
14.O3 Swap
describe:
O3's Swap and Bridge cross-chain mechanisms aggregate multiple liquidity pools across chains, allowing simple one-time confirmation transactions with planned gas stations to solve the gas fee requirements on each chain.
Design Type: Liquidity Pool Aggregator
15.Orbiter
describe:
A decentralized cross-rollup bridge for transferring Ethereum native assets. The system has two roles: Sender and Maker. "Maker" must first deposit excess margin into Orbiter's contract before it is eligible to become a cross-rollup service provider for "Sender". In the usual process, "Sender" sends assets to "Maker" on the "Source Network", and "Maker" sends assets back to "Sender" on the "Destination Network".
Design Type: Liquid Network
16.Poly Network
describe:
Allows users to transfer assets between different blockchains using Lock-Mint swaps. It uses the Poly Network chain to verify and coordinate message passing between relayers on supported chains. Each chain has a set of Relayers, and the Poly Network chain has a set of Keepers, which are used to sign cross-chain messages. Chains integrated with Poly Bridge need to support light client verification, as verification of cross-chain messages includes verifying block headers and transactions through Merkle proofs. Some smart contracts used by the bridge infrastructure are not verified on Etherscan.
Design Type: Token Bridge
17.Voyager (Router Protocol)
describe:
The Router Protocol uses a pathfinding algorithm to find the best path to move assets from the source chain to the target chain using a router network similar to Cosmos’ IBC.
Design Type: Liquid Network
18.Umbria Network
describe:
Umbria has three main protocols working together:
Cross-chain asset bridge; supports the transfer of assets between otherwise incompatible blockchains and cryptocurrency networks.
A staking pool where users can earn interest on their crypto assets by providing liquidity to the bridge. UMBR liquidity providers earn 60% of all fees generated by the bridge.
Decentralized Exchange (DEX); Automated Liquidity Protocol powered by a constant product formula, deployed using smart contracts and managed entirely on-chain.
The two protocols work together to provide asset migration between cryptocurrency networks.
Design type: Liquidity network (using an AMM)
19. Via Protocol
describe:
The protocol is an aggregator of chains, DEXs, and bridges to optimize asset transfer paths. This allows asset bridging in three ways:
Conduct multiple transactions on different blockchains
Conduct a transaction through a decentralized bridge integrated with a DEX
A transaction through a semi-centralized bridge will trigger a second transaction on the target chain
Design Type: Hybrid Design (Token Bridge/Liquidity Network)
20.Multichain
describe:
Multichain is an externally validated bridge. It uses a network of nodes running the SMPC (Secure Multi-Party Computation) protocol. It supports dozens of blockchains and thousands of tokens through token bridges and liquidity networks.
Design Type: Hybrid Design (Token Bridge/Liquidity Network)
21.Orbit Bridge
describe:
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 "representative tokens" are minted on the target chain. The 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. The bridge contract implementation and Farm contract source code are not verified on Etherscan.
Design Type: Token Bridge
22.Portal (Wormhole)
describe:
Portal Token Bridge is built on Wormhole, a messaging protocol that leverages a specialized network of nodes to perform cross-chain communication.
Design Type: Token Bridge
23.Satellite (Axelar)
describe:
Satellite is a token bridge powered by the Axelar Network
Design Type: Liquid Network
The L2Beat project maintains a list of L2-related blockchain bridges, along with their total value locked (TVL), a description and a brief risk assessment (if any).
L2 Bridge Risk Profile
Finally, users need to be careful when using an L2 bridge, and really, any bridge, and need to assess the following risks for a given bridge:
Loss of funds
Oracles, relayers, or validators collude to submit fraudulent proofs (e.g., block hashes, block headers, Merkle proofs, fraud proofs, validity proofs) and/or relay unmitigated fraudulent transfers
Validator/Relay private key leaked
Validators maliciously mint new tokens
Failure to timely dispute false claims (Optimistic Messaging Protocol)
The target blockchain reorganization occurs after the Optimistic oracle/relay dispute time has passed (Optimistic messaging protocol).
Unverified contract source code involved or used in the protocol contains malicious code or functionality that can be abused by contract owners/administrators
Token bridge owners misbehave or initiate time-sensitive emergency actions that affect user funds and fail to communicate appropriately with the user base
The protocol contract is suspended (if the function exists)
The protocol contract received a malicious code update
Freeze funds
Relayers/liquidity providers do not take action on user transactions (messages)
The protocol contract is suspended (if the function exists)
The protocol contract received a malicious code update
Insufficient liquidity of target token on the bridge
Review users
The oracle or relay on the target or target L2 or both cannot facilitate the transfer (message)
The protocol contract is suspended (if the function exists)
While this list is not exhaustive, it provides a good overview of the risks associated with current bridge use.
New developments using zero-knowledge proof (ZKP) technology are underway that aim to mitigate some of the risk factors listed above and address both bridge challenges. In particular, the use of ZKPs allows for the following bridge design features:
Trustless and secure, as the correctness of the block headers on the source and target blockchains can be proven via zk-SNARKs, which can be verified on an EVM-compatible blockchain. Therefore, no external trust assumptions are required, assuming that the source and target blockchains and the light client protocol used are secure and that we have 1-of-N honest nodes in the relay network.
Permissionless and decentralized, since anyone can join the bridge’s relay network and no PoS-style or similar verification schemes are required Scalable, since applications can retrieve ZKP-verified block headers and perform application-specific verification and functionality Efficient, since the new, optimized proof scheme has short proof generation and fast proof verification times
Although early, these types of developments are expected to accelerate the maturity and safety of the bridge ecosystem.
Summary
We can summarize the above discussion and overview of L2 bridges as follows:
L2 Bridges are an important glue for the L2 ecosystem, further facilitating L2 interoperability and the efficient use of assets and applications across the ecosystem.
L2 bridges used on L2 anchored on the same L1, such as Ethereum mainnet, are more secure than bridges between L1s - assuming the source code is secure, which is often a big assumption.
As with all distributed system architectures, there are important trade-offs to make, as expressed in two hypothetical trilemmas – the blockchain bridge trilemma and the 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 in its early stages and in a state of flux.
Users are advised to perform due diligence to evaluate which L2 bridges offer the best risk-reward profile for their needs.
New developments are underway using the latest ZKP technologies that effectively solve both bridge trilemmas and help improve the overall safety of bridges.
Many thanks to Tas Dienes (Ethereum Foundation), Daniel Goldman (Offchain Labs), and Bartek Kiepuszewski (L2Beat) for carefully reading the manuscript and providing valuable suggestions for content.