Introduction
In 2021, following delays in Ethereum’s vision for scaling (sharding, layer 2’s, etc.), various alternative layer 1 (L1) smart contract platforms emerged. These “alt L1s” presented new visions for the future of blockchains (Solana, Near, Avalanche, et al). As the crypto bull market kicked into high gear, an increasing amount of capital poured into these new networks; in part to capitalize on speculative mania, while also using new products and forging new communities. The result was Ethereum’s total value locked (TVL) dominance went from ~95.0 percent market share in late 2020, to the current level (May 2022) of ~55.0 percent market share.
The rapid expansion of alt. L1s created the need to move assets between these different blockchains. As the new multi-chain world burgeoned, blockchain bridges became increasingly important; TVL in bridges exploded (bridges need liquidity to facilitate transfers) and bridge volume increased immensely.
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.
Frameworks
Interoperability Trilemma
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.
Locally verification: only the parties involved in a given cross-chain interaction verify transactions. Each validator node in the network holds assets as inventory on each blockchain. Each single node then acts as a router utilizing their bonded capital (pools of liquidity).
Interoperability protocols must make tradeoffs in how messages are verified.
Below is a depiction of how the most important interoperability protocols verify communication.
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).
**EDIT NOTE: LayerZero is not technically natively verified. For a great discussion on the matter, listen to this.
Modular Interoperability
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.
IBC is a protocol that handles the transport, authentication, and ordering of data across blockchains in the Cosmos ecosystem. Like TCP/IP, IBC is a general messaging protocol (meaning any application, and/or blockchain, can utilize the IBC protocol) that is split between an application layer and infrastructure layer (for IBC, there is the TAO layer — transport, authentication, and ordering — and the application layer). Rather than enabling communication between computers, IBC enables communication between blockchains; specifically, to date, Cosmos ecosystem blockchains.
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.
The core of the next evolution in blockchain interoperability is cross-chain (or “cross-ecosystem”) general messaging protocols that enable applications on different blockchains (Ethereum, Solana, Avalanche, et al) to communicate with each other. Axelar and LayerZero are prominent examples.
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.
IBC partnering with LayerZero: IBC has an infrastructure layer that handles the transport, authentication, and organization of IBC messages. The transport layer of IBC requires light clients on each respective chain (which is prohibitively expensive for further IBC expansion). In being a chain agnostic general messaging protocol, LayerZero can complement IBC by utilizing the LayerZero protocol as transport layer, while maintaining the other aspects of IBC. Effectively, LayerZero can transport IBC messages; the main difference is the verification model. With IBC, verification is reliant upon each blockchains’ validators; with IBC plus LayerZero, verification is reliant upon oracles in LayerZero’s network (more on this to come).
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.
Protocols
This section will provide a high-level overview of a few prominent interoperability protocols: IBC, LayerZero, Axelar, and Nomad.
IBC
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.
As noted above, IBC uses a light client model to maintain state and relay messages between two blockchains (it is natively verified). When chain A wants to establish communication with chain B, the two chains enter into a “handshake” agreement to establish a channel (over which messages can be passed). The state of chain A on chain B is maintained via the light client and updated via relayers (who transport messages between blockchains).
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).
Interchain Accounts (ICA) is an application layer protocol that will allows users to perform complex transactions cross-chain by using IBC general messaging.
LayerZero
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
- The message is forwarded to the destination address (specific application)
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.
Security
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.
Source: LayerZero
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.
Axelar
Axelar initially published their whitepaper in January 2021 and have been at work in building the protocol since. In early 2022, Satellite launched as one of the first applications on the Axelar Network. Axelar is a general messaging protocol that utilizes its own validator set for security. The Axelar blockchain was built using the Cosmos technology stack; over the past few months, Axelar has grown to be one of the most prominent blockchains in the Cosmos ecosystem (as measured by trailing 30-day IBC transaction volume).
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.
On each blockchain that Axelar connects, there is a gateway smart contract. Axelar validators monitor the gateway smart contract on each blockchain and are responsible for confirming the transaction is valid (on the source chain), then passing the transaction to the appropriate (destination) blockchain.
Security
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
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.
Security
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.
While Nomad offers cheap and secure transactions, the downside is the waiting period. In building out their bridge application, Nomad has partnered with Connext to fix this issue. Connext is a cross-chain liquidity network that has pools of liquidity across blockchains (offering short transaction latency). Thus, users of Nomad bridge who do not want to wait 30 minutes for their capital can instantly get liquidity on the destination blockchain using Connext liquidity (Connext then gets paid back by Nomad once the process is complete).
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
Programmable Interoperability
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.
Nexus Protocol is an early-stage project that seeks to bring forth this interoperable future.
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.
To do this, Nexus utilizes Multi-Party Computation (MPC) technology to introduce the first stateless, general-purpose, decentralized cloud computing platform, allowing developers to program their own blockchain oracles. This system creates “programmable interoperability” between blockchains and the digital world outside each blockchain.
Zk-bridge?
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.