LayerZero V1 vs V2: Deep Dive into Cross-Chain Messaging and Innovations

LayerZero V1 vs V2: Deep Dive into Cross-Chain Messaging and Innovations

As blockchain ecosystems continue to grow, the need for efficient, secure, and customizable cross-chain communication has become paramount. LayerZero, a protocol designed to facilitate trustless omnichain interoperability, has evolved significantly from V1 to V2. In this article, we’ll break down the core mechanics of both versions, focusing on fee structures, protocol upgrades, and enhanced customization capabilities.


1. Application Configuration and Fee Estimation

LayerZero facilitates cross-chain messaging by allowing users to configure their application settings per destination chain. If no specific configuration is set, the protocol defaults to pre-set configurations.

Fee Estimation Process

Fees are estimated using the estimateFees function, considering the following factors:

  • Relayer Fees: Covers the cost of relaying messages to the target chain.

  • Oracle Fees: Paid to oracles for publishing receipt roots on the target chain.

  • Protocol Fees: Paid to the LayerZero treasury.

ApplicationConfiguration Struct

struct ApplicationConfiguration {
    uint16 inboundProofLibraryVersion;
    uint64 inboundBlockConfirmations;
    address relayer;
    uint16 outboundProofType;
    uint64 outboundBlockConfirmations;
    address oracle;
}

If a user hasn’t set custom configurations, LayerZero will use default settings per chain.


2. Breakdown of Fees

Relayer Fees

Relayer fees are calculated based on:

  • BaseGas: Fundamental cost of sending a message cross-chain.

  • ExtraGas: Additional gas for execution on the target chain.

  • GasPerByte: Charges based on calldata size. ⚡

  • DstNativeAmt: Any native token transferred in the message.

Relayer fees are accumulated and tracked using the nativeFees mapping:

mapping(address => uint) public nativeFees;

Oracle Fees

Oracles ensure receipt root data is published on the destination chain. The fee is determined using the default oracle or a user-specified oracle.

Protocol Fees

Protocol fees are determined based on whether the sender is paying in ZRO (LayerZero’s native token) or in native tokens.

function getFees(bool payInZro, uint relayerFee, uint oracleFee) external view returns (uint);

If native tokens are used, the protocol credits the treasury contract with the fees. For ZRO payments, tokens are transferred to the LayerZero treasury.


3. How messages are sent :

Once a cross-chain message is initiated, the following happens:

  1. The Oracle publishes the receipt root on the destination chain.

  2. The Relayer sends the calldata and proof to the UltraLightNode (ULN) contract.

  3. If any errors occur during execution, the payload is stored for retry attempts.

Block Hash and Receipt Root Updates

Oracles are responsible for updating block hashes and receipt roots.

function updateHash(uint16 _srcChainId, bytes32 _lookupHash, uint _confirmations, bytes32 _blockData);

3.1 Message Flow Overview :

At a high level, sending and receiving messages in LayerZero V2 involves several key components:

  • User Application (UA): Initiates the message.

  • UltraLightNode (ULN): The core smart contract responsible for coordinating the message flow.

  • Oracle: Verifies the transaction on the source chain and publishes proof on the destination chain.

  • Relayer: Delivers the proof and message payload to the destination chain.

  • Executor: Executes the message logic on the destination chain.

3.2 : Send a cross-Chain Message :

Step 1: User Application (UA) Initiates the Message

The process begins with the User Application (UA) calling the send function on the LayerZero endpoint. This function requires parameters such as:

  • Destination Chain ID: The target blockchain.

  • Payload: Data to be sent.

  • Adapter Parameters: Custom configuration settings for relayer and oracle behavior.

Step 2: UltraLightNode Processes the Message

The UltraLightNode (ULN) processes the message and ensures it adheres to security parameters defined in the Security Stack. The ULN generates a message hash that serves as a unique identifier for the message.

Step 3: Oracle and Relayer Are Notified

  • Oracle: Observes the source chain and generates a proof of the message.

  • Relayer: Picks up the proof and delivers it, along with the payload, to the destination chain.

At this stage, fees are distributed to the Oracle and Relayer based on pre-defined rules.

3.3 Verifying and Receiving the Message

Step 4: Oracle Publishes Receipt Root

The Oracle publishes the receipt root on the destination chain, verifying that the source chain message was legitimate.

Step 5: Relayer Delivers Proof and Payload

The Relayer sends the proof and payload to the UltraLightNode (ULN) on the destination chain. The proof ensures that the message was indeed generated and approved by the Oracle.

Step 6: Security Stack Validation

The Security Stack validates the message. In LayerZero V2, developers can customize the Security Stack to include Decentralized Verifier Networks (DVNs) or other verification mechanisms.

Step 7: Executor Processes the Payload

After validation, the Executor component executes the payload on the target User Application (UA). This execution may involve state changes, fund transfers, or triggering other smart contracts.

3.4 Handling Failures and Retries

StoredPayload for Failed Messages

If the message fails to execute for any reason (e.g., insufficient gas, contract errors), the payload is stored in the storedPayload mapping on the UltraLightNode.

Developers or off-chain services can manually trigger a retry by calling the retry function on the UltraLightNode.

Event Emission for Monitoring

Throughout the process, LayerZero emits key events, such as:

  • MessageSent: On successful initiation of a message.

  • MessageReceived: On successful execution.

  • MessageFailed: When execution fails.

These events can be monitored off-chain for analytics and troubleshooting.


4. Upgrades and Innovations in LayerZero V2

LayerZero V2 introduces groundbreaking features, addressing limitations in V1 and offering developers enhanced flexibility.

Customizable Security Stack

  • High Security: Higher cost, slower delivery.

  • Low Security: Lower cost, faster delivery. Developers can now choose the security stack that suits their application.

Ordered vs Unordered Message Delivery

In V1, all messages had to be delivered in order. V2 introduces flexibility:

  • Ordered Delivery: Ensures sequential execution.

  • Unordered Delivery: Enables simultaneous execution.

Separation of Verification and Execution

In V1, the Relayer was responsible for both verification and execution. In V2:

  • Verification: Handled by the Security Stack.

  • Execution: Managed by Executors.

This separation enhances scalability and efficiency.

Composed Messages

LayerZero V2 supports composed messages, enabling developers to send a single cross-chain message that triggers multiple actions on different contracts on the destination chain.

LayerZero V2 supports composed messages, enabling developers to send a single cross-chain message that triggers multiple actions across contracts on the destination chain.

Example of Composed Messages:

Step 1: Transfer an asset.

Step 2: Stake the asset in a DeFi protocol.

Step 3: Execute an additional action based on the result.

The Executor processes each step in sequence or concurrently, depending on the application requirements.


5. Understanding Decentralized Verifier Networks (DVNs)

Decentralized Verifier Networks (DVNs) play a pivotal role in LayerZero V2 by addressing centralization risks associated with verification. DVNs consist of multiple independent verifiers responsible for validating message proofs and ensuring message authenticity.

Core Responsibilities of DVNs:

  • Decentralized Verification: Reduces reliance on a single verifier, ensuring robustness and security.

  • Enhanced Trust Model: Messages must be validated by a quorum of verifiers before execution.

  • Scalability: The distributed nature of DVNs allows for parallel processing of multiple cross-chain messages.

Security Improvements with DVNs:

DVNs prevent malicious actors from exploiting vulnerabilities by requiring multiple nodes to validate a message. This reduces the chances of a single point of failure.

Flexibility for Developers:

LayerZero V2 allows developers to customize DVN settings based on their application's needs, balancing security, speed, and cost.

For a deeper dive into DVNs, check out the LayerZero DVN Overview.


6. Conclusion

LayerZero V2 marks a significant step forward in cross-chain communication. With enhanced configurability, separated verification and execution, and improved fee structures, it provides developers with a powerful toolkit to build next-generation omnichain applications.

Whether you prioritize cost efficiency, high security, or execution speed, LayerZero V2 offers the flexibility to tailor cross-chain messaging to your specific needs.


Further Reading: