Partnered With:

Explanation of LayerZero Interoperability Protocol: Technology Principles and Features.

Read this article in 47 Minutes

This article comprehensively reviews the mainstream models in the cross-chain field, the technical principles of layerZero, provides a detailed explanation of the cross-chain lifecycle, and conducts a comprehensive analysis of its protocol advantages and

Original Title: "LayerZero Technology Principles and Analysis of Advantages and Disadvantages: Why is it Valued at 3 Billion US Dollars"

Source: Fourteen Jun

Foreword

Within just one year, the full-chain interoperability protocol LayerZero has once again raised $120 million at a valuation of $3 billion, triple the previous valuation. Investors include a16z, Christies Inc, and Sequoia Capital.

A ten-thousand-word research report will comprehensively review the mainstream models of cross-chain technology, the technical principles of layerZero, provide a detailed explanation of the cross-chain lifecycle, and conduct a comprehensive analysis of its protocol advantages and disadvantages.

This article is the first part, focusing on discussing the technical solutions of LayerZero and evaluating its advantages and disadvantages.

1、LayerZero Technical Principles

1.1 Overview

LayerZero is a cross-chain communication protocol that provides trustless communication. Its essence is to utilize the technology principles of light nodes and design a mechanism for super light nodes. By dividing the intermediate trust link into two parts through relays and oracles, it achieves better security at a lower cost.

Attention, LayerZero's focus is not on asset cross-chain, but on higher-level message cross-chain. As a bottom-layer protocol, the application layer of asset cross-chain is a subset of it. More specifically, asset cross-chain is also developed by Layerzero Labs, called Stargate.

1.2, What is a light node?

The communication link between cross-chains is mainly completed through external verification or on-chain light nodes. Firstly, a light node is a node operation mode, and there are also full nodes and archive nodes. Different nodes of the same chain are a reduced version of the chain information. Light nodes only save all historical block headers and do not store specific transaction information within the blocks.

With multiple Merkle Roots of block headers, it is possible to use Merkle tree verification to determine whether a transaction truly exists in this block.

【Ethereum's EVM virtual machine architecture diagram from official GITHUB】

The benefit of running verification on the chain through light nodes is the complete elimination of external role interference from notaries, achieving a high degree of decentralization based on the security of the chain, thus making it more secure.

However, this will result in even higher cross-chain costs, which will ultimately be borne by users with cross-chain needs. The author once estimated the cost of storing NFT metadata in KB units.

Expand reading: 【Source Code Interpretation】What is the NFT you bought?

1.2, What is a super light node?

Ultra-Light Node (ULN) is actually very simple. Compared to a light node, an ultra-light node performs the same verification as a light node on the chain, but does not preserve all block headers in order. Instead, they are streamed on demand by dispersed oracles.

Its benefit is that it does not rely on the block header data flow from the light node to start.

The cost, however, is the lack of historical sequential data flow, which means that once the oracle and relay are both malicious, they can pass verification and allow malicious information to be executed.

The trade-off between the loss of a certain degree of security and the significant reduction of costs depends on how everyone weighs it based on their own scenarios. Referring to the design of social protocols such as Lens, the value of information that social attention focuses on is not too high. Therefore, it is optimistic to perform meta-transactions while ensuring application-level isolation, and it is also advisable to execute first and trace later.

2、LayerZero's Cross-Chain Core Role

In the LayerZero official whitepaper shown in the following image, the green section plays a crucial role in facilitating information transfer between two chains, namely Oracle and Relayer.

【LayerZero Official Whitepaper from Official Website】

2.1, Positioning of Oracle and Relayer

In short, the main function of Oracle is to let the contracts on the target chain know when to verify and what the verification answer is. The Relayer is responsible for providing the proof process required for verification transactions and the specific content of cross-chain information.

The author also mentioned in the previous research report 4337 that the current 4337 contract still needs to access off-chain oracle price services to truly achieve the function of multi-currency payment transaction fees: expand reading Interpretation of the Approval Plan for the Abstract of Ethereum Account ERC4337.

In short, Oracle plays the role of a notary in LayerZero cross-chain. Perhaps due to such malicious motives, the security of the oracle is almost equivalent to the value of on-chain Defi. Too many lending products rely on the oracle to provide prices. If it is willing to act maliciously, there are more profitable things to do.

2.2, Division of Labor between Oracle and Relayer

The role of an oracle is: to transmit the Blockhash and Block Receiptsroot of the cross-chain request on the source chain to the target chain.

Blockhash is the block hash that informs the contract on the target chain which block contains the user's cross-chain request.

Block Receiptsroot is used to verify the messages passed by the transaction relay.

The role of a relay is: to transmit the path information required for the cross-chain message's Receipt and Merkle Proof to the target chain's contract for verification.

其中 Receipt refers to the transaction receipt information, which mainly includes the transaction execution result, transaction hash, and transaction event log.

Transaction execution result: whether the transaction on the source chain was successful or not.

Transaction hash: The globally unique hash of each transaction.

Transaction event log: Understand the specific content of cross-chain information.

The path information here is the red arrow in the following figure. For example, after the relay sequentially informs the L2 -> Hash 0-0 -> Hash 1 information to the on-chain node, comparing it with the TopHash given by the oracle, and after the secondary calculation based on the information contract provided by the relay is consistent, it indicates that the relay is correct.

2.3, LayerZero's Cross-Chain Lifecycle

After understanding the work of the middle area cross-chain role, let's make a transaction from ChainA to ChainB. Both boxes on the left and right in the following figure interact with the endpoint contract on their respective chains.

LayerZero Official Whitepaper from Official Website

The overall process is outlined as follows:

A transaction starts from a user application (UA) initiating a transaction (i.e. executing some operations on the chain). Then, with the assistance of oracles and relayers at the LayerZero endpoint, the transaction is broken down into multiple parts (proofs and block headers). Once the oracles and relayers have sent their respective information on the target chain (signing the transaction on the chain), and the LayerZero Endpoint (contract) has verified the correctness of the information, the message will be transformed and executed on the target chain.

The detailed steps are as follows (refer to the above picture):

Step 1: The Communicator of the User Application UA (such as the Stargate Bridge) of LayerZero sends a request, including the transaction identifier t, the data transferred from A to B (payload), or the identifier or relay_args of the user application smart contract on Chain B and other transaction information.

Step 2: The communicator sends this data to the validator in the form of a LayerZero packet.

Step 3: The validator sends the transaction identifier and the identifier of the smart contract on Chain B to the network layer (NetWork). The network layer's work is also triggered, and information to be transmitted needs to be sent from the source chain A's block header to the target chain B through an oracle.

Step 4: The validator forwards this information (packet) to the relay. Once the relay is notified, it retrieves the transaction proof (Proof from Step 7) stored off-chain and sends it to Chain B (Step 11). The endpoint of Chain B can also initiate a request to obtain the result of a specified block hash (Step 10).

Step 5: The network layer sends the identifier of the smart contract on Chain B and the block ID of the transaction block to the oracle. When the oracle is notified, it retrieves the block header of the current block on Chain A (Step 6) and sends it to Chain B (Step 8).

It can be seen that parts 6, 7, 8, 10, and 11 are actually embedded in the links of the relay and oracle.

Step 9: The network layer sends the obtained block hash to the validator (triggering the verification of the super light node).

Step 12: The validator ensures the transaction is valid and submitted by checking the transaction proof and block header stored in the network layer. If the block header and transaction proof match, the transaction information (Packet) is sent to the communicator.

Step 13: The communicator sends the information (Packet) to the user application on Chain B to perform any function.

Cross-chain as a whole is the Gas fee charged when the first transaction is executed on the source chain, and it corresponds to three transactions on the target chain, consisting of a relay, an oracle, and Layer Zero: Executor (an EOA account).

3、How to evaluate the advantages and disadvantages of the LayerZero protocol?

3.1, Is it dangerous to rely on oracles?

If there is only one relayer or one oracle, there may be a real danger (which is beyond the scope of protocol management), but currently layerZero implements that any application can customize its own relayer and even choose different oracles to support its system.

Even if some relayers are down or not working for some purpose, in the gradual market competition, a many-to-many selection pattern will be formed, and decentralized mutual supervision will be formed between their respective games, similar to the mining mechanism.

Even if Oracle 1 and Relay A collude maliciously, this is an isolated risk, as only applications that use Oracle 1 as an oracle and Relay A as information will be affected.

And LayerZero is just the mechanism for transmitting information at the lowest level. As for how upper-layer applications use the transmitted information, it can be defined and secured separately. For the protocol itself, it does not store funds or data, which reduces the likelihood of it being attacked.

Therefore, because the funds are dispersed, it makes the cost of hacking higher and the return lower.

Currently, LayerZero has undergone over 30 official audits, including Quantstamp, Zokyo, Zellic, and Trail of Bits, among others. Additionally, it currently hosts a $15 million bug bounty program through ImmuneFi, which is the largest real-time bug bounty program in the industry! So far, LayerZero has rewarded nearly $1 million to disclosed white hat hackers.

3.1, Advantages of Comparing Cross-Chain Products at the Protocol Level

Consistent with the previous conclusion, the extremely low cost of cross-chain security verification is a major highlight, while the security of highly trusted oracles is compromised. Excluding security factors (after all, it can be strengthened at the application layer), the low protocol access cost and universality for developers are the hidden advantages that the author sees.

Greater universal scalability

In the current cross-chain at the protocol level, as well as the IBC protocol in the Cosmos ecosystem and the XCMP cross-chain protocol in the Polkadot ecosystem, their limitations in scalability refer to the fact that in order to verify transactions on other public chains from Ethereum, corresponding light nodes must be deployed on Ethereum. The high gas costs associated with this make it difficult for many EVM-compatible chains (such as ETH/BSC/Polygon/L2, etc.) to support the IBC protocol, greatly limiting its universality. Therefore, currently it can only run between relatively niche Cosmos ecosystem chains.

Lower complexity for developers to access

The workload of the underlying protocol has been placed on the extremely simple contract access design from the beginning. The demand for cross-chain messaging scenarios is extremely high, such as cross-chain lending, yield aggregation, and trading, just to name a few. Due to its convenience and ease of development, the protocol has already transmitted millions of messages on more than 30 chains' Dapps (including decentralized exchanges such as PancakeSwap, SushiSwap, TraderJoe, and Uniswap), and its application bridges have locked in a total value of over 7 billion US dollars (the TVL in the recent article is 400 million US dollars).

解除多链碎片化的兼容性
解除多链碎片化的兼容性 translates to "Resolve the compatibility of multi-chain fragmentation" in English.

In the lock-up casting mode mentioned earlier, the generated packaged tokens are a kind of fragmentation phenomenon for multi-chain funds. LayerZero uses non-packaged asset methods, supports both EVM and non-EVM, has a unified liquidity layer, and can bundle complex transactions such as original chain exchange, bridging, target chain exchange, and pledging when assets cross chains.

3.3, Summary

【Cross-chain solution interpretation: https://research.web3caff.com/zh/archives/7592】

Cross-chain is one of the important investment tracks in the multi-chain pattern. It has high certainty and clear business models in the market, and has generated high revenue in the immature stage. As a communication protocol embedded in the basic code of various Dapps, the protocol itself has become one of the lowest levels in the Lego blocks.