Compare 23 Cross-chain bridges to gain an in-depth understanding of the status quo of L2 bridges

This article is machine translated
Show original

Original title: The Current State of Layer 2 Bridges

By Andreas Freund

Original compilation: Kyle, the way of DeFi

We live in a Multichain world, with billions of dollars in asset value locked on more than 100 chains. And the owners of these blockchain assets behave just like their assets 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 moving assets through a trusted intermediary, the same approach has worked for a long time Neither blockchain works, for three reasons:

1) Blockchains cannot communicate with each other;

2) Due to the trustless nature of public blockchains, arbitrage on a particular blockchain requires all relevant assets to exist on that blockchain;

3) And there is no trusted intermediary in traditional finance between trustless blockchains.

In order to solve the capital inefficiency problem on the blockchain, and make money in the process, enterprising individuals created blockchain bridges to address these three challenges and began to connect the blockchain ecosystem 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 these 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 advantages of various blockchains - thereby empowering them, from different blockchain ecosystems of developers can collaborate and build new solutions.

There are two basic types of bridges:

1. Trusted Bridge

Reliance on a central entity or system for operation. Trust assumptions about the custody of funds and the safety of bridges. Users mainly rely on the reputation of the bridge operator. Users need to relinquish control over their crypto assets.

2. No trust bridge required

Operate using decentralized systems, such as smart contracts with embedded algorithms. The security of the bridge is the same as that of the underlying blockchain. Enable 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 Burning Token Bridge: Instant guaranteed finality, as minting assets on the target blockchain can happen when needed without the possibility of transaction failure. Instead of native assets, users receive a synthetic asset, often called a wrapped asset, on the target blockchain. A Liquidity network of local asset pools with unified Liquidity : A single asset pool on one blockchain connects to other asset pools on other blockchains, sharing access to each other's Liquidity. This approach does not allow for 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 assumption, must address two difficult problems facing blockchain bridges.

The Cross-chain Trilemma by Ryan Zarick of Stargate

A bridge protocol may have only two of the following three properties:

Instant Guaranteed Finality: Guaranteed to receive assets on the target blockchain immediately after the transaction on the source blockchain is executed and the transaction on the target blockchain is finalized.

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 representing the original assets on the source blockchain.

The Interoperability Trilemma by Connext's Arjun Bhuptani

An interoperability agreement may have only two of the following three properties:

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

Scalability: the ability to connect different blockchains.

Generality: Allows arbitrary data messaging

Aside from the trilemma that can be solved by clever design, the biggest challenge for blockchain bridges is security, as evidenced by the many hacks in 2021 and 2022; be it Wormhole, Ronin, Harmony or Nomad event. Fundamentally, bridges between blockchains are only as secure as the least secure blockchain used in the asset's bridge (chain). However, the latter issue is not an issue for bridges between layer 2 (L2) platforms anchored on the same layer 1 (L1) blockchain, since they share the same ASD.

Why are Cross-chain bridges important to L2?

So far, we haven't specifically discussed L2 platforms designed to extend L1 blockchains while inheriting L1 security guarantees, because L2 is strictly a specific type of bridge: a local bridge. However, when creating bridges between L2s, there are some features 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 L2s and L1s and between different L2s.

Bridges between L2s are important for the same reasons as L1s: L2 assets are seeking the capital efficiencies of other L2s, along with portability and other capabilities.

As mentioned earlier, differences in local trust assumptions on L2 platforms can be overcome if the bridged L2s are anchored on the same L1. And the bridge requires no additional trust assumptions. However, differences in the 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

Digging deeper into L2 bridges, we found that an L2-L2 bridge should ideally meet the following criteria:

Clients must be abstracted from each L2 protocol to which they are connected via an abstraction layer - the loosely coupled paradigm.

The client must be able to verify that the data returned from the abstraction layer is valid, ideally without changing the trust model to that used by the target L2 protocol.

Interface L2 protocol requires no structural/protocol changes.

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

From the current situation, one will find that 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 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 types of bridge designs:

1. Hope Exchange

Description: Rollup- Rollup universal Token bridge. It Rollup users to send tokens from one Rollup to another 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 bridge and Dapp built on LayerZero. DeFi users can exchange native assets Cross-chain on Stargate in a single transaction. Applications form 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: Liquidity Network

3. Synapse Protocol

describe:

A token bridge that uses validators between chains and Liquidity pools to perform Cross-chain and same-chain exchanges.

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. Relayers are then compensated by providing proofs of their actions to Optimsitic oracles on Ethereum. The architecture utilizes a single Liquidity pool on Ethereum and separate deposit/repayment pools on the target chain that are rebalanced using a canonical bridge.

Design Type: Liquidity Network

5.Beamer

describe:

Enables users to move tokens from one Rollup to Rollup. A user requests a transfer by providing a Token on the source Rollup . The Liquidity Provider then fills in the request and sends the token 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 distinct concerns: services provided to end users, and Liquidity Provider recovering funds. As soon as the request arrives, it is served optimistically. Refunds for source Rollup are guaranteed by their own mechanism, separate from the actual service.

6. Biconomy Hyphen

describe:

The Multichain relay network utilizes smart contract-based wallets for users to interact with Liquidity Provider and transfer tokens between different (Optimistic) L2 networks.

Design Type: Liquidity 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. SLL pools the Liquidity of multiple bridges and DEXs, and also allows P2P settlement. This differs from a Liquidity pool network because this single metabridge allows funds to be dynamically selected and routed through the optimal 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 spanning more than 30 blockchains and L2 Rollup . It is built on top of the Celer interchain messaging framework, which is built on top of the Celer State Guardian Network (SGN). SGN is a Proof-of-stake(PoS) blockchain built on Tendermint, acting as a message router between different blockchains.

Design Type: Liquidity Network

9. Connext

describe:

Dispatch and process messages related to sending funds Cross-chain. Custody 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 functional groups. Facets share contract storage and can be upgraded individually.

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

10. Elk Finance

describe:

Use ElkNet with the following features:

Cross-chain utility token ($ELK) for value transfer Safe and reliable transmission compared to traditional bridges Cross-chain value transfer in seconds through ElkNet between all blockchains supported by Elk Bridge as a Service (BaaS) Provides the infrastructure for developers to leverage ElkNet for custom bridging solutions Cross-chain swaps between all connected blockchains Provides our Liquidity Provider with Indemnity Loss Protection (ILP) Irreplaceable with unique capabilities and features Token (Moose NFT)

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

11. LI.FI

describe:

Bridge and DEX aggregator to route any asset on any chain to the desired asset on the desired chain, available at API/contract level via SDK, or as an embeddable widget in Dapp

Design Type: Liquidity Pool Aggregator

12.LayerSwap

describe:

Bridge tokens directly from centralized exchange accounts 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-locked contracts (HTLC), using secure communication between users combined with a Liquidity Provider relay network for backing tokens.

Design Type: Liquidity Network

14. O3 Swap

describe:

O3's Swap and Bridge Cross-chain mechanism aggregates multiple Cross-chain Liquidity pools, allowing simple one-time confirmation transactions with planned gas stations to solve the gas fee demand on each chain.

Design Type: Liquidity Pool Aggregator

15.Orbiter

describe:

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

Design Type: Liquidity Network

16. Poly Network

describe:

Allows users to transfer assets between different blockchains using the Lock-Mint swap. It uses Poly Network chains to verify and coordinate message delivery 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. The chain integrated with Poly Bridge needs to support light client verification, because the 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, utilizing a network of routers similar to Cosmos' IBC to move assets from the source chain to the destination chain.

Design Type: Liquidity Network

18. Umbria Network

describe:

Umbria has three main protocols working together:

Cross-chain asset bridge; supports transferring 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's Liquidity Provider earn 60% of all fees incurred by the bridge.

Decentralized Exchange (DEX); automated Liquidity protocol powered by a constant product formula, deployed using smart contracts and managed entirely on-chain.

Both 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:

Multiple transactions on different blockchains

Conduct a transaction through a decentralized bridge integrating DEX

A transaction through the 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 bridge and Liquidity network.

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. Token is stored on the source chain, and the "representation token" is minted on the target chain. The deposited Token is not precisely locked, and Orbit Farm can be used in DeFi protocols. Accrued interest will not be passed directly to Token depositors. 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 top of Wormhole, a messaging protocol that utilizes a dedicated network of nodes to perform Cross-chain communication.

Design Type: Token Bridge

23. Satellite (Axelar)

describe:

Satellite is a token bridge powered by Axelar network

Design Type: Liquidity Network

The L2Beat project maintains a list of L2-related blockchain bridges, with their Total Value Locked (TVL), along with descriptions and brief risk assessments (if any).

L2 Bridge Risk Profile

Finally, users need to be careful when using L2 bridges, and indeed any bridge, and the following risks need to be assessed for a given bridge:

financial loss

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 transmissions

Validator/Relayer private key compromised

The validator maliciously mints new tokens

False Claims Not Disputed in Time (Optimistic Message Protocol)

The target blockchain reorganization happens after Optimistic's oracle/relayer dispute time elapses (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/admins

Token bridge owners misbehaving, or initiating time-sensitive emergency actions affecting user funds, without proper communication with the user base

Protocol contract pause (if function exists)

The protocol contract received a malicious code update

freeze funds

Relayers/ Liquidity Provider do not act on user transactions (messages)

Protocol contract pause (if function exists)

The protocol contract received a malicious code update

Insufficient Liquidity of the target Token on the bridge

review user

Oracles or relays on target or target L2 or both are unable to facilitate transfers (messages)

Protocol contract pause (if function exists)

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

New developments using Zero-knowledge Proof(ZKP) technology are underway to mitigate some of the above risk factors and solve two bridge challenges. In particular, the use of ZKPs allows the following bridge design features:

Trustless and secure, as the correctness of block headers on the source and target blockchains can be proven by zk-SNARKs, which can be verified on EVM-compatible blockchains. Therefore, no external trust assumption is required, it is assumed 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 as anyone can join the bridge's relay network and does not require PoS-style or similar verification schemes Scalable as applications can retrieve ZKP-verified block headers and perform application-specific Verification and function efficient due to new, optimized proof scheme with short proof generation and fast proof verification time

Although early, these types of developments promise to accelerate the maturity and safety of the bridge ecosystem.

summarize

We can summarize the above discussion and overview about L2 bridges as follows:

L2 Bridges are the vital glue of 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 the Ethereum mainnet, are more secure than bridges between L1s - assuming the source code is secure, which is usually a big assumption.

As with all distributed system architectures, important trade-offs need to be made, as expressed by 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 nascent and in a state of flux.

Users are advised to conduct due diligence to evaluate which L2 bridges offer the best risk-reward profile for their needs.

New developments are underway using the latest ZKP techniques that effectively solve the two-bridge trilemma and contribute to improving the overall safety of the bridge.

Many thanks to Tas Dienes (Ethereum Foundation), Daniel Goldman (Offchain Labs), and Bartek Kiepuszewski (L2Beat) for perusing the manuscript and making valuable content suggestions.

Source
Disclaimer: The content above is only the author's opinion which does not represent any position of Followin, and is not intended as, and shall not be understood or construed as, investment advice from Followin.
Like
Add to Favorites
Comments