The Interop Series: IBC and LayerZero

Introduction

The Inter-Blockchain Communication (IBC) protocol and LayerZero are two of the leading interoperability solutions today. As of Aug 2nd, both LayerZero [1] ($1.08 billion) and IBC ($883.9 million) rank 1st and 3rd respectively based on one month bridged volume.

Last month we kicked off the Interop Series - a collection of blog posts that compare IBC with other interoperability protocols. In this piece, we’ll provide an in-depth comparison between IBC and LayerZero, starting with an overview of their architectures, followed by an analysis across four key pillars of comparison:

• Security
• Latency and cost
• Expressiveness
• Extensiveness

For readers already familiar with either or both protocols, feel free to skip the section on architecture and navigate to the comparative analysis.

Architecture

The Inter-Blockchain Communication (IBC) Protocol

As a well-specified, battle-tested, and general-purpose interoperability protocol, IBC is a standardized transport layer that facilitates sending and receiving messages between arbitrary state machines.

The core components of IBC include:

• Light client: A lightweight representation of one blockchain on another. Used to verify block headers.
• Connections: A transport layer abstraction that connects two light clients on two disparate chains.
• Channels: A transport layer abstraction that serves as a conduit to transfer IBC packets between modules/applications on different chains.
• Relayers: Off-chain processes that monitor cross-chain events, constructs IBC packets, and performs message routing between source and destination chains.

Note: While light clients are the preferred mechanism today to verify message correctness, they are not a strict requirement. Similar to TCP, IBC is a standardized way to transport messages from point A to B. The verification method used is entirely up to the chain developer. IBC defines three interfaces - ClientState, ConsensusState, and ClientMessage - that are designed to be generic enough to swap out different verification mechanisms. Let’s use an example of an end-to-end transaction flow between chain A and chain B to understand IBC’s architecture in detail:

1. A user on chain A intends to send a message to their account on chain B (e.g. token transfer).
2. The user triggers the relevant application module, which subsequently calls into Core IBC[3].
3. Core IBC commits a hash of that message to the state machine, at a predefined path agreed upon by both chains during the connection handshake.
4. The commit triggers an event. Relayers continuously monitor chains for such events and constructs a multi-message transaction that includes a MsgRecvPacket and a MsgUpdateClient to update the light client of chain A on chain B of its latest ConsensusState (Merkle root of the application state), a Merkle proof of the message, and the message itself encoded as bytes.
5. Upon receiving the message, Core IBC writes a packet receipt to state[4] and verifies the correctness of the message by checking if the Merkle proof provided hashes up to the Merkle root[5] (contained within the Root field of ConsensusState).
6. In the happy path, the message is successfully verified, triggering an application callback which allows the module to unmarshal the contents of the message and perform business logic (such as minting/swapping/staking tokens or performing a function call). A MsgAcknowledgement is sent back to chain A, conveying a successful acknowledgement of the message.
7. In the unhappy path, the application logic fails on chain B. In this case, an error acknowledgement is sent back to chain A, which can then revert state (such as unlocking tokens that were previously locked).

IBC also handles timeouts, where a message was sent from chain A, but it was never received on chain B within a specified time. Timeouts are always proven on the source chain based on the counterparty’s time. Detailing how timeouts work is outside of the scope of this blog post. See here to learn more about how timeouts work.

Application developers can permissionlessly deploy their apps on top of the IBC transport layer. The reference implementation of the IBC protocol written in Go, ibc-go, offers various applications out of the box, such as:

• ICS-20 Fungible Token Transfers: For cross-chain token transfers
• ICS-27 Interchain Accounts (ICA): For cross-chain account management
• ICS-31 and 32 Interchain Queries (ICQ): For cross-chain data reads
• ICS-721 NFT Transfers: For cross-chain NFT transfers

ICS stands for Interchain Standards. They define the standardized technical specifications for each subprotocol or feature.

IBC also offers app devs the freedom to extend these apps with the use of middleware, enabling additional functionality that complements existing applications without having to add or change core IBC logic. Middleware that can be used today includes:

• ICS-29 Relayer Fee Middleware: To pay IBC relayers for the packets they relay
• Callbacks Middleware: Wrap token transfer or ICA module to perform arbitrary logic upon sending or receiving a message. See here to learn more.
• Rate-Limiting Middleware: Safety control middleware for token transfers.
• Packet-Forward Middleware: Middleware for efficient packet routing.

LayerZero

LayerZero defines itself as “an immutable, censorship-resistant, and permissionless smart contract protocol that enables anyone on a blockchain to send, verify, and execute messages on a supported destination network.”

v2[6] of the LayerZero protocol consists of the following key components:

• Endpoint: A smart contract that acts as the primary interface for OApps (Omnichain applications) to send, receive, and verify messages cross-chain. There exists one Endpoint per supported chain.
• MessageLibs: A collection of smart contracts that an OApp can configure to enforce protocol logic for composing, sending, receiving and verifying messages. The default MessageLib in LayerZero V2 is Ultra-Light Node 302 (ULN302). It is responsible for interfacing with Endpoint contracts, encoding/decoding messages, emitting events to DVNs and Executors, and committing verified messages to destination Endpoints.
• Decentralized Verifier Network (DVN): An on-chain or off-chain entity capable of verifying the validity of messages. A DVN can be a native bridge, an externally-verified bridge (eg. Axelar), or a ZK light client such as Polyhedra. The default DVNs are Google Cloud and the one operated by LayerZero Labs. The LayerZero Labs DVN uses a 2 of 3 multi-signature verification. OApps can configure multiple DVNs (X of Y of N). For example, a 1 of 3 of 5 security configuration would mean that one required DVN and two arbitrary DVNs out of a total of five must verify a message before execution.
• Executor: Any entity capable of calling the lzReceive method on a destination Endpoint contract (after all configured DVNs have verified the payloadHash).

Let’s use an example of an end-to-end transaction flow between chain A and chain B to understand LayerZero’s architecture in detail:

1. An application on chain A calls the lzSend method on an Endpoint.
2. The application specifies the destination chain to which the message is to be sent, the relevant MsgLibs to be invoked, and the message itself.
3. The Endpoint uses the application configured MsgLibs to determine how the message will be composed. Specifically, the MsgLibs enforce how the message packet will be constructed and to which Executors and DVNs the events must be emitted.
4. The configured security stack (DVNs) scans for such events, constructs the payloadHash using their own consensus process, and each individual DVN writes their view of the payloadHash to the destination MsgLib.
5. The destination MsgLib enforces that:
1. a) The DVNs waited for the specified number of block confirmations before writing the hashes on-chain.
2. b) The DVN addresses are the same as those configured by the application.
3. c) And that the required threshold of DVNs verified the message.
6. Afterwards, an Executor commits the nonce of that message to the destination Endpoint contract for execution.
7. The Executor ensures that the individual hashes submitted by the DVNs are identical to the hash emitted upon sending that message.
8. Finally, the Executor calls the lzReceive method on the destination Endpoint to execute the message.

Now that we have an understanding of how these two protocols work, we’ll move on to comparing them across different verticals.

Comparing IBC and LayerZero

Security Model and Processes

To analyze the security of an interoperability protocol, its important to address the following key questions:

1. How secure is the underlying system design?
2. How secure is the implementation?
3. What processes are in place to minimize the risk of implementation bugs?
4. What defence-in-depth measures are in place to mitigate loss in a worst-case scenario?

In the sections below, we’ll look into bullet points 1, 3, and 4.

IBC

From a system design perspective, the security of IBC is inherently linked to the security of chains that use IBC. This is because light clients verify what the validator set of a chain has committed to. When chain B receives a message from chain A, the former (light client of A on B) trusts what the consensus threshold of chain A’s validator set has claimed to be true.

As light clients cannot re-execute transactions and verify state transitions themselves, they could potentially be tricked into accepting an invalid header if > ⅔ majority of a counterparty chain’s validator set has been compromised.

IBC's light client-backed security is an improvement over systems that use a third-party verification bridge (C) for sending messages between chains A and B. In such systems, the weakest link could be the third-party bridge, which, if compromised, could jeopardize the security of both chains A and B. IBC eliminates this issue by not relying on an intermediary for message verification.

To mitigate risks from worst-case scenarios, IBC employs the following defence-in-depth measures:

• Misbehaviour detection: As mentioned earlier, even though light clients trust the consensus mechanism of a counterparty, if the counterparty validator set misbehaves - such as double signing - light clients are capable of detecting it and freezing that connection and therefore preventing any further messages to be accepted from the malicious chain.
• Rate limits: The IBC rate limit middleware developed by Osmosis can be used to act as a safety control mechanism to limit the amount of value that can exit a chain within configurable time intervals. It is currently used by high-volume chains such as Osmosis, dYdX, and Stride.
• Application circuit breaker: The x/circuit module within the Cosmos SDK allows specific, or all messages to be disabled in case of a hack/bug.

Aside from the in-protocol safeguards, the development of IBC (both ibc-go - the reference implementation, and ibc-rs) is subject to rigorous safety measures and robust internal security processes. In addition, every major feature is subject to multiple rounds of internal audit, as well as an external audit. There are also bug bounties for each part of the stack.

LayerZero

In terms of security, LayerZero is a unique interoperability protocol as it offers a high degree of customization of one's security stack (DVNs + Executor). From an application developer’s perspective, they can tailor the degree of security by configuring their security stack according to the application's needs.

For example, an app that manages a high volume of value exchange - such as a stablecoin provider - might opt for multiple DVNs verifying the validity of cross-chain messages while also running their own DVN. But for apps that don’t require high security, they can choose to opt for just one DVN.

Given the X of Y of N model for DVNs, applications can, for example, compose their security stack in such a way that 1 required DVN and 2 arbitrary DVNs out of a total of 5 must verify a message before execution (1 of 3 of 5). If the required DVN’s view of the payloadHash does not match that of the others, then the message will never be executed on the destination.

From a user standpoint, the degree of security is greater while using IBC as opposed to LayerZero, because the latter employs third parties to verify the authenticity of messages while in the case of IBC, the chains themselves are performing the verification sans trusted third parties.

Apart from a configurable security stack, LayerZero also ensures that protocol changes can only be made by appending MessageLibs. Existing MessageLibs cannot be removed to help ensure that updates to the protocol do not introduce new and potentially malicious code.

Similarly, all LayerZero Endpoint contracts are immutable. Therefore once deployed, an Endpoint’s contract code cannot be changed. Additionally, LayerZero also runs a major bug bounty program.

Latency and Cost

IBC

The median latency of a MsgRecvPacket on CometBFT (formerly Tendermint) chains is 22 seconds. Given that the latency of CometBFT consensus is ~5 seconds[7], the median latency of receiving an IBC packet is approximately 17 seconds. The median time for a full packet lifecycle (from sending a message on the source to receiving the acknowledgement) is 19 seconds excluding consensus latency.

The speed of IBC between other ecosystems such as Polkadot parachain<>Cosmos SDK chain is contingent upon the latency of Polkadot’s[8] and CometBFT consensus plus relayer latency.

In terms of fees, IBC has no in-protocol rent extraction. Users pay the associated transaction cost on the source chain, and relayers take care of fee payment for packet delivery. ICS-29 Fee Middleware can be used to incentivize relayer operators for the packets they deliver. You can read here to learn more about the Fee Middleware. Using the Fee Abstraction module developed by Osmosis, users of IBC can pay fees in any token and not just the chain’s native token.

Similar to the Internet, IBC is a public goods infrastructure product without a profit motive. The development of IBC is funded by the Interchain Foundation - a non-profit organization. There is no single team responsible for the development of the protocol. Instead, a community of passionate builders contribute to the open-source repositories (ibc-spec, ibc-go, ibc-rs).

LayerZero

To assess the latency of LayerZero, we looked at the speed of Stargate Finance - a liquidity network built on top of LayerZero by the LayerZero Labs team.

For cross-chain transfers, Stargate offers two options for users: Taxi and Bus. By batching multiple transactions together, Stargate Bus is the cheaper but slower option, while Stargate Taxi offers faster but more expensive bridging relative to Bus.

We analyzed the speed of Stargate Taxi for ETH transfers between Ethereum Mainnet, Arbitrum, and Base. You can find the results here and here. The median latency of transfers from Arbitrum to Ethereum Mainnet is 298 seconds, and the median time between Arbitrum and Base is 107 seconds.

Like IBC, the LayerZero protocol does not charge an additional fee on top of the regular gas costs for transaction execution on source and destination chains. The Stargate Finance application charges cross-chain swap fees that vary by network.

Expressiveness

IBC

The property of expressiveness here is defined as the degree of freedom offered to developers to build applications.

One of the features unique to IBC among all existing interoperability solutions is the support for native packet receipts and acknowledgements, making it easy for app developers to build composable applications. In the case of asynchronous cross-chain communication, acknowledgements are useful because they can be used to handle failures. Returning an acknowledgement of failure is preferable to simply aborting a transaction as it allows the sending chain to take appropriate action based on the failure (retry send or refund tokens to the user).

Acknowledgements are also useful for composing messages. For example, one can use the callbacks middleware to build an application that bundles multiple user actions into a single transaction. This is made possible by triggering an action upon receiving a successful ACK.

Using callbacks middleware, developers can build apps with the following use cases:

• Send tokens from chain A to B. If the transfer is successful (success ACK received), send a subsequent message to stake/LP/swap tokens.
• Execute arbitrary smart contract logic upon receiving an ICS-20 token transfer packet.

IBC also offers the Interchain Accounts (ICA) feature out of the box. Using ICA, any action that can be performed on a chain (send, swap, stake, LP) can be executed on a remote chain from the source chain. Currently, ICA is used in the following ways:

• Stride and Quicksilver leverage the feature for cross-chain liquid staking
• Neutron uses ICA for money market activities, such as cross-chain lending/borrowing
• Nolus and Quasar leverage ICA for cross-chain portfolio management

One of the main selling points of ICA is that from an end-user perspective, an action performed on a remote chain is indistinguishable from an action performed on the source chain. Users don’t need to leave the source chain front-end to do actions on another chain. This allows app developers to abstract the concept of cross-chain where users no longer need to know which chain they’re on and which chain they need to go to.

LayerZero

There are multiple ways in which applications can transfer data over LayerZero. Apart from the standard chain A -> B transfer, LayerZero also supports the following message design patterns:

• A -> B -> A: A nested send call from chain A to B that subsequently sends back again to chain A
• A -> B1 -> B2: A composed call sent from chain A to an app B1 on chain B, that calls an external contract B2 on the same chain.
• A -> B1 -> B2 -> A: transfers data from a source to destination, calls an external contract, and then calls back to the source.
• Batch send: A single transaction that can initiate multiple lzSend calls to more than one chain.

These messaging patterns offer application developers a high degree of flexibility to build composable applications. For example, using the A -> B1 -> B2 pattern, a DAO could send funds to another chain's contract and compose a message to execute investments or funding of public goods.

Extensiveness to New Ecosystems

IBC

IBC is currently live on 115 chains including Cosmos app chains, Solana, and Polkadot.

Apart from these networks, the following teams are working on extending IBC to new chains:

• Polymer Labs: IBC for Ethereum rollups
• Union: IBC between Ethereum Mainnet, rollups and Cosmos chains
• Landslide Network: IBC between Avalanche and Cosmos chains
• Cardano Foundation: IBC between Cardano and Cosmos chains
• Composable Finance: IBC between Bitcoin and Cosmos chains
• Datachain: IBC between Ethereum Mainnet and Cosmos chains
• TOKI: IBC support on Ethereum and its L2s, as well as Solana, Avalanche, and Polygon

To integrate IBC on a new chain, the following components are required:

• An IBC transport layer implementation
• A light client of the chain (and of the counterparties that you wish to connect to)
• A relayer implementation

IBC deployment on a new chain is permissionless, allowing developers to implement IBC on any chain without requiring approval from a centralized authority. Teams interested in integrating IBC can proceed independently, without the need to request support or permission from any specific organization or development team.

LayerZero

The LayerZero protocol is live on 83 networks including Solana, Ethereum Mainnet, Polygon, BNB chain, and OP Mainnet.

Integrating LayerZero on a new chain involves:

• Deploying an Endpoint
• Configuring the necessary MsgLibs
• Manually configure DVNs
• Build an Executor or use the default Executor if it supports the new chain

LayerZero integrations follow a permissioned model, requiring coordination with the LayerZero Labs team for new chain deployments. Developers interested in integrating LayerZero must reach out to LayerZero Labs for integration support. The LayerZero Labs team is responsible for deploying and maintaining all Endpoint contracts.

Conclusion

IBC and LayerZero offer robust solutions for blockchain interoperability, each with its own tradeoffs. For projects building cross-chain applications, deciding which protocol to choose will ultimately depend on your specific use cases and interoperability needs.

Given IBC’s light client-backed security, applications and their users receive a higher degree of security while using IBC compared to LayerZero. But in terms of extensibility, LayerZero is currently easier to deploy on heterogeneous environments.

Even though LayerZero offers greater extensibility, all new chain integrations are permissioned and all Endpoint contracts are deployed and maintained by the LayerZero Labs team. In the case of IBC, integrating new chains is permissionless.

In terms of cost, both protocols are similar in the sense that they do not charge a markup for transactions. When it comes to speed, IBC is at least 5.2x faster.

Regarding flexibility and expressiveness for building applications, both protocols have a similar feature set, with IBC offering support for features that LayerZero does not currently offer such as message acknowledgements, timeouts, and middleware support.

As the interoperability landscape continues to evolve, IBC and LayerZero will undoubtedly play a pivotal role in shaping the cross-chain experience, driving forward the vision of a fully interconnected network of networks.