Bridge TVL exploded in mid-to-late 2021
On a technical level, there are different bridge architectures and there are various mental models for compartmentalizing how they work. The first iteration of bridges mostly functioned in a “pair-wise” fashion. Under this architecture, each bridge must attract pools of liquidity for each asset the bridge wants to support transfers for on each blockchain they want to support. Thus, if a bridge wants to connect chain A with chain B and chain C, while providing users with the ability to transfer ETH, USDC, and USDT between the blockchains, the bridge must incentivize liquidity pools for each of those assets (and the synthetic representations of each asset) on each blockchain.
After being battletested in the market, this first iteration of bridging architecture has a few issues:
- User experience: if a user wants to move from token X on chain A, to token Z on chain B, it typically takes 20 clicks and 15 minutes.
- Security: there have been numerous bridge hacks that have led to hundreds of millions in stolen funds.
- Cost: more secure options, like running on-chain nodes (called light clients), are expensive (and complex to operate).
- Capital inefficient: the proliferation of bridges has led to fragmented liquidity; not only across chains, but also across assets.
The industry is at the early stages of a paradigm shift away from this first iteration of bridges towards true interoperability in the form of cross-chain general messaging protocols. These protocols seek to enable communication between every application on every blockchain.
Why is cross-chain general messaging important?
Cross-chain general messaging represents a new framework in how to architect applications. No longer will developers need to deploy their application across 10 blockchains to be successful. Rather, an application can live on one blockchain and communicate with other blockchains to achieve the same desired outcome. Developers will increasingly be able to capitalize on the strengths of different blockchain architectures by communicating cross-chain via general message passing. While in the future, cross-chain general messaging will enable new forms of applications to be built, there are already clear use cases:
- Governance: general messaging provides the ability for a user to cast a DAO governance vote on chain A, for an decentralized application (“dApp”) whose governance module lives on chain B.
- DeFi enabled NFTs: imagine being able to post an NFT as collateral on chain A, and borrow against that same NFT on chain B, all in the click of a button.
- Universal DeFi liquidity: rather than having assets bridge and move across disparate blockchain ecosystems (which fragments liquidity), liquidity can remain on its native blockchain.
- Gaming: be able to transfer and confirm ownership of in-game NFTs across blockchains and games.
This research piece will begin by providing useful frameworks for thinking about interoperability, before providing an overview of the architecture of a few of the most prominent interoperability protocols and ending with a look at what the future could hold.
Similar to the L1 blockchain trilemma (between decentralization, security, and scalability), there is also a trilemma core to interoperability between being trustless, generalizable, and extensible.
- Trustless: protocol does not introduce additional security assumptions
- Generalizable: protocol can handle arbitrary cross-chain data transfers
- Extensible: protocol can be extended to other domains (i.e., other blockchains)
For a protocol to be trustless and generalizable, a light client representing the other blockchain is necessary (for chain A and chain B to communicate, chain A has a light client representing/updating chain B’s state on chain A and vis versa). These protocols are natively verified and expensive to extend to other blockchains.
Native verification: all the underlying blockchains’ validators are fully validating data passing between blockchains. This is typically done by running a “light client” of one blockchain within the other blockchain (and vis versa), with messages sent between the chains to update transactions.
If a protocol is extensible and generalizable, that protocol can be extended across many blockchain ecosystems while still being able to send general messages. This is because these protocols rely on external verification of the messages between two blockchains; thus, introducing a new trust assumption.
External verification: an external (off-chain) validator set is used to relay data between blockchains. This validator set could be a multisig or a separate blockchain validator set. The validators are tasked with verifying messages between blockchains.
Protocols that are trustless and extensible fall into the category of “liquidity networks”. These protocols are typically reliant upon each blockchain for security and have asset liquidity on each blockchain (chain A and chain B, for example). This model is extensible (can utilize across different blockchains, for different assets) but does not support general messaging.
Interoperability protocols must make tradeoffs in how messages are verified.
It should be noted that Nomad, which will be discussed in further detail below, does not fit into one of these three buckets (it being an optimistic system).
The first true interoperability protocols in crypto (such as IBC) were inspired by TCP/IP, the core protocols used by the internet to move information from an application on one computer, to an application on another computer.
The TCP/IP stack is split between the infrastructure (or transport) layer and the application layer. Together, TCP/IP enables arbitrary data to be passed between computers over the internet. Specific application layer protocols can then use the transport layer (TCP/IP). For example, SMTP for email and HTTP for the World Wide Web.
Comparing the original web 1.0 internet protocols to the nascent blockchain interoperability protocols (IBC being the best example to date) will help to visualize the similarities.
Comparison between TCP/IP and IBC
To date, IBC has been successful as a general messaging protocol in the Cosmos ecosystem; meaning, IBC has enabled communication between Cosmos application-specific blockchains (but not between Cosmos chains and EVM chains like Ethereum or Avalanche). XCMP, the general messaging protocol for the Polkadot ecosystem (XCMP is the “IBC of Polkdot”) recently went live, enabling interoperability between Polkadot parachains. Both IBC and XCMP are ecosystem specific general messaging protocols.
Interoperability protocols like Axelar, LayerZero and Nomad send messages between disparate blockchains
An interesting trend that is beginning to emerge is the attempt to modularize the interoperability stack.
Modularity of the interoperability protocol stack
Composable Finance is working to leverage their cross-chain general messaging protocol to bring IBC to the Near blockchain. The visual for how this will work is similar to the above example. IBC will be the messaging layer and Composable Finance will be the transport layer. Polymer is another project seeking to leverage the IBC messaging layer to facilitate cross-chain general messaging.
This section will provide a high-level overview of a few prominent interoperability protocols: IBC, LayerZero, Axelar, and Nomad.
IBC was first implemented in April 2021, connecting the Cosmos Hub with IRISnet. Over the course of 2021, Cosmos ecosystem blockchains upgraded to enable IBC. This helped to spark growth in the Cosmos ecosystem (also aided by Terra TVL expansion and Osmosis/Juno gaining notoriety).
To date, IBC has been the most successful interoperability protocol, growing from 218,000 transaction in June 2021 to 3.7 million transactions in May 2022; while connecting 47 blockchains in the Cosmos ecosystem.
Example: a user wants to bridge a token — token X — from chain A to chain B using IBC:
- The user locks token X in the smart contract on chain A.
- This transaction is included as a part of the block header that a relayer then passes from chain A to chain B (as the above example depicts).
- Chain B verifies the proof from chain A. Specifically, chain B verifies and validates the message happened on chain A and the transaction details. Importantly, chain B assumes that if the message is from chain A, then the message (and the block it is included in) is valid (on this point, the instant finality of Tendermint consensus enables this).
- If the proof is valid, token X is unlocked on chain B.
IBC is already putting on display the power of general messaging interoperability. IBC enabled blockchains in the Cosmos ecosystem will be able to leverage the validators (and thus, the security) of other blockchains. “Shared security” would allow a new, smaller application-specific blockchain to utilize the economic security of the Cosmos Hub (the ATOM).
LayerZero operated in private before coming out of stealth mode in September 2021. The project gained notoriety with a demo video that displayed the power of cross-chain general messaging. LayerZero built Stargate on the LayerZero protocol. Stargate is a bridge that LayerZero claims to solve the interoperability trilemma. Other protocols have also begun building on LayerZero. Most notably a bridgeless cross-chain swap protocol, Hashflow.
LayerZero is an omnichain interoperability protocol with the goal of connecting every smart contract on every chain. One of the key innovations introduced by LayerZero is the concept of an “ultra-light” node. The idea for the ultra-light node model is to try to maintain the security of the light client model (IBC being the best example), while lowering the cost of transactions.
The ultra-light nodes are LayerZero Endpoint smart contracts on each blockchain. These smart contracts have separate modules that can easily extend and be implemented to new blockchains. One of these modules is a “library” which is tasked with validating proofs from other blockchains.
How does it work?
There are two pieces of information — block header and transaction proof. An oracle and a relayer are responsible for independently forwarding those pieces of information to the destination chain.
An example of an application sending a message from chain A to chain B:
- Message is routed via endpoint on chain A
- Endpoint on chain A notifies the app specific oracle and relayer for the message
- Oracle forwards block header to endpoint on chain B, while relayer submits transaction proof
- Transaction proof on chain B (destination chain) is validated
What makes this model unique is the fact that the ultra-light node (LayerZero Endpoint) is not storing the state of other blockchains (as in the light client model introduced by IBC). Rather, the oracle is tasked with reporting the state of each blockchain, and the relayer is tasked with general message passing and proofs.
It is important to note, the worst-case scenario security outcome occurs if the relayer and oracle are the same entity. In this scenario, LayerZero inherits the security of the oracle (Chainlink is the main oracle). The relayer and oracle are both permissionless; thus, a protocol could run their own (and make guarantees as such).
What is interesting about this model is the siloed nature of risk. In order to corrupt the system, control over both the relayer and oracle are necessary; and due to the permissionless nature, there are different relayers/oracles for various applications. What this means is that if a specific relayer/oracle are corrupted, only applications using those specific parties will face an issue. In this way, risk is siloed.
It is fair to caveat that currently Stargate (the first bridge built on LayerZero) utilizes a three-party multisig for the oracle, and LayerZero acts as relayer. The plan is for this to change as the network grows.
Source: Map of Zones
Axelar is a general messaging interoperability protocol that provides a “protocol stack” solution enabling dApps to easily leverage Axelar’s APIs to communicate cross-chain. The Axelar network is composed of two main protocols:
- Cross-chain gateway protocol (CGP): connects multiple blockchain ecosystems and routes messages across them.
- Cross-chain transfer protocol (CTP): application layer protocol stack on top of CGP. Allows developers to connect dApps across blockchains.
This is analogous to the framework noted above between the application layer protocol and infrastructure/transport layer protocol. While Axelar functions in a similar way to LayerZero, offering an entire protocol stack is unique to Axelar.
How does it work?
The Axelar protocol stack functions in layers. At the top, dApps leverage application specific protocols to connect to different blockchain ecosystems. This enables developers to build their dApp on the platform best suited for the use case of the dApp they are building, while also allowing the dApp to connect to other ecosystems and their users.
Fundamentally, Axelar is built as a Cosmos SDK blockchain; meaning, it runs on Tendermint consensus with delegated proof-of-stake (PoS) security. Thus, Axelar relies on external verification, making it extensible and generalizable (Axelar can send general messages across any blockchain) but not trustless (Axelar introduces a new trust assumption; that being the validator set). Tendermint PoS blockchains rely on the economic value of the blockchains’ token for security. A major risk to the network would be a rapidly declining token price, leaving the network vulnerable to attack (as with what happened in the Terra death spiral).
Nomad is a general messaging interoperability protocol that applies security concepts from fraud proof rollups (like Optimism and Arbitrum). Nomad has built the Nomad bridge using their general messaging protocol; the bridge is the canonical (official) bridge for the Evmos and Moonbeam ecosystems.
How does it work?
Nomad deploys a “home” smart contract when it launches on a blockchain. Rather than maintaining the state of another blockchain (as in the light client model discussed above), the Nomad home smart contract maintains a merkle tree that contains the history of Nomad messages sent and received on the home smart contract. Messages are enqueued on the home smart contract and committed to the merkle tree. The merkle root of this tree is notarized by an updater and relayed to the destination blockchain.
This is where the “fraud proof” concept comes in. There is a 30-minute delay between when the message is committed to the merkle tree, and when the message is officially confirmed. During this period, any watcher of the network can claim fraud and the system is reliant on having at least one honest watcher. To dis-incentivize fraud, the updater who notarizes the messages, also bonds capital to the home smart contract. If there is fraud by an updater their bond is slashed.
As noted above, Nomad relies on an optimistic system in which only one honest actor needs to flag fraudulent behavior. There are no new trust assumptions introduced.
In doing this, Nomad and Connext partner to form a modular interoperability stack that solves the interoperability trilemma noted above.
What the future might look like
Blockchains communicating and interoperating with other blockchains is important but for blockchains as a new computing paradigm to reach their full potential, they also need to interoperate with the internet. To date, oracles like Chainlink and Band have expanded the range of blockchain applications by providing information like asset prices on blockchains. However, as blockchain dApps develop, increasingly there is and will be a need for new and more complex forms of data on blockchains (i.e., there is and will be a serious need for more advanced oracles). Interoperability will encompass not only blockchain to blockchain communication but blockchain to blockchain AND blockchain to internet communication.
Blockchains like Ethereum are often labeled “world computers”, however, Ethereum (and other smart contract platforms) provide an isolated and computationally limited execution environment. Blockchains are unable to carry out expensive computational tasks (run machine learning algorithms) and interoperate with external systems (like connecting to the internet).
Nexus is a general-purpose, decentralized cloud computing network that enables blockchains to outsource computation and interoperate with external systems; thus, solving the limitations of blockchain computing environments.
Zero-knowledge proof technology is very exciting and has already begun to come to market in the form of rollups (StarkNet, zkSync, Aztec, Scroll, et al). Many proclaim that a zero-knowledge proof-based bridge is the ultimate bridging solution. What makes creating a zk-bridge difficult is the problem of creating a zk-based light client. To do this, the consensus process of a blockchain would need to be updated within a zk-proof. Currently, this is incredibly difficult.