LayerZero Network

Layer Zero is an Omnichain Interoperability Protocol designed for lightweight message passing across chains. It is capable of sending a message to any contract on any chain. A simplified way of putting it is a messaging transport layer for smart contracts to communicate between chains. This opens up a world of possibilities not yet realized in current blockchain infrastructures.

They are currently live on Ethereum, Avalanche, Polygon, BNB Chain, Fantom, Arbitrum, and Optimism. In 6–8 weeks they plan to be live on Solana, Terra, Cosmos Hub, and Osmosis. And then everywhere else in 4–6 months.

HOW DOES IT WORK

Traditionally the user in order to get their tokens from say Ethereum over into Avalanche would have to go through a series of different websites/UI, swap fees, wallet networks, and bridges/DEXs/CEXs depending on how they go about it. This is very inefficient but is the current state of chain hopping.

Traditional cross-chain bridging fails in 2 broad areas, having a consensus forming middle chain validate and forward messages between chains, and running a light node on-chain. I will cover these in more detail below.

Middle Chain

Middle chains receive, validate and forward messages between chains. Hence the name “middle chain”. Middle chains are granted full signing power to all messages, making for a single point of failure.

This is worrisome because, in the event of a consensus corruption event, all liquidity can be stolen across all chains. Middle chains bond 100’s of millions while simultaneously securing tens of billions. You can see the issue here around these being insecure.

On-Chain Light Node

On-chain light nodes receive and validate the block headers for each pairwise chain on the opposing chain. Transaction proofs containing messages are forwarded and validated on-chain against those block headers. Transmitting messages this way is the most secure way of doing it however it's also the most expensive. Running a light node on Ethereum currently costs tens of millions per day per pairwise chain.

Layer Zero fixes this with what it calls Ultra LightNodes (ULN). These offer the security of a light node as stated above but with the cost-effectiveness of middle chains. This is possible because ULNs perform the same validation as an on-chain light node but instead of keeping all the block headers sequentially, they are streamed on-demand by decentralized oracles.

If you use Chainlink as your oracle any malicious action in the system is still predicated on first being able to defeat the Chainlink DON (no easy task). Even if the Oracle’s consensus is corrupted, it also requires that the Relayer is actively colluding.

LayerZero protocol also involves specific modules like the LayerZero protocol, LayerZero Endpoints, and third-party Oracles & Relayers which I will cover in more detail below.

LAYERZERO ENDPOINTS

Messages in LayerZero are sent and received by LayerZero Endpoints. Each chain in the LayerZero network has one LayerZero Endpoint which is implemented as a series of on-chain smart contracts.

These endpoints are what handle message transmission, verification, and receipt. Their purpose is to guarantee valid delivery when the user sends a message using the protocol.

Each LayerZero Endpoint is split into four modules:

Communicator

Validator

Network

Libraries

The first 3 communicator, validator, and network modules are what make up the core functionality of the Endpoint. These modules act similar to a traditional network stack. Messages are sent down the stack on the sender side (communicator), to Validator to Network and then up the stack on the recipient side.

While each new chain supported by LayerZero is added as an additional library. These libraries are auxiliary smart contracts that define how specific communication for each chain is handled. Each chain in the LayerZero network has an associated Library and each Endpoint includes a copy of every Library.

Communication between 2 chains only requires that their Libraries be present on both ends, allowing LayerZero to be a fully connected network capable of performing transactions between any pair of nodes.

THIRD-PARTY ORACLE & RELAYER

Oracle

The Oracle is a third-party service (expected to use Chainlink) that allows for reading a block header from one chain and sending it to another. It does this independent of any other LayerZero components.

Relayer

The Relayer is an off-chain service that is used to fetch the proof for a specified transaction

To ensure trustlessness and valid delivery, the only requirement for any message sent using the LayerZero protocol is that the Oracle and the Relayer must be independent of each other. This design ensures that the Oracle and the Relayer cannot collude with each other.

The flow goes like this (follow with the photo below).

User Application sends a message from chain A to chain B

Message routed through Endpoint on chain A

Endpoint notifies the User Application specified Oracle and Relayer of the message and destination chain

Oracle forwards block header to the endpoint on chain B and the Relayer submits the transaction proof

The proof is validated on the destination chain and the message is forwarded to the destination address.

LAYERZERO PROTOCOL

This photo may be extremely confusing and technical, that is ok it’s not necessary to understand what is happening. This is what happens in the backend when the LayerZero protocol executes a cross-chain transaction.

For those interested, I will list the technical breakdown steps in the drop-down below.

COMMUNICATION FLOW

Step 1:

The user application on chain A (App A) executes some series of actions as part of transaction T. We uniquely identify transaction T by the transaction identifier t—the format of this identifier may vary depending on the type of chain A. A step included in transaction T is the transmission of a message over LayerZero with valid delivery conditioned on T. For illustration purposes, and without loss of generality, we assume that in this scenario App A is using our reference Relayer. App A sends a request to the LayerZero Communicator containing the following information:

t: The unique transaction identifier for T.

dst: A global identifier pointing to a smart contract on chain B.

payload: Any data that App A wishes to send to App B.

relayer args: Arguments describing payment information in the event that App A wishes to use the reference Relayer.

Step 2:

The Communicator constructs a LayerZero packet containing dst and payload, referred to as Packet(dst, payload), and sends it, along with t and relayer args, to the Validator

Step 3:

The Validator sends t and dst to Network. This step notifies Network that the block header for the current block on chain A needs to be sent to chain B

Step 4:

Validator forwards Packet(dst, payload), t, and relayer args to the Relayer, notifying the Relayer that the transaction proof for T needs to be prefetched and eventually sent to chain B. This happens concurrently with Step 3.

Step 5:

Network sends dst and the block ID of the current transaction (cur blk id) to the Oracle. This notifies the Oracle to fetch the block header for the current block on chain A and send it to chain B. In the event that multiple LayerZero transactions occurred in the same block, Step 5 is only executed once.

Step 6:

Oracle reads the block header (blk hdr) from chain A.

Step 7:

The Relayer reads the transaction proof associated with transaction T (proof(t)) from chain A, and stores if off-chain. Steps 6 and 7 occur asynchronously to each other.

Step 8:

The Oracle confirms that the block corresponding to blk hdr is stably committed on chain A and then sends blk hdr to Network on chain B. The mechanism for determining when this happens varies per chain, but will typically involve waiting for some number of block confirmations.

Step 9:

Network sends the block hash, specified as blk hdr hash, to the Validator.

Step 10:

The Validator forwards blk hdr hash to the Relayer.

Step 11:

After receiving blk hdr hash, the Relayer sends a list of any Packet(dst, payload), t, proof(t) tuples that match the current block. In the event that multiple users simultaneously send messages between the same endpoints, there may be multiple packets and associated transaction proofs within the same block.

Step 12:

The Validator uses the received transaction proofs in conjunction with the block headers stored by Network to validate whether the associated transaction T is valid and committed. If the block header and transaction proof do not match, then the message is discarded. If they do match, then Packet(dst, payload) is sent to the Communicator.

Step 13:

The Communicator emits Packet(dst, payload) to App B.

TOKENOMICS

Currently, there is no native token for Layer Zero.

In every LayerZero transaction, the sender is expected to pay (fees):

Oracles for moving the block data.

Relayers for delivering the messages with proof.

LayerZero for developing the messaging protocol. UA can choose to pay in the native token at the source chain (e.g. ETH for Ethereum) or pay in LayerZero token (ZRO)

The fee variabilities are also handled on the app level as each transaction will require different levels of security.

INVESTORS

LayerZero lads Series A round boasts some of the biggest and most impressive names in Crypto in many different areas.

See this tweet here for a full breakdown - https://twitter.com/PrimordialAA/status/1509209102903300112?s=20&t=7k3W4vPrew5pxpdox0oqjQ

TEAM

LayerZero is co-founded by Bryan Pellegrino, CTO Ryan Zarick and Caleb Banister.