LayerZero — Part1: Cross-chain Messaging
1. Cross-Chain Messaging Protocol
1.1. Introduction
Early in 2022, Vitalik Buterin posted a message on Twitter with the following gist:
the future will be multi-chain, but it will not be cross-chain
The more a blockchain or protocol relies on cross-chain, the greater the security vulnerabilities of that blockchain or protocol become. Therefore, it’s important for each blockchain to solidly build its own ecosystem. However, as the blockchain ecosystem evolves with an increasing variety of chains, cross-chain solutions become inevitably more important. From the user’s perspective, enhanced interoperability between blockchains means increased capital efficiency through chain-to-chain swaps and asset management. Additionally, for builders and blockchains, cross-chain solutions can be highly beneficial as they allow one’s application to attract customers from other chains.
In this article, we will explore the cross-chain solution Layer Zero, which has recently attracted attention due to significant investment and anticipation surrounding its token launch. We will examine its significance and limitations.
1.2. Cross-Chain Messaging Protocol
A cross-chain messaging protocol refers to a set of communication rules that allow sending messages across multiple chains. An important aspect of cross-chain messaging is validation. Let’s understand this with an example.
Suppose Alice wants to send USDC from Chain A to Chain B. Alice needs to do two things:
- Perform the task of locking up USDC on Chain A,
- And simultaneously send a message to Chain B saying, ‘I have locked up USDC on the A network, please mint USDC here!’, requesting the operation.
The problem here is that Chain B cannot trust the message sent by Alice saying, ‘I have locked up USDC on the A network, please mint USDC here!’. In other words, Chain B requires proof from Alice that the transaction has been executed or that it has been properly completed.
Cross-chain protocols can be broadly divided into two categories based on how they implement this verification step:
- An external validator verifies Alice’s action (USDC lockup) on Chain A and produces a proof guaranteeing it, which is then conveyed to Chain B.
- Alice brings the transaction proof and the block header containing that transaction directly from Chain A to Chain B to verify that her transaction is indeed included in Chain A.
We will explore this in more detail in the sections below.
1.3. Cross-Chain Messaging Protocol (1) — External Validators
Using external validators for proof is the most commonly used cross-chain protocol. In this protocol, message creation and validation occur as follows:
- A message is created containing data such as which target chain the user wants to perform the operation on (Destination Chain), and what kind of operation they want to perform (Payload), based on events within the transaction.
- The validity of this message is verified by an external validator or a group of validators, who then create a proof and send it to the target chain.
Cross-chain protocols with this mechanism can be divided into three types: centralized bridges, middle chains, and bonding protocols.
1.3.1. Centralized Bridges
Centralized bridges operate by having a centralized validator or administrator verify the validity of messages between different chains. For example, Wormhole uses validators known as Guardians who create Verifiable Action Approvals (VAA) for the messages and send them to the target chain.
However, as the name suggests, centralized bridges have inherent issues due to their centralized nature. Although some protocols use multi-signature or Multi-Party Computation (MPC) technology to distribute authority, they still rely on designated entities as validators, requiring trust in them, which is a clear limitation.
Centralized bridges have faced various problems to date. Notable examples include last year’s hacking of the Ronin and Wormhole Bridges, and the recent suspension and hacking of Multichain. Both Ronin and Wormhole relied on a centralized set of validators to verify the validity of cross-chain messages, and the bridges’ assets were compromised due to the theft of private keys and signatures. The total damage from these two bridge hacks amounted to $950 million.
In early June this year, there was an incident where the CEO of Multichain became incommunicado in China. As a result, the Multichain team lost access to router server management that the CEO had, leading to the suspension of cross-chain services for blockchains like Kekchain and PublicMint due to an inability to respond to node network problems.
In early July, private keys of the SMPC wallets on the Fantom and BNB chains operated by Multichain were hacked, resulting in the theft of approximately $120 million.
This too can be attributed to the side effects of having a centralized node network.
1.3.2. Middle Chains
Middle chains are a type of cross-chain messaging protocol that aims to resolve the issues of centralized bridges by conducting message verification on a separate intermediate blockchain. Let’s examine this through the example of Celer Network.
Celer Network has established a Tendermint-based middle chain called the State Guardian Network (SGN), which performs the verification of inter-chain messages. Validators in SGN sign user-created messages based on $CELR token-based voting, and verification is completed if it receives more than 2/3 of the votes.
While this middle chain approach conceptually has the advantage of being more trustless than centralized bridges, if the number of validators is small or the market capitalization of the coins used in the chain is low, the network itself can still become a single point of failure.
Currently, the Celer Network is composed of 20 validators, and the total amount of $CELR tokens staked in the protocol is around $130 million. Therefore, with just one-third of this amount, about $36 million, it would be possible to launch an attack on the Celer Network.
1.3.3. Bonding Protocols
Bonding protocols, unlike middle chains, do not have a separate consensus algorithm. However, they provide a degree of safety for users’ fund transfers by implementing a structure for slashing and rewards. Notable examples include Polygon PoS Bridge and Hop Protocol. Let’s briefly explain using Hop Protocol as an example.
Hop Protocol’s off-chain bridging service is centered around Bonders and operates in an optimistic manner. Each Bonder is responsible for verifying messages during the process of bridging users’ assets between Layer 2s. To prevent users from being harmed by malicious actions of Bonders, Hop Protocol requires Bonders to stake a certain amount of funds. If a Bonder’s malicious message verification results in harm to a user and it’s discovered, a portion of the Bonder’s stake is slashed. This method allows Hop Protocol to deter malicious activities to some extent.
1.4. Cross-Chain Messaging Protocol (2) — Block Header & Transaction Proof
The method of delivering custom messages as described above requires a validator, and there are disadvantages and trust costs if these validators act incorrectly or maliciously. To address this in a more trustless manner and verify on-chain, light client bridges have emerged.
A light client is a type of node that stores only specific data, not all data in a blockchain. Light client bridges use this to perform message verification through specific data tracked by the light client, enabling trustless inter-chain communication.
1.4.1. Light Clients
The light client approach to cross-chain protocol does not use separate validators but verifies by bringing the block header and transaction hash from the source chain to the target chain. Let’s take Cosmos as a representative example.
Cosmos is a blockchain built to enable IBC (Inter-Blockchain Communication). It uses light clients and relayers to transfer not only inter-chain messages but also block headers and transaction proofs. This process can be simplified as follows:
- The user executes a transaction on the source chain to send assets to the target chain.
- Relayers monitor events on the source chain, form them into packets, and obtain the Merkle proof of the transaction from the source chain’s full node.
- Relayers then deliver this to the target chain.
- The target chain verifies if an actual transaction occurred on the source chain and if the state has changed, using the CommitmentRoot tracked by the light client of the opposite chain.
- Once verified, the target chain decodes the packet’s data and executes the transaction as requested by the user.
Through light clients existing in each chain, chains within the Cosmos ecosystem can freely conduct cross-chain communications without a third-party trust entity.
However, this method requires deploying a light client for all connected chains, which is costly. For example, running a Tendermint light client in Ethereum means verifying all ed25519 signatures of validators in the connected Cosmos chain (Ethereum does not currently support precompiled contracts for ed25519 verification). The cost of verifying one ed25519 signature in Ethereum is up to 500,000 gas, meaning for a Cosmos ecosystem chain with 100 validators, it could cost up to 500 million gas.
Additionally, chains like Bitcoin, Ethereum, or recently Aptos, which do not guarantee immediate block finality, have difficulties connecting with the Cosmos hub. This is why currently, the Cosmos hub only guarantees connections with chains built through the Tendermint SDK.
1.4.2. LayerZero
LayerZero also adopts the light client approach, verifying the block header and transaction proof of the source chain on the target chain.
How LayerZero implements this mechanism and overcomes the disadvantages of light clients will be explored in more detail in subsequent sections.
2. LayerZero Architecture and Security
LayerZero enables cross-chain messaging through the comparison of messages sent from one chain to another by entities known as Relayers and Oracles. Let’s take a detailed look at how message verification and propagation occur.
2.1 LayerZero Components
The components involved in LayerZero’s cross-chain messaging can be classified into four main categories: the core endpoints that receive, verify, and propagate messages; the Relayers and Oracles that transfer messages from one chain to another; and finally, the User Application (UA), which uses LayerZero to send and receive messages from one chain to another. Let’s examine each of these in more detail.
- Endpoints
Endpoints consist of the Communicator, which interacts directly with users to receive and deliver messages; the Validator, which verifies the validity of messages; and the UltraLightNodeV2.sol, which acts as the Network, responsible for transmitting and receiving messages to other chains. Additionally, there are Endpoint.sol libraries designed to reflect the different characteristics of each chain. - Relayer
Through the Relayer.sol contract, Relayers receive proofs of messages and deliver these proofs to other chains. As Relayers exist off-chain, the process of delivering proofs cannot be verified on-chain. - Oracle
Like Relayers, Oracles also transfer information from one chain to another. However, unlike Relayers, which deliver proof of messages, Oracles transmit the block header in which the message is included. Therefore, if multiple messages are transmitted within a single block, the block header is sent only once. Currently, LayerZero uses Chainlink’s Oracle by default, and while Chainlink’s Oracle code is not open to the public, the Oracle interface required by LayerZero is provided. - User Application (UA)
This is an application that uses LayerZero to send and receive cross-chain messages. It allows for the selection of which Relayers and Oracles to use, and the number of block confirmations to wait for before sending a cross-chain message.
// These are the default Block Confirmations waited by LayerZero before delivering messages
const defaultBlockConfs = {
[ChainId.ETHEREUM]: 15,
[ChainId.BSC]: 20,
[ChainId.AVALANCHE]: 12,
[ChainId.POLYGON]: 512,
[ChainId.ARBITRUM]: 20,
[ChainId.OPTIMISM]: 20,
[ChainId.FANTOM]: 5,
[ChainId.SWIMMER]: 20,
[ChainId.DFK]: 10,
[ChainId.HARMONY]: 5,
[ChainId.MOONBEAM]: 10,
[ChainId.APTOS]: 500000,
[ChainId.CELO]: 5,
[ChainId.DEXALOT]: 10,
[ChainId.KLAYTN]: 5,
[ChainId.METIS]: 5,
[ChainId.FUSE]: 5,
[ChainId.GNOSIS]: 5,
[ChainId.INTAIN]: 5,
}2.2 LayerZero Messaging Flow
The actual contracts, functions, and events involved in LayerZero’s cross-chain messaging are as shown in the figure above. Let’s now examine the role of each contract in the process of transmitting a message from Chain A to Chain B via off-chain relayers and oracles.
Chain A
- A user calls the _lzSend() function of the User Application (UA) through a cross-chain messaging-enabled DApp. Here, the user sets the destination chain and the message to be sent.
- The UA contract calls send() in Endpoint.sol.
3. Endpoint.sol calls send() in UltraLightNodeV2.sol.
4. UltraLightNodeV2.sol generates a Packet(encodedPayload) event.
Off-Chain
- Relayers and Oracles wait for the Packet event to occur.
- Once the Packet event is detected and after the outbound block confirmation count set by UA has passed, the Relayer calls the validateTransactionProofV2() function in RelayerV2.sol on Chain B, inputting the transaction proof and block header information as arguments.
- However, if the Oracle does not update the block header hash value in UltraLightNodeV2.sol, the Relayer does not know the block header information. Similarly, after the outbound block confirmations set by UA have passed, the Oracle calls updateHash() in UltraLightNodeV2.sol on Chain B to update the block header hash value. This triggers the HashReceived(_srcChainId, msg.sender, _lookupHash, _blockData, _confirmations) event.
4. The Relayer receives the block information from the HashReceived event and then repeats the process in step 2.
5. The validateTransactionProof() function in UltraLightNodeV2.sol is called, and if the transaction proof and block header hash match, the cross-chain message verification is completed.
Chain B
- Inside the validateTransactionProof() function of UltraLightNodeV2.sol, the receivePayload() function of Endpoint.sol is called.
- The message is stored in the storedPayload variable of Endpoint.sol.
3. UA retrieves the message from Endpoint.sol using the id of Chain A and the address of the account on Chain A that sent the message, and then presents it to the user of the application, completing the cross-chain messaging process.
2.3 LayerZero Security
Cross-chain protocols are complex systems composed of numerous components spread across different networks and execution environments. They involve various security considerations, assumptions, and trade-offs, as well as the coordination of entities with different incentive and trust models. The risks of cross-chain protocols can be assessed by dividing them into design, implementation, and operation-related aspects according to the Crosschain Risk Framework. In this article, we will examine LayerZero’s security from the design and operation perspectives.
2.3.1 Operation Risk
- Shared Security vs. Isolated Security
Shared security refers to a structure where applications running on a specific infrastructure cannot freely choose their security model and must follow all security requirements imposed by the infrastructure. For example, optimistic rollups typically undergo a 7-day Dispute Time Delay (DTD). Applications operating on such rollup infrastructure cannot simply ignore or shorten this period. While this may seem detrimental to the user experience, this duration is set for a reason. It ensures that applications using the rollup can guarantee safety to users regardless of the internal security policies of the application. In other words, applications can only strengthen the policies of the rollup; they cannot weaken them by reducing the DTD or similar actions.
Per-Application security, henceforth referred to as isolated security, is a structure where each application is responsible for its own security, independent of the constraints of the infrastructure. It might seem like a good idea because the development team of the application is best aware of what security elements are necessary for their application. However, this approach can also be seen as transferring the responsibility of assessing security policy risks from the infrastructure to the end-users. Additionally, if the application development team is free to choose the security policies of the application, they can change them at any time. Therefore, assessing the risks for each application just once is not sufficient; the risk assessment process must be repeated whenever the application’s policies change.
LayerZero allows individual User Application to set their own Relayers, Oracles, and block confirmation counts, which categorizes LayerZero under Isolated Security.
2. Valid Delivery
LayerZero assumes that cross-chain messaging is valid only in cases of Valid Delivery. Valid Delivery in LayerZero is determined by comparing transaction proofs and block headers; this outcome occurs in two scenarios.
The first scenario is where the information provided by both the Relayer and Oracle matches and is valid. The second scenario, where the information matches but is not valid, is only possible if the Relayer and Oracle collude. LayerZero’s design claims to eliminate the possibility of such collusion.
However, in reality, each UA can define its own Relayer and Oracle, contradicting this claim. LayerZero’s design does not guarantee that these components are independent and cannot collude, and ensuring this is actually the responsibility of the User Application (UA). Moreover, fundamentally, all UAs can change their Relayers, Oracles, and block confirmation period at any time, completely overturning LayerZero’s assumptions about collusion.
3. Potential Attack Methods
Let’s explore how vulnerabilities can arise in applications using LayerZero. Assume we have deployed Omnichain Fungible Token (OFT) contracts on two different chains (Chain A and Chain B) with a set destination.
In normal cross-chain messaging, if a certain amount of tokens is locked in the OFT contract on Chain A, a message is sent to the OFT contract on Chain B, resulting in the minting of an equivalent amount of tokens on Chain B. Conversely, if OFTs are burned on Chain B, a message is sent to Chain A, unlocking the equivalent OFTs.
While this appears unproblematic in normal circumstances, LayerZero’s UA can independently and changeably define which Relayer and Oracle to use, potentially leading to issues. An OFT that functioned normally a few days ago could cause problems.
As seen in the Shared Security vs. Isolated Security discussion, using the setConfig function, the owner of the OFT contract can change the Relayer and Oracle to an EOA (Externally Owned Account). After this change, if the Relayer and Oracle send a message to ULN on Chain A stating that the remaining OFT on Chain B has been burned and set the recipient of that OFT to a malicious user instead of the original owner, the OFT would be stolen.
All of this is a valid feature of LayerZero, and while users may notice changes in application settings, it’s difficult to immediately discern if the change is malicious. Theoretically, applications could be designed to prevent changes in Relayers and Oracles, but no such cases exist among already deployed applications.
In conclusion, this represents a flaw in the application itself, not in LayerZero, but it demonstrates that LayerZero cannot guarantee the security of applications implementing and operating cross-chain messaging through it. LayerZero’s security model assumes that application owners (or those who hold the private keys) will not act irrationally, but this assumption is flawed in a hostile environment. Therefore, in reality, no assumptions can be made about the security of applications built using LayerZero, and each application should be considered risky until proven otherwise.
2.3.2 Architecture Risk
All cross-chain protocols require a series of validators to prove the validity of cross-chain messages, and these protocols rely on one of two models to ensure that the validators function appropriately. The first model assumes that the reputation of the entities operating these validators and the possibility of legal action prevent misbehavior by the validators. This model is known as the Proof of Authority model. The second model is the Proof of Stake model, which includes a cryptographic guarantee where validators face financial disadvantages if they act maliciously within the protocol.
LayerZero relies on a Proof of Authority model, needing two groups of validators: Relayers and Oracles. It uses Chainlink Oracles, consisting of four well-reputed corporations. Since LayerZero operates only one entity as a Relayer, there is a perceived risk of message censorship.
The LayerZero team is aware of this risk and is developing a model that introduces a decentralized group of 11 validators based on Proof of Authority, which includes operating Relayers and Oracles. In this configuration, a cross-chain message is valid only if it receives signatures from 7 out of the 11 validators. Additionally, they are developing a product called Essence, which will simplify the implementation and operation of Relayers and Oracles. They also plan to open-source the off-chain components (Relayers, Oracles, etc.).
In Part 2, we will further explore the use cases of LayerZero and delve into its significance and limitations.
