LayerZero - Deep Drilling

On April 4th, LayerZero Labs completed a US$120 million Series B round of financing at a valuation of US$3 billion, with participation from a16z Crypto, Christie’s Auction House, Sequoia Capital, Samsung Next, BOND, Circle Ventures, and OpenSea Ventures. Funding from the round will be used for growth initiatives, including hiring and expanding the company's presence in the Asia-Pacific region.

This article explores LayerZero's design, security, and trust assumptions. LayerZero is an Arbitrary Message Bridging (AMB) technology that focuses on connecting blockchains with as little additional trust as possible.

This article will cover the following topics:

LayerZero Overview

How it works - transaction lifecycle

security features

trust assumption

overview

LayerZero is a general-purpose data messaging protocol called a "full chain solution". It aims to pass lightweight messages between blockchains through efficient gas usage, non-upgradeable smart contracts.

The main advantage of LayerZero is that no additional trust assumptions are required when verifying Cross-chain transactions. Common LayerZero features include:

• Simplicity - LayerZero aims to put developers first. Building user applications with LayerZero requires only the implementation of two functions - send and receive. If you can write in Solidity, Rust, etc., you can build applications on-chain in no time. Furthermore, since there is no "middleman" in the system, two high-throughput chains can interact freely.
• Lightweight Clients - Running smart contracts at Layer 1 can be extremely expensive. Therefore, LayerZero exports the storage and extraction of transactional data to Oracles and Relayers, the relationship of these two off-chain entities ensures efficient transactions, thus allowing ultra-light node endpoints to be small and cost-effective. In addition, the low operating cost of its lightweight client enables rapid integration of new chains.
• Potential - As the name suggests, LayerZero is the underlying component of the infrastructure that can be used by many Dapp such as Liquidity networks, Multichain yield aggregators, Multichain lending protocols, etc. to build super interesting and unique Multichain encryption use cases.
• LayerZero Scanning - Cross-chain transactions are now bound in a single database via LayerZero scanning, allowing users and developers to easily obtain status information and timing information for transactions.

How it works - transaction lifecycle

The most basic components of LayerZero are the "Endpoints" found on the support chain. These endpoints are implemented as a series of smart contracts that allow communication between domains, with each chain having its own "library" in the LayerZero system. Each endpoint is equipped with a message library native to the endpoint's domain, and a proxy to ensure that the endpoint uses the correct library version. Once deployed, endpoints act like smart contracts that cannot be closed, allowing an immutable flow of messages.

From there, LayerZero relies on two off-chain entities, an oracle (Oracle) and a relay (Relayer) , to pass messages between endpoints found on different domains. In this setup, the Oracle of domain A (like Chainlink) forwards block headers to domain B, while a separate relayer passes transaction proofs from domain A to domain B. If the two match, and the proof is verified by the block header, the Cross-chain message will be sent to the destination address.

To summarize the relationship between oracles and repeaters:

• The job of LayerZero’s oracles is to pass common data (aka block headers) from the source domain to the target domain. It is a third-party service that is expected to run through ChainLink.
• And the job of the relayer is to obtain the proof of the specified transaction. Notably, under the parameters set by LayerZero, anyone can become a relayer, which helps ensure that the system is decentralized.

The only important condition for oracles and repeaters is that they must operate independently without collusion. If they don't collude, then LayerZero is safe. But if the oracles and repeaters somehow collude, LayerZero's security structure will be compromised.

In LayerZero, a transaction/message only needs to provide source gas in a single call. A transaction begins when a user application (UA) initiates a transaction (i.e. performs some action on-chain). This transaction is then broken down into parts (proof and header) with the assistance of LayerZero endpoints via oracles and relayers. Once the oracle and relayer send their respective messages from the source chain, and the LayerZero Endpoint verifies the correctness of the message, the message is transformed and executed on the target chain.

A general transaction on LayerZero will follow the following steps:

Let's break down the process step by step:

• Step 1: User application (such as Stargate) uses LayerZero's reference relay and performs a series of operations as a transaction. The user application sends a request to LayerZero's communicator , including transaction information such as transaction identifier, data transferred from A to B (payload), or identifier pointing to the user application smart contract on Chain B.
• Step 2: The communicator sends these data to the validator in the form of LayerZero packets.
• Step 3: The validator sends the transaction identifier and the identifier of the smart contract on chain B to the network . As a result, the network is notified that it needs to send the block header of source chain A to target chain B.

To summarize steps 1-3 - the user application packages and transmits the data to the LayerZero endpoint located on Chain A.

• Step 4: The validator forwards this information to the relayer . As a result, relayers are notified to prefetch transaction proofs and send them to Chain B.
• Step 5: The network sends the identifier of the smart contract on Chain B together with the block ID of the transaction block to the oracle. As a result, the oracle is told to fetch the block header of the current block on Chain A and send it to Chain B.

In summary, steps 4-5 are - LayerZero's endpoint on Chain A sends transaction information to LayerZero's reference relay, and the block ID of the transaction block is sent to the oracle.

• Step 6: The oracle obtains the block header from Chain A.
• Step 7: The relayer receives the transaction proof from Chain A and stores it off-chain.

To summarize steps 6-7 - the relayer and the oracle receive the transaction proof and block header from Chain A respectively.

• Step 8: The Oracle waits for a certain number of block confirmations, and then confirms that the block has been successfully committed on Chain A. After confirmation, the oracle sends the block header to the network on Chain B.
• Step 9: The network sends the block hash to validators.
• Step 10: The validator forwards the block hash to the relayer.
• Step 11: The relayer sends a list of all data structures that match the current block.
• Step 12: The validator ensures that the transaction is valid and committed by looking at the transaction proof and block header stored on the network. If the block header and the transaction proof match, the transaction information is sent to the communicator in the form of a Packet.
• Step 13: The communicator sends the information (Packet) to the user application on Chain B.

To summarize steps 8-13 - LayerZero's endpoint on Chain B uses block headers to get the information initiated by the user application on Chain A and sends it to the user application on Chain B.

In this way, user applications can use LayerZero to send transaction information (such as tokens) from Chain A to Chain B.

safety

LayerZero offers the following security features:

• Efficient Delivery - The independence of oracles and relays is the foundation of LayerZero's security. If the block headers and transaction proofs provided by two independent entities match, the delivery of the transaction is valid. Otherwise, it has no effect. This is a very secure mechanism, since the statistical probability of a transaction proof matching a block header is low without prior knowledge of other aspects.
• Expensive to attack - At worst for LayerZero, the oracle and relay could be run by the same entity and collude maliciously. This means that the block headers and transaction proofs provided by oracles and relayers are invalid, but they still match due to malicious collusion overriding the system. However, even if oracle 1 and relayer A collude maliciously, this is an isolated risk because only applications that use oracle 1 as an oracle and relayer A as a message will be affected. All other oracles and relays will continue to function normally . As a result, the cost of attack becomes very high and the reward is small because you can only attack a specific pool of funds, not the funds of the entire system. But this is a small risk, because if a user application has a specific risk prevention mechanism and does not trust a specific configuration of oracle or relay, it can choose to run part of it itself to eliminate the possibility of collusion.
• Simple and effective design - LayerZero doesn't add any extra bells and whistles to its bridge mechanism with tokens, locking and minting mechanisms, etc., so LayerZero's security can be traced back to the chain where its endpoints reside.
• Risk Diversification - LayerZero allows user applications to choose different oracle/relay combinations to spread the risk of trying to get two separate entities to collude through bribery or malicious attacks.
• Risk shielding - users can run their own relayers, which means that users want to trust LayerZero, then all they need to do is run their own relayers and trust Oracle to be independent of them.
• Pre-Crime - This feature allows repeaters to stop hacking events before they happen. Before delivering messages, relayers can fork on the target blockchain and run transactions locally in order to verify that no malicious actions (defined by each user application) have occurred. This provides an additional layer of security for Dapp auditing and bug bounties.
• Audits - LayerZero has been through more than 20 formal audits, including Quantstamp, Zokyo, Zellic, and Trail of Bits. Additionally, LayerZero currently hosts a $15 million bug bounty through ImmuneFi and has shown a penchant for rewarding white hat hackers.

trust assumption

LayerZero makes the following trust assumptions:

• Progressive decentralization - the number of repeaters on the LayerZero network will increase, which is the most important security mechanism for gradually decentralizing the messaging system.
• Reliance on Relays and Oracles - LayerZero users rely on the security of relayers and oracles to pass messages Cross-chain. There is nothing on-chain related to funds and data itself.
• Operational Risk - LayerZero relies on third parties (oracles and relayers) for its functions, which increases operational risk beyond LayerZero's control.
• Dependent on the security of the chain - LayerZero does not add intermediaries to conduct Cross-chain transactions, but it does rely on the native chain where the endpoint is located to operate correctly. If a chain is 51% attacked, it is uncertain how LayerZero will handle such an event.