Mapping the Evolution of Blockchain Bridges
Where we've been
In the early days of smart contract platforms, the consensus view was that there could only ever be a handful of L1s – maybe even only one – that truly mattered. The bridging approaches of the day reflected this, as many were designed to be pairwise and/or asset-specific bridges that focused exclusively on basic functionalities like moving bitcoins to Ethereum.
As the landscape evolved further, we saw the emergence of numerous L1 ecosystems and importantly, sub-ecosystems of rollup networks and application-specific chains emerging within them. While these developments in blockchain architecture design came with many advantages, they also made the problem of bridging meaningfully more complicated. As a result, bridge designs started shifting away from the “one chain to rule them all” approach towards a vision of cross-chain interoperability.
However, in building towards that future it quickly became clear that bridges – like blockchains – have their own “trilemmas” and trade off profiles.
Where we are now
This realization led to yet another shift towards more specialized, often ecosystem-specific approaches and less focus on building one-size-fits-all solutions. To illustrate this, let’s consider two examples: 1) Hop Protocol 2) IBC
Hop Protocol addressed a specific need of the Ethereum ecosystem – token transfers between rollups – which is becoming increasingly important as execution moves off Ethereum L1 for scalability reasons. While Ethereum’s rollup-centric architecture benefits from having secure, native message bridges for moving funds between L1 and L2, it’s also faced with liquidity fragmentation and withdrawal latency. Hop works by leveraging Ethereum L1 as a hub through which L2 assets can be transferred via spokes (native message bridges), while also providing up-front liquidity through an AMM operated by well-capitalized, permissioned market makers. This provides the end-user with the experience of interacting with Ethereum and its L2s as though it were one cohesive network. While this design allows Hop to leverage Ethereum’s strengths to address some pain points specific to its ecosystem, it also sacrifices generalizability, as it does not support arbitrary messages or non-EVM rollups.
IBC addressed a specific need of the Cosmos ecosystem – communication between sovereign blockchains – which is becoming increasingly important as more developers invest in building their own bespoke chains. While Cosmos chains are sovereign and distinct, many of them were constructed using roughly the same building blocks: some version of Tendermint and Cosmos SDK modules. The subtle but important implication of this standardization is that more native and trust-minimized methods of bridging, such as lightclients & relays, become much easier to implement across the entire ecosystem as a result. However, despite these strong security properties, lightclient bridges like IBC have been slow to achieve adoption outside of the Cosmos ecosystem due to a lack of extensibility. This can be attributed to the fact that this approach requires the continuous building of new smart contracts on destination chains that can make sense of state proofs from new source chains. Additionally, the cost of streaming block headers and signature verification can be prohibitively expensive, especially when dealing with Ethereum.
Where we’re going
In this latest phase of evolution, the focus is now shifting towards supporting cross-chain application development, specifically around reducing liquidity fragmentation and enhancing the developer experience.
It turns out that just as applications fall on a spectrum with respect to the amount of throughput or security they require, the same is true for bridging capabilities. For example, a standalone game may only need a method of connecting to a major L1 where users can trade in-game assets on a more general marketplace, while a yield aggregation application may need to send large amounts of tokens and arbitrary messages across multiple chains at high speed and with robust security.
To get a better understanding of how bridges are working to provide developers with more flexibility and optionality, let’s again consider two examples: 1) LayerZero 2) Hyperlane
LayerZero works by constructing Endpoints – a set of non-upgradeable smart contracts – which, when deployed to supported chains, allow for arbitrary message passing between them. Applications can then decide which third party services to use for the actual relaying of messages (block headers & transaction proofs) across endpoints. As co-founder & CEO Bryan Pellegrino pointed out in an interview, this more modular approach puts application developers in control by moving all of the parameterization up the stack from the protocol layer to the application layer. Applications can pick oracle/relay services based on specific cost and security needs or set custom configurations of the messaging library used for sending & receiving verified messages. This design approach also makes it relatively easy for LayerZero to offer new proof validation libraries down the line, which could allow applications to leverage zero-knowledge proofs to improve security or performance.
Set to go live in 2023, Hyperlane brands itself as a modular interoperability network that’s especially focused on abstracting away the complexities of cross-chain communication for developers. Hyperlane plans to introduce a suite of unique product offerings, including:
- An on-chain API that can be used to send & receive messages across chains
- Sovereign Consensus – the ability to configure and implement application-specific security models
- Interchain Accounts – use the Accounts API to do function calls on other chains without deploying contracts on them
- Interchain Queries – use the Queries API to access & verify information on another chain, enabling that information to be leveraged for initiating other actions
A few other notable examples:
Connext
Introduced xApps earlier this summer, which are decentralized applications that can perform operations between independent chains and/or execution environments. This allows developers building cross-chain applications to have a single, unified smart contract interface rather than needing to deploy separate instances to various different chains, and also allows the notion of gas fees to be abstracted away from the user by letting the protocol call the functions.
deBridge
Working towards offering developer tooling for easily building NFT bridges, something that is still very much absent from the bridging ecosystem. deBridge also offers a Hardhat plugin for integration testing, which allows for developing unit test cases for contracts or performing functional tests on the deBridge infrastructure.
Axelar
Deployed Satellite earlier this year, which is a cross-chain asset transfer application built natively on Axelar. Additionally, after being selected by Osmosis governance as its bridge of choice, Axelar has worked on an integration with Osmosis that allows developers to easily use Osmosis as a cross-chain back-end, allowing users to swap and purchase from any chain within a single interface.
Looking Forward
Ultimately, the endgame for bridges looks like a seamless and cohesive experience for both end-users and application developers. There’s no question that there’s more to do before that vision is achieved, but it does feel like the design space for bridges has taken significant steps forward and been more fully explored. Just as modularity in blockchain design – breaking apart core pieces of the stack to avoid tradeoffs and allowing for plug & play – led to more choice and flexibility for developers, the same will be true for bridges.
This next wave of bridging will be amount improving DX, high quality oracle/relay services, bridge & liquidity aggregation, NFT bridging and miner/oracle extractable value – future articles will take a deeper look at these topics individually. If you’re thinking about or building in any of these verticals, want to chat or collaborate on further writing, feel free to reach out via DM or to natalie@volt.capital!
Special thanks to Bryan Pellegrino (LayerZero), Arjun Bhuptani (Connext), Dmitriy Berenzon (1kx) for reviewing and providing thoughtful feedback!