LayerZero CEO: Understanding LayerZero from First Principles

Written by: Bryan Pellegrino, Co-founder and CEO of LayerZero Labs

Compiled by: aididiaojp.eth, Foresight News

Yesterday, there was a lot of discussion about LayerZero on Twitter, including many misunderstandings. So, I will start from first principles to introduce LayerZero: What is it? How does it work? How do developers ensure its security?

What is LayerZero?

LayerZero is an interoperability protocol for messaging that allows cross-chain contracts to be called with a payload.

How does it work?

Developers deploy contracts on multiple chains, which we refer to as Chain A and Chain B. Transactions are submitted on Chain A, and messages containing results can be passed to contracts on Chain B. The contracts interact with LayerZero endpoints, and then the oracle and relayer chosen by the application retrieve the corresponding block headers and transaction proofs. They independently send their respective information to Chain B after waiting for a specified number of block confirmations on Chain A. On Chain B, this information will be validated through validators or proof libraries, and then the message will be sent to the message contract on Chain B.

A simple example is that users can bridge on Stargate, swap using SushiXSwap, or trade NFT assets across chains.

What guarantees do infrastructure providers offer?

There are four real components here: relayers, oracles, validators/proof libraries, and block confirmations.

Applications can have complete control over each of these components, and here are the details:

Relayers ------ Relayers are completely open and permissionless. Applications can choose any existing relayer, which can be a relayer network or a simple single signer.

Oracles ------ Oracles are also completely open and permissionless. Applications can choose any existing oracle, which can be an oracle network or a single signer.

Proof Libraries ------ The validation libraries are published in an append-only registry, and new libraries can be published, but existing libraries can never be modified and are completely irrevocable immutable validation libraries. Applications can choose any existing library (all of which have public audits) to perform their validation. With the invention of new proof mechanisms, advancements in areas like zero-knowledge proofs, and the emergence of optimized protocols around gas and adoption rates, the registry allows for unlimited flexibility.

Block Confirmations - Block confirmations are the number of blocks that must be completed on the current source chain before messages can be passed to the target chain. This number varies greatly in consensus mechanisms and systems with probabilistic finality, and it is the way applications control the finality of a given block, similar to what centralized exchanges do before accepting deposits from a given chain.

If applications configure these parameters, it will look like this:

If applications do not configure the parameters, they will use the "default" settings, which will impose certain adaptability and functionality limitations.

In Scenario A, when the application sets the configuration of [ULN v2, Relayer A, Oracle Z, Block Confs X, and Proof Lib V1], no other system can modify these parameters. At this point, Relayer A will be used with Oracle Z, and all messages will be validated through ULN v2 and Proof Lib V1 after waiting for X blocks.

In Scenario B, when the application uses the default settings, it means they have delegated the choice of parameters to the LayerZero multisig. The only thing the LayerZero multisig can do is add new libraries and change the defaults.

Now, let’s discuss the current state of affairs.

Today, most interoperability systems work like this:

Interoperability systems like Wormhole and Nomad operate in a similar manner. All controls are located within [the system] and can be upgraded by the administrators controlling these systems (Wormhole requires a 13/19 multisig from validators). This poses certain risks, leading to multiple security issues with Wormhole and Nomad. Using LayerZero's defaults is similar to these systems, where applications delegate control of parameters to a set of external management keys, relying on key managers not to act maliciously.

The difference is that in these systems, applications have no control and can never prevent [the system] from enforcing upgrades and changing the underlying messaging or protocol trust assumptions.

LayerZero provides a way for each application to explicitly choose a set of security parameters that can never be modified. We believe that critical infrastructure should be immutable, open-source, and always owned by user applications.