This is the first of a serie of posts describing existing cross-chain communication protocols and standards. The goal of these entries is to develop a common understanding of current techniques and open problems about blockchain interoperability.
Figure 1: Simplified workflow. Application X on chain L2a sends a message to Application Y on L2b. LZE and DVN stand for LayerZero endpoint and Decentralized Validation Network respectively. A more detailed workflow can be found at How it works | LayerZero .
Layer Zero is one of the most established cross-chain interoperability solution with a large ecosystem of 160+ partners and more than 140 millions of messages processed over 100+ chains. One of the reason of the success of this project is the focus on providing the best developer experience through a simple design and a collection of standards.
How does Layer Zero work?
To understand Layer Zero it helps to think about how the Internet works. One of the main challenges when designing a communication protocol is the heterogeneity of the parties involved. In the case of Internet, computers run on different hardwares, operating systems, configurations etc… To solve this, the TCP/IP protocol separates how the information is encoded (packets) and how it is processed via different layers of abstraction (low level routing, logical routing, session and application handling). Similarly smart contracts are deployed on different chains, executed by a different set of nodes etc… Like in the case of TCP/IP, Layer Zero establishes clear boundaries between each step of a message life cycle: encoding, routing, decoding, validation, and execution. In practice (see Figure 1) for an application on chain L2a to send a message on chain L2b we go through 5 steps:
- The application (App X) sends a message to the Layer Zero endpoint (LZE) contract. The LZE contains configuration needed to route and validate the message as well as post-processing logic for managing fees.
- The LZE will emit an event (published on L2a). Such event contains contains the “packet” that is read by the (offchain) validators of the Decentralized Verifiers Network (DVN).
- The validator after checking the packet will send some proof/ certificate (e.g. signature) to the destination chain LZE.
- After enough proofs have been collected, the Executor will “commit“ the message making it available for the destination chain application (App Y).
- The same Executor (or another) releases the message to App Y.
Layer Zero modular design
Layer Zero modular design is achieved by:
- Separating execution from verification. Layer Zero separates the execution of the message from its validation. This modular approach allows developers to choose their DVN and explore different security / cost tradeoffs while avoiding the pain of having to change the application contracts code.
- Separating message syntax from its semantics. The message payload, as in the case Internet is an arbitrary sequence of bytes. It is up to the sending/receiving contracts to define the meaning. This differs from other interoperability solutions (e.g. LxLy bridge) where the message is meant to transfer some asset or call a function on the destination chain. Such flexibility makes it easier to develop applications with stable interfaces. Another important consequence of this design is that Layer Zero is VM agnostic.
- Separating core protocol security, message validation logic, and application security.
- The core security invariants of Layer Zero are censorship resistance and replay attack protection. These are handled by the LZE contract and cannot be changed as the LZE contract is immutable. These two invariants ensure each message is delivered to the receiving application exactly once.
- Message validation specific to the chosen DVN can be customized via
MsgLibs
extensions (see Figure 1) which are append only libraries and define the logic for emitting events on the source chain and verifying them on the destination chain. Examples of such validation logic can rely on zero-knowledge proofs, signature quorums, or existing bridges. - It is also possible to define application specific validations. For example a validator could simulate the execution of the message to be delivered on the destination chain, and accept only if some application invariant is satisfied (e.g. the total amount of tokens minted is less or equal to the total amount of tokens locked.) .
Beyond its modular design, Layer Zero has other relevant properties. First of all Layer Zero takes care of gas management in a transparent way, which means that a user does not need to have funds on the destination chain to send a message. While Layer Zero currently only supports asynchronous communication, it is possible to compose actions on the destination chain by leveraging the lzCompose
interface. Such feature can be used for example to bridge a token from chain A to chain B and then swap this token for another. Finally performance depends essentially on the chosen DVN, as Layer Zero minimalistic design adds little overhead especially regarding gas cost.
We summarize the main properties of Layer Zero in the table below:
Property | Comment |
---|---|
Communication pattern | External validators set (DVN) + relay (Executor) |
Composability | Asynchronous |
Performance | Depends on the DVN. Non DVN-related gas cost are minimal. |
Security | Depends essentially on the DVN (both nodes behaviour and validation algorithms), assuming the immutable LZE contracts are correctly implemented. |
Supports multiple VMs | Yes |
Usability | Gas is managed by Layer Zero so users do not need funds on the destination chain. |
Towards Synchronous Composability
Current deployed interoperability solutions including Layer Zero only provide asynchronous composability. In practice this means that if a contract on the source chain makes a cross-chain call in block number X, the changes to the state implied by such call will be effective in block number Y where Y>X. While asynchronous composability covers already a lot of use cases, synchronous composability is required for more advanced cross-chain applications such as flash loans.
lzread, is a recent and exciting feature of Layer Zero that allows any contract to request information stored on other chains. Applications include cross-chain price feeds, governance and liquidity pools rebalancing. While lzread
is still an asynchronous communication primitive, it involves a back and forth communication between contracts deployed on different chains (contract X deployed on chain A requests data to contract Y deployed on chain B, contract Y replies with the requested data to contract X). It would be interesting to explore how block builders / sequencers could be integrated with Layer Zero in order to make this interaction happen in a single block, turninglzread
into a synchronous cross-chain read feature.