TLDR

• LayerZero is an omnichain interoperability protocol with a mission to connect every contract on every chain. They are able to create a generalistic messaging protocol across any chain through their Ultra Light Client design which makes it cheaper to validate Ethereum and other high throughput chains more broadly.
• LayerZero itself is just a generalized communication protocol, hence it is not focused strictly on being a cross-chain DEX but rather a much grander vision. It is designed to be a low-level messaging protocol so higher-level applications can compose on top of it and provide a wide range of functionalities.
• Initial rollout is planned for EVM chains with plans to incorporate non-EVM chains such as Solana in the future.
• They recently announced planned integrations of IBC data standards for a robust set of communication and token standards that will sit on top of LayerZero’s transport layer.

LayerZero Overview

LayerZero is a new cross-chain communication primitive that will enable a suite of omnichain applications to compose on top of it. LayerZero itself is just a generalized communication protocol, hence it is not focused strictly on being a cross-chain DEX but rather a much grander vision. It is designed to be a low level messaging protocol so higher level applications can compose on top of it and provide a wide range of functionalities. Some of the use cases this can enable include the following applications:

• Cross chain decentralized exchanges
• Cross chain yield aggregators
• Cross chain lending

Note, LayerZero simply provides the communication layer for these applications to be built on top of and they operate at 2 different levels of the implementation stack. LayerZero extends outwards to support all layers, which includes messaging directly between Layer 1 and Layer 2 chains.

As of now, if a DEX wants to go multichain, the application would have to fragment its liquidity across chains. As such, we can take a look at Sushi, which is deployed on over 25 chains but lacks the necessary volumes and TVL to compete with other chain’s native DEXs. Why? Well, it is fragmenting its liquidity across each new chain and cannot port over the liquidity that it has on Ethereum over to Avalanche which only has $500k TVL compared to Trader Joe which has $1.8B TVL at the time of writing. This is not to criticize Sushi but rather to highlight the tradeoffs that protocols make in order to be cross-chain. In short, the liquidity is fragmented and this ultimately hurts the end users who must face exorbitant fees, slippage, use trusted 3rd parties and many other obstacles to bridging across chains. Ultimately, this creates a poor UX for the end user, limits a product’s overall reach, and forces teams to maintain all of the different deployments on X chains they are deployed on (increases complexity and maintenance whereas the time could be spent towards building new features).

Enter LayerZero and the cross-chain vision

So how does LayerZero work? To better understand what LayerZero is, let's take a look at what a communication flow for a cross-chain transaction in LayerZero would look like in practice.

LayerZero is able to bring cross-chain communication by building atop of a primitive they call ‘valid delivery’. This communication enables cross-chain token transfers or any arbitrary data by providing 2 guarantees (as shown in the above flow). The report will be referencing the series of steps shown in the diagram above throughout the rest of this report. The 2 guarantees of valid delivery include the following:

1. Every message sent over the network is coupled with a transaction on the sender chain.

2. A message is delivered to the receiver if and only if the associated transaction is valid and has been committed on the sender-side chain.

Note, the only requirement to ensure ‘valid delivery’ is that every message sent using the LayerZero protocol, requires the Oracle and Relayer to be independent of each other.

LayerZero Components

We explained what LayerZero enables and defined the primitive of ‘valid delivery’ but let's dive into the components of LayerZero. It is made up of multiple components - Endpoints, an Oracle and a Relayer. We will cover each core component below starting with Endpoints.

Endpoints

Going back to Figure 4 above, we can see that the LayerZero Endpoints are the user-facing interface (Steps 1 + 13). They are made up of four modules: Communicator, Validator, Network and Libraries (not shown). The Endpoint’s core functionality revolves around the Communicator, Validator and Network, while each new chain is added as an additional Library. This ensures a modular design that enables LayerZero to seamlessly add new chains without modifying the Endpoint’s core modules.

Endpoints are currently implemented as a series of smart contracts on each chain that is included in the network. The workflow is as follows for a cross-chain transaction:

Sender: Messages are sent down the stack on the sender side; Communicator -> Validator -> Network (Steps 2-3)

Receiver: Then the messages are sent up the stack on the recipient side; Network -> Validator -> Communicator (Steps 9 and 12)

As mentioned before, each new chain can be added by extending Libraries. These Libraries are auxiliary smart contracts that define the communication standards for a given chain. Each chain in the network has its own Library and each Endpoint keeps a copy of every library. Hence, for any two chains to communicate, they only need their respective libraries on both ends.

Given that Endpoints exist as smart contracts running on multiple layer 1 chains, how does it ensure scalability without incurring prohibitive costs? For example, running a light client for Ethereum would incur millions in fees. The answer can be found in the design of their light client, which is designed to be ultra-light and called the Ultra Light Node (ULN). It does this by delegating the tasks of fetching the necessary cross-chain headers and transaction proofs to off-chain entities- the Relayer and the Oracle. It streams 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 (Step 8). The submitted header will be cross-verified with the transaction proof submitted by the Relayer (Step 11). In short, it aims to have the security of a light node with the cost-effectiveness of middle chains.

Oracle

The oracle is used to read a block header from one chain (Step 6)and send it to another chain (Step 8). This can be any 3rd party service but they intend to use Chainlink amongst other oracles. At the time of writing, they use their own oracles and not Chainlink.

Relayer

Is an off-chain service that functions similar to the Oracle. Rather than fetching block headers, it fetches the proof for a specified transaction (Step 7).

Security

Again, ‘valid delivery’ is ensured by making the Oracle and Relayer independent by design. This allows for LayerZero to remain lightweight in design and ensure the security of the protocol. In order for an attack to take place, it would require both the oracle network and the relayer to be compromised or colluded.

However, what if the Relayer and the Oracle network are the same entity and they are colluding together by agreeing on everything? The worst case security of this configuration is the equivalent to the best case security of the chosen oracle. For example, if Chainlink is used as the oracle, the worst case is the oracle and the relayer are the exact same entity. This still has the base case security as being as secure as the Chainlink DON.

Let's better understand the cross-chain landscape by comparing the other implementations in the market today.

Cross-Chain Comparison Table

LayerZero Implementing IBC

Much of the Cosmos ecosystem is interoperable via Cosmos’s Interblockchain Communication Protocol (IBC). It went live for token transfers in March 2021 and now has over 25 chains securing over $60B in value at the time of writing. Although IBC is effective for connecting Cosmos Zones, it has largely been restrained from connecting to Ethereum or other EVM based chains due to its current transport layer.

IBC itself defines a generalized standard for how communication can be done between two chains. It also has a set of standards that define how messages should be formatted for token transfer. As mentioned in the table above, the IBC transport layer requires a full light client between the connected chains. This is extremely cost-prohibitive for Ethereum and most EVM chains. Additionally, IBC was not designed for other concensus protocols, so there must be custom light clients written for other chains that dont use Tendermint. To resolve this without reinventing the wheel, LayerZero adopted IBC by swapping out IBC’s transport layer with its own. Now IBC can reach all chains that LayerZero can connect to through its transport layer.

So what does this mean? Are IBC and LayerZero competitors or symbiotic? In short, the future of interchain communication is a single standardized protocol like IBC which is the data layer and it will run over many diverse blockchain communication protocols such as LayerZero or other trusted cross-chain solutions who are the transport layer.

Key Takeaways

• We are excited to see the applications that will leverage LayerZero’s communication protocol for higher-level applications. LayerZero resolves some of the bottlenecks seen with other cross-chain implementations by building out an ultra light client and building out an isolated risk model via their offchain Relayer and Oracle and Library architecture for onboarding new chains.
• As seen with the recent integration with IBC, LayerZero provides a communication-agnostic transport layer for any token or messaging standard to live on. This will be a key feature in defining the future of interchain communication.
• We believe that LayerZero is well positioned for a cross-chain world. We are more so excited to see them have a cross-chain DEX, as there is a very large demand for that and many competitors in the landscape trying to solve the same problem.