Yet, unlike in the conventional financial sector, where assets in one jurisdiction may be utilized in arbitrage operations in another country without the need for a trusted intermediary, the same strategy has long worked. For three reasons, neither blockchain works:
- Blockchains are unable to communicate with one another.
- Due to the trustless nature of public blockchains, arbitrage on a certain blockchain necessitates the existence of all relevant assets on that blockchain.
- In conventional finance, there is no trustworthy middleman between trustless blockchains.
To address the capital inefficiency problem on the blockchain while also making money, innovative entrepreneurs built blockchain bridges to meet these three difficulties and began to connect the blockchain ecosystem together, and you can now trade Bitcoin on Ethereum. Of course, cross-chain bridges can be used for various purposes, but their primary role is to increase capital efficiency.
What exactly is a blockchain bridge?
A blockchain bridge joins two blockchains, allowing for safe and verifiable communication between them via the transfer of information and/or assets.
This opens up a plethora of possibilities, including:
- Asset transfer between chains.
- Novel decentralized apps (dApps) and platforms that empower users by allowing them to enjoy the benefits of multiple blockchains.
- Developers from various blockchain ecosystems may work together to create innovative solutions.
Bridges are classified into two types:
- Trusted Bridge
Dependence on a single entity or system to function. Trust assumptions about fund custody and bridge safety. Customers mostly rely on the bridge operator’s reputation. Users must give up control of their digital holdings.
- No trust bridge required
Use decentralized systems, such as smart contracts with embedded algorithms, to operate. The bridge’s security is identical to that of the underlying blockchain. Let users manage their finances via smart contracts.
You may differentiate two sorts of cross-chain bridge architectures based on two sets of trust assumptions:
- Lock, Mint, and Burn Token Bridges: Immediately assured finality due to the ability to issue assets on the destination blockchain when needed without the risk of transaction failure. Instead of native assets, users on the target blockchain receive a synthetic asset, also known as a wrapped asset.
- A local asset pool liquidity network with harmonized liquidity: A single asset pool on one blockchain links to other asset pools on different blockchains, sharing liquidity. This method does not provide instant, guaranteed finality since transactions may fail if there is insufficient liquidity in the pooled pool.
Yet, all solutions, regardless of trust assumption, must handle two challenging issues confronting blockchain bridges.
A bridge protocol may only contain two of the following three characteristics:
- Immediate Guaranteed Finality: The recipient of assets on the target blockchain is guaranteed to get them immediately after the transaction on the source blockchain is completed and the transaction on the target blockchain is finalized.
- Unified Liquidity: A single pool of liquidity for all assets transferred across the source and target blockchains.
- Native assets: Receive target blockchain assets rather than bridge-minted assets representing the source blockchain’s original assets.
Arjun Bhuptani of Connext discusses the Interoperability Trilemma.
Just two of the following three attributes may be included in an interoperability agreement:
- No additional trust assumptions, only the same security assurances as the underlying blockchain.
- Scalability is the capacity to connect many blockchains.
- Enables arbitrary data messaging.
Apart from the trilemma, which may be handled by intelligent design, the largest difficulty for blockchain bridges is security, as proven by the numerous attacks in 2021 and 2022, including the Wormhole, Ronin, Harmony, and Nomad events. Bridges across blockchains are fundamentally only as secure as the least secure blockchain utilized in the asset’s bridge (chain). Nevertheless, because they share the same ASD, bridges between layer 2 (L2) platforms anchored on the same layer 1 (L1) blockchain are not affected by the latter problem.
What is the significance of cross-chain bridges in L2?
While L2 is purely a sort of bridge: a local bridge, we haven’t particularly examined L2 platforms built to expand L1 blockchains while inheriting L1’s security guarantees. Nevertheless, while building bridges across L2s, various L2 platform characteristics, such as optimistic rollups vs. zk-rollups vs. Validium rollups vs Volition rollups, come into play. These distinctions distinguish them due to variations in trust assumptions and finality between L2s and L1s, as well as between various L2.
Bridges between L2s are vital for the same reasons that bridges between L1s are important: L2 assets want the capital efficiencies of other L2s, as well as portability and other capabilities.
If the bridged L2s are anchored on the same L1, discrepancies in local trust assumptions on L2 platforms can be addressed. Thus, no additional trust assumptions are required for the bridge. Yet, discrepancies in the finality of L2 transactions anchored on L1 make it difficult to connect assets between L2s while minimizing trust.
L2 Blockchain Bridge Types
We investigated L2 bridges further and discovered that an L2-L2 bridge should ideally fulfill the following criteria:
The loosely coupled paradigm requires clients to abstract away from each L2 protocol to which they are linked via an abstraction layer.
The client must be able to validate the data supplied by the abstraction layer, ideally without modifying the trust model used by the target L2 protocol.
There are no structural or protocol modifications required for the interface L2 protocol.
Other parties must be able to independently create interfaces to the target L2 protocol, ideally standardized interfaces.
According to the current scenario, most L2 bridges handle L2 as if it were another blockchain. It is worth noting that the fraud proofs used in optimistic rollups, as well as the validity proofs used in zk-rollups solutions, replace the block headers and Merkle proofs used in “regular” L1-to-L1 bridges.
Current L2 Bridge Landscape
Hope Exchange
Rollup-rollup universal token bridge. It allows users to send tokens from one rollup to another almost instantly without waiting for the rollup’s challenge period.
Design Type: Liquid Network (using an AMM)
Stargate
Composable native asset bridge and dApps built on top of LayerZero. DeFi users can exchange native assets across chains 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: Fluid Network
Synapse Protocol
A token bridge that utilizes validators between chains and liquidity pools to perform cross-chain and same-chain swaps.
Design Type: Hybrid Design (Token Bridge/Liquidity Network)
Across
A cross-chain Optimistic bridge that uses actors 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: Fluid Network
Beamer
Enables users to move tokens from one rollup to another. Users request transfers by providing tokens on the source rollup. The liquidity provider then fills the request and sends tokens directly to users 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 providers recovering funds. As soon as the request arrives, it is served optimistically. The source rollup’s refund is guaranteed by its own mechanism, separate from the actual service.
Biconomy Hyphen
The multi-chain relay network utilizes smart contract-based wallets for users to interact with liquidity providers and transfer tokens between different (Optimistic) L2 networks.
Design Type: Fluid Network
Bungee
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
Celer cBridge
A decentralized non-custodial asset bridge supporting 110+ tokens across 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: Fluid Network
Connext
Dispatch and process messages related to sending funds across chains. 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)
Elk Finance
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 via ElkNet between all blockchains supported by Elk
- Bridging as a Service (BaaS) provides developers with the infrastructure to implement custom bridging solutions utilizing ElkNet
- Cross-chain swaps between all connected blockchains
- Intended Loss Protection (ILP) for our liquidity providers
- Non-fungible tokens (Moose NFTs) with unique abilities and properties
- Design Type: Hybrid Design (Token Bridge/Liquidity Network)
LI.FI
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 dApps
Design Type: Liquidity Pool Aggregator
LayerSwap
Bridge tokens directly from centralized exchange accounts to Layer 2 (L2) networks (Optimistic and zk-rollups) with low fees.
Design Type: Liquidity Network (using an AMM)
Meson
An atomic swap application using hashed time-lock contracts (HTLCs) using secure communication between users combined with a liquidity provider relay network for backed tokens.
Design Type: Fluid Network
O3 Swap
O3’s Swap and Bridge cross-chain mechanism aggregates multiple cross-chain liquidity pools, allowing simple one-time confirmation transactions with planned gas stations and solving the gas fee demand on each chain.
Design Type: Liquidity Pool Aggregator
Orbiter
A decentralized cross-rollup bridge for transferring Ethereum-native assets. The system has two roles: Sender and Maker. A “Maker” must first deposit an excess deposit into Orbiter’s contract before being eligible to become a cross-rollup service provider for a “Sender.” In the usual process, ‘Sender’ sends assets to ‘Maker’ on ‘Source Network’, and ‘Maker’ sends assets back to ‘Sender’ on ‘Destination Network.’
Design Type: Fluid Network
Poly Network
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
Voyager (Router Protocol)
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: Fluid Network
Umbria Network
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 providers 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, managed entirely on-chain.
Both protocols work together to provide asset migration between cryptocurrency networks.
Design Type: Liquidity Network (using an AMM)
Via Protocol
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)
Multichain
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)
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 target chain. Deposited tokens are not locked precisely, and Orbit Farm can be used in DeFi protocols. Accrued interest is not passed directly to token depositors. Bridge contract implementation and Farm contract source code are not verified on Etherscan.
Design Type: Token Bridge
Portal (Wormhole)
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
Satellite (Axelar)
Satellite is a token bridge powered by the Axelar network
Design Type: Fluid 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 available.
L2 Bridge Risk
Ultimately, when utilizing L2 bridges, or any bridge, users must exercise caution, and the following hazards must be considered for each bridge:
Financial loss
- Oracles, relayers, and validators conspire to submit fraudulent proofs (for example, block hashes, block headers, Merkle proofs, fraud proofs, and validity proofs) and/or relay unchecked fraudulent communications.
- The private key of the Validator/Relayer has been hacked.
- Validators create new tokens on purpose.
- False claims are not challenged in a timely manner (Optimistic Message Protocol)
- Once Optimistic’s oracle/relayer dispute timer expires, the intended blockchain reorganization occurs (Optimistic messaging protocol).
- Unverified contract source code incorporated in or utilized in the protocol contains harmful code or functionality that may be misused by contract owners/admins misbehaving or launching time-sensitive emergency actions affecting user money without sufficient communication with the user base.
- Protocol contract suspension (if the function exists)
- A malicious code update was applied to the protocol contract.
Asset is frozen
- Relayers and LPs do not intervene in user transactions (messages).
- Protocol contract suspension (if the function exists).
- A malicious code update was applied to the protocol contract.
- On the bridge, there is insufficient liquidity of target tokens.
User evaluation
- Oracles, relays, or both on the target or target L2 are unable to support transfers (messages).
- Protocol contract suspension (if the function exists).
While not full, this list offers a reasonable summary of the dangers connected with present bridge use.
Novel advancements are ongoing employing zero-knowledge proof (ZKP) technology to alleviate some of the aforementioned risk issues and tackle two bridge difficulties. The usage of ZKPs, in particular, enables the following bridge design features:
- The validity of block headers on the source and destination blockchains may be confirmed using zk-SNARKs, which can be validated on EVM-compatible blockchains, making it trustless and safe. As a result, no external trust assumption is necessary, the source and target blockchains, as well as the light client protocol utilized, are safe, and the relay network has 1-of-N honest nodes.
- Permissionless and decentralized since anybody may join the bridge’s relay network and no PoS or equivalent verification mechanisms are required.
- Applications may get ZKP-validated block headers and execute application-specific validation and functionality, making it scalable.
- Efficient because of a novel, optimized proof system with quick proof creation and verification times.
Although still in their early stages, these sorts of advancements have the potential to accelerate the maturity and safety of the bridge ecosystem.
Conclusion
The above description and overview of L2 bridges may be summarized as follows:
- L2 Bridges are the L2 ecosystem’s critical glue, supporting L2 interoperability and the effective usage of assets and applications throughout the ecosystem.
- An L2 bridge deployed on an L2 that is anchored on the same L1, such as the Ethereum mainnet, is more secure than a bridge between L1s, providing the source code is safe, which is sometimes a significant assumption.
- Important trade-offs must be considered, as described by two hypothetical trilemmas: the blockchain bridge trilemma and the interoperability trilemma.
- L2 bridges contain highly diverse trust assumptions, such as trustworthy vs. trustless bridges, as well as very different design options, such as lock-mint-burn vs. liquidity networks.
- The L2 Bridges ecosystem is currently in its early stages and in change.
- Users should undertake due diligence to determine whether L2 bridges have the optimum risk-reward profile for their needs.
- Further advancements are underway, utilizing the most recent ZKP technology to successfully address the two bridge trilemma and contribute to the bridge’s overall safety.
While establishing an L2 interoperability framework is still in its early stages, these are significant advancements that should be regarded seriously, as any of these initiatives may become “the bridging framework.”
DISCLAIMER: The Information on this website is provided as general market commentary and does not constitute investment advice. We encourage you to do your own research before investing.
