LayerZero as an IBC Transport Layer

tldr; A more technical dive into IBC on top of LayerZero

An omnichain interoperability protocol is expected to enable secure, ordered, and generic message transport between any two contracts on different chains. To that end, IBC defines a set of standards defining a generic message Transport Layer that includes data structures, abstractions, and semantics, which once implemented by participating chains will allow them to safely communicate. On top of the Transport Layer, IBC also defines an App Layer with a set of standards, like ICS-20 for fungible tokens, that defines how messages should be interpreted.

However, IBC’s Transport Layer is expensive to use and has limited connectivity across chains. By swapping out IBC’s Transport Layer with LayerZero, we can bring omnichain connectivity to IBC and benefit the IBC’s ecosystem as a whole.

LayerZero v.s. IBC’s Transport Layer

Firstly, IBC’s Transport Layer governs how light clients store and verify data (ICS-2, ICS-23), perform connection handshake (ICS-3), and establish message channels (ICS-4). It is a full light client implementation that requires an explicit on-chain full headers sync for the handshake to succeed. Any message passing is performed by The Relayer as specified by the ICS-18. However, running a full light client is cost-prohibitive in most EVM-based chains and thus limits its usage.

LayerZero relaxes the on-chain full header sync assumption by streaming block headers on-demand from the Oracle, which is an implicit way to reach the desired full header sync state through a more efficient off-chain entity. The submitted header will be cross verified with the transaction proof submitted by the Relayer. LayerZero contracts abstract the transaction proof of different chains as Libraries. For example, Ethereum and Tendermint are using different serialization formats (RLP vs go-wire), signature schemes (secp256ka vs ed25519), and data structure (Patricia Trie vs IAVL+ trees).

In breaking up responsibilities between the Oracle and Relayer, LayerZero leverages the security properties of established Oracles such as Chainlink and Band with an additional layer of security via the open relayer system. The system would only break if the Oracle and the Relayer collude, as it is statistically impossible to send a transaction proof that can be validated against a block header without knowledge of that specific block header, and vice versa.

Another major problem of IBC’s transport layer is that it only allows direct communication between blockchains with deterministic finality. The safety of higher IBC abstraction layers and guarantees for applications depend on this property of finality. For IBC to work with proof-of-work systems (which have a probabilistic finality), an adaptor zone imposing a finality threshold is needed (e.g. “peg zone” defined in sifchain).

LayerZero natively resolves the above problem as it can work seamlessly with transactions of both deterministic and probabilistic finality. In the latter case, the oracle acts as the agent that enforces the necessary finality threshold. This property allows LayerZero to work with heterogeneous ledgers with varied network topology and consensus algorithms.

Thank you to Kyle Samani, Zaki Manian, John Robert Reed, Bryan Pellegrino, and Ryan Zarick for your review.