Comparing 23 cross-chain bridges, gaining insights into the current state of L2 bridges

Original Title: The Current State of Layer 2 Bridges

Author: Andreas Freund

Original Compilation: Kyle, The Way of DeFi

We live in a multichain world, with billions of dollars worth of assets locked across more than 100 chains. The behavior of these blockchain asset owners resembles that of their assets in traditional finance: they are seeking arbitrage opportunities to make money. However, unlike the traditional financial world, where assets from one country can be used in arbitrage activities in another country without transferring assets through trusted intermediaries, the same approach has not worked for a long time in blockchain for three main 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 traditional trusted intermediaries between trustless blockchains.

To address the issue of capital inefficiency on blockchains and make money in the process, enterprising individuals have created blockchain bridges to tackle these three challenges and begin connecting the blockchain ecosystem—yes, you can now trade Bitcoin on Ethereum. Of course, cross-chain bridges can also be used for other types of functions; however, the primary function is to enhance capital efficiency.

What is a Blockchain Bridge?

At a high level, a blockchain bridge connects two blockchains, facilitating secure and verifiable communication between them through the transfer of information and/or assets.

This provides many opportunities, such as cross-chain asset transfers, new decentralized applications (dApps), and platforms that allow users to access the advantages of various blockchains—thereby enhancing their capabilities, enabling developers from different blockchain ecosystems to collaborate and build new solutions.

There are two basic types of bridges:

1. Trusted Bridges

These rely on a central entity or system to operate. Trust assumptions regarding fund custody and bridge security. Users primarily rely on the reputation of the bridge operator. Users need to relinquish control over their crypto assets.

2. Trustless Bridges

These operate using decentralized systems, such as smart contracts with embedded algorithms. The security of the bridge is equivalent to the security of the underlying blockchain. This allows users to control their funds through smart contracts.

Within these two sets of trust assumptions, we can distinguish between different common cross-chain bridge design types:

Lock-Mint-Burn Token Bridges: Provide instant finality guarantees, as the minted assets on the target blockchain can occur when needed without the possibility of transaction failure. Users receive a synthetic asset on the target blockchain, often referred to as a wrapped asset, rather than a native asset. Liquidity networks with a unified liquidity pool of native assets: A single asset pool on one blockchain connects with other asset pools on other blockchains, sharing access to each other's liquidity. This approach cannot achieve instant, guaranteed finality, as transactions may fail if there is a lack of liquidity in the shared pool.

However, all designs, regardless of any trust assumptions, must address two challenges faced by blockchain bridges.

The Bridging Trilemma proposed by Ryan Zarick of Stargate

Bridge protocols can only have two of the following three attributes:

Instant finality guarantee: Ensures that assets are immediately received on the target blockchain after a transaction is executed on the source blockchain and finalized on the target blockchain.

Unified liquidity: A single liquidity pool for all assets between the source and target blockchains. Native assets: Receive assets on the target blockchain rather than assets minted by the bridge representing the original assets on the source blockchain.

The Interoperability Trilemma proposed by Arjun Bhuptani of Connext

Interoperability protocols can only have two of the following three attributes:

Trustless: Same security guarantees as the underlying blockchains, with no new trust assumptions.

Scalability: The ability to connect different blockchains.

Generality: Allows arbitrary data messaging.

In addition to the trilemmas that can be addressed through clever design, the biggest challenge for blockchain bridges is security, as evidenced by numerous hacking incidents in 2021 and 2022; whether it be Wormhole, Ronin, Harmony, or Nomad events. Fundamentally, bridges between blockchains are only as secure as the least secure blockchain used in the bridging (chain). However, for bridges between Layer 2 (L2) platforms anchored on the same Layer 1 (L1) blockchain, this latter issue is not a concern, as they share the same security guarantees from the shared L1 blockchain.

Why Are Cross-Chain Bridges Important for L2?

So far, we have not specifically discussed L2 platforms designed to scale L1 blockchains while inheriting L1 security guarantees, as L2 is strictly a specific type of bridge: a native bridge. However, when creating bridges between L2s, L2 platforms have certain characteristics, such as optimistic rollups vs. zk-rollups vs. Validium rollups vs. Volition rollups. These differences make them particularly unique, as there are differences in trust assumptions and finality between L2s and between L2s and L1s.

The importance of bridges between L2s is the same as that of L1s: L2 assets are seeking capital efficiency from other L2s, as well as portability and other functionalities.

As mentioned earlier, if the bridged L2s are anchored on the same L1, the differences in local trust assumptions on L2 platforms can be overcome. Moreover, this bridge does not require additional trust assumptions. However, the differences in finality of L2 transactions anchored on L1 make it challenging to bridge assets between L2s in a trust-minimized manner.

Types of L2 Blockchain Bridges: An Overview

Delving deeper into L2 bridges, we find that L2-L2 bridges ideally should meet the following criteria:

Clients must abstract from each L2 protocol they connect to through an abstraction layer—loose coupling paradigm.

Clients must be able to verify the validity of the data returned from the abstraction layer, ideally without changing the trust model to that used by the target L2 protocol.

Interface L2 protocols do not require structural/protocol changes.

Third parties must be able to independently build interfaces for the target L2 protocol—ideally standardized interfaces.

Currently, most L2 bridges treat L2 as another blockchain. Note that the fraud proofs used in optimistic rollups and the validity proofs used in zk-rollups replace the block headers and Merkle proofs used in "normal" L1 to L1 bridging.

Current Landscape of L2 Bridges

Below we summarize the current and highly diverse landscape of L2 bridges, including names, brief summaries, and bridge design types:

1. Hope Exchange

Description: A rollup-rollup universal token bridge. It allows users to almost instantly send tokens from one rollup to another without waiting for the rollup's challenge period.

https://hop.exchange/whitepaper.pdf

Design Type: Liquidity Network (uses an AMM)

2. Stargate

Description:

A composable native asset bridge and dApp built on LayerZero. DeFi users can cross-chain swap native assets on Stargate in a single transaction. Applications compose Stargate to create native cross-chain transactions at the application level. These cross-chain swaps are supported by a community-owned Stargate unified liquidity pool.

Design Type: Liquidity Network

3. Synapse Protocol

Description:

A token bridge that utilizes validators between chains and liquidity pools to execute cross-chain and same-chain swaps.

Design Type: Hybrid Design (Token Bridge/Liquidity Network)

4. Across

Description:

A cross-chain optimistic bridge that uses participants called relayers to fulfill user transfer requests on the target chain. Relayers are then compensated by providing proof of their actions to the Optimistic oracle on Ethereum. This architecture leverages a single liquidity pool on Ethereum and independent deposit/repayment pools on the target chain, which are rebalanced using normative bridges.

Design Type: Liquidity Network

5. Beamer

Description:

Enables users to move tokens from one rollup to another. Users request transfers by providing tokens on the source rollup. Liquidity providers then fill the request and send tokens directly to users on the target rollup. The core focus of the protocol is to make it as convenient as possible for end users. This is achieved by separating two different concerns: the service provided to end users and the liquidity providers' recovery of funds. Once a request arrives, service is optimistically provided. Refunds on the source rollup are guaranteed by its own mechanisms and are separated from the actual service.

6. Biconomy Hyphen

Description:

A multichain relay network that utilizes smart contract-based wallets for users to interact with liquidity providers to transfer tokens between different (Optimistic) L2 networks.

Design Type: Liquidity Network

7. Bungee

Description:

This bridge is built on socket infrastructure and SDK, with the Socket Liquidity Layer (SLL) as its main component. SLL aggregates liquidity from multiple bridges and DEXs and also allows for P2P settlement. This differs from liquidity pool networks because this single meta-bridge allows for dynamic selection and routing of funds through the best bridge based on user preferences (e.g., cost, latency, or security).

Design Type: Liquidity Pool Aggregator

8. Celer cBridge

Description:

A decentralized non-custodial asset bridge that supports over 110 tokens across more than 30 blockchains and L2 rollups. It is built on the Celer inter-chain messaging framework, which 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: Liquidity Network

9. Connext

Description:

Schedules and processes messages related to cross-chain fund transfers. A custodial fund for standardizing assets, fast liquidity, and stable exchanges. Connext contracts use a diamond pattern, so it contains a set of facets that act as logical boundaries for functional groups. Facets share contract storage and can be upgraded individually.

Design Type: Hybrid Design (Token Bridge/Liquidity Network)

10. Elk Finance

Description:

Uses ElkNet with the following features:

Cross-chain utility token ($ELK) for value transfer with secure and reliable transmission across all blockchains supported by Elk in seconds. Bridging as a service (BaaS) provides infrastructure for developers to leverage ElkNet for custom bridging solutions. Cross-chain exchanges between all connected blockchains provide impermanent loss protection (ILP) for our liquidity providers. Unique capabilities and characteristics of non-fungible tokens (Moose NFT).

Design Type: Hybrid Design (Token Bridge/Liquidity Network)

11. LI.FI

Description:

A bridge and DEX aggregator that routes any asset on any chain to the desired asset on the desired chain, provided at the API/contract level through an SDK or as an embeddable widget in a dApp.

Design Type: Liquidity Pool Aggregator

12. LayerSwap

Description:

Bridges tokens directly from centralized exchange accounts to Layer 2 (L2) networks (Optimistic and zk-rollups) at low fees.

Design Type: Liquidity Network (uses an AMM)

13. Meson

Description:

An atomic swap application using hash time-locked contracts (HTLC), combining secure communication between users with a liquidity provider relay network for supported tokens.

Design Type: Liquidity Network

14. O3 Swap

Description:

O3's Swap and Bridge cross-chain mechanism aggregates multiple liquidity pools across chains, allowing for simple one-time confirmation transactions with planned gas stations to address gas fee requirements on each chain.

Design Type: Liquidity Pool Aggregator

15. Orbiter

Description:

A decentralized cross-rollup bridge for transferring Ethereum native assets. The system has two roles: Sender and Maker. The "Maker" must first deposit excess collateral into Orbiter's contract to qualify as a cross-rollup service provider for the "Sender." In the usual process, the "Sender" sends assets to the "Maker" on the "Source Network," and the "Maker" sends the assets back to the "Sender" on the "Destination Network."

Design Type: Liquidity Network

16. Poly Network

Description:

Allows users to exchange assets between different blockchains using Lock-Mint. It uses the Poly Network chain to verify and coordinate messaging between relayers on supported chains. Each chain has a set of Relayers, while the Poly Network chain has a set of Keepers for signing cross-chain messages. Chains integrated with Poly Bridge need to support light client verification, as the validation 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)

Description:

The Router Protocol uses pathfinding algorithms to find the best route, utilizing a router network similar to Cosmos's IBC to move assets from the source chain to the target chain.

Design Type: Liquidity Network

18. Umbria Network

Description:

Umbria has three main protocols working together:

A cross-chain asset bridge; supports the transfer of assets between other incompatible blockchains and cryptocurrency networks.

A staking pool where users can earn interest on their crypto assets by providing liquidity to the bridge. Liquidity providers of UMBR earn 60% of all fees generated by the bridge.

A decentralized exchange (DEX); an automated liquidity protocol supported by a constant product formula, deployed using smart contracts and fully managed on-chain.

The two protocols work together to facilitate asset migration between cryptocurrency networks.

Design Type: Liquidity Network (uses an AMM)

19. Via Protocol

Description:

This protocol is an aggregator of chains, DEXs, and bridges for optimizing asset transfer paths. This allows for asset bridging in three ways:

Multiple transactions on different blockchains.

A single transaction through a decentralized bridge integrated with a DEX.

A single transaction through a semi-decentralized bridge that triggers a second transaction on the target chain.

Design Type: Hybrid Design (Token Bridge/Liquidity Network)

20. Multichain

Description:

Multichain is an externally verified 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

Description:

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 held on the source chain, and "representative tokens" are minted on the target chain. The deposited tokens are not precisely locked, and Orbit Farm can be used in DeFi protocols. Accrued interest is not directly passed to token depositors. The bridge contract implementation and Farm contract source code are not verified on Etherscan.

Design Type: Token Bridge

22. Portal (Wormhole)

Description:

The Portal Token Bridge is built on Wormhole, a messaging protocol that utilizes a dedicated network of nodes to perform cross-chain communication.

Design Type: Token Bridge

23. Satellite (Axelar)

Description:

Satellite is a token bridge supported by the Axelar network.

Design Type: Liquidity Network

The L2Beat project maintains a list of blockchain bridges related to L2, along with their total value locked (TVL), descriptions, and brief risk assessments (if any).

L2 Bridge Risk Overview

Finally, when users utilize L2 bridges, in fact, any bridge requires caution, and the following risks need to be assessed for a given bridge:

Loss of Funds

Collusion by oracles, relayers, or validators submitting fraudulent proofs (e.g., block hashes, block headers, Merkle proofs, fraud proofs, validity proofs) and/or relaying unmitigated fraudulent transfers.

Leakage of validator/relayer private keys.

Malicious minting of new tokens by validators.

False claims not timely disputed (Optimistic messaging protocol).

Reorganization of the target blockchain occurs after the dispute time for the Optimistic oracle/relayer has passed (Optimistic messaging protocol).

Unverified contract source code involved in or used by the protocol contains malicious code or functions that can be abused by contract owners/admins.

Misconduct by token bridge owners or initiating time-sensitive emergency actions affecting user funds without proper communication with the user base.

Protocol contracts are paused (if functionality exists).

Protocol contracts receive malicious code updates.

Frozen Funds

Relayers/liquidity providers do not act on user transactions (messages).

Protocol contracts are paused (if functionality exists).

Protocol contracts receive malicious code updates.

Insufficient liquidity for target tokens on the bridge.

User Censorship

Oracles or relayers on the target or target L2, or both, fail to facilitate transfers (messages).

Protocol contracts are paused (if functionality exists).

While this list is not exhaustive, it provides a good overview of the relevant risks associated with using bridges.

New developments using zero-knowledge proof (ZKP) technology are underway, aimed at mitigating some of the above risk factors and addressing the two bridge trilemmas. In particular, the use of ZKP allows for the following bridge design features:

Trustless and secure, as the correctness of block headers on the source and target blockchains can be proven through zk-SNARKs, which can be verified on EVM-compatible blockchains. Therefore, no external trust assumptions are needed, assuming the source and target blockchains and the light client protocols used are secure, and we have 1-of-N honest nodes in the relay network.

Permissionless and decentralized, as anyone can join the bridge's relay network, and no PoS-style or similar verification schemes are required.

Scalable, as applications can retrieve ZKP-verified block headers and perform application-specific verification and functionality.

Efficient, as new, optimized proof schemes have shorter proof generation and fast proof verification times.

Although it is still early, these types of developments are expected to accelerate the maturity and security 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 entire ecosystem.

L2 bridges used on L2s anchored on the same L1, such as the Ethereum mainnet, are more secure than bridges between L1s—assuming the source code is secure, which is often a significant assumption.

Like all distributed system architectures, important trade-offs must be made, as expressed by the two assumed trilemmas—the blockchain bridge trilemma and the interoperability trilemma.

L2 bridges have very different trust assumptions, such as trusted vs. trustless bridges, and very different design choices, such as lock-mint-burn vs. liquidity networks.

The L2 bridges ecosystem is still in its early stages and is in a state of constant change.

Users are advised to conduct due diligence to assess which L2 bridges can provide the best risk-return profile to meet their needs.

New developments using the latest ZKP technology are underway, effectively addressing the two bridge trilemmas and contributing to the overall security of bridges.

Special thanks to Tas Dienes (Ethereum Foundation), Daniel Goldman (Offchain Labs), and Bartek Kiepuszewski (L2Beat) for carefully reviewing the manuscript and providing valuable content suggestions.