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:

1. blockchains cannot talk to one another,
2. arbitrage plays on a particular blockchain require that all involved assets are present on that blockchain because of the trustless nature of public blockchains, 
3. 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. 

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

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. 

Why are Bridges important for L2s?

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. 

Type of L2 Bridges: An Overview

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.

The current L2 Bridges Landscape

Below we summarize the current and very varied landscape of L2 bridges with a name, brief summary, and bridge design type:

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.

Summary

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.