Partnered With:

LayerZero CEO: Understand LayerZero from first principles

Read this article in 8 Minutes

LayerZero allows applications to set a set of security parameters that can never be modified, something that cross-chain protocols like Wormhole and Nomad don't have.

LayerZero CEO: Understanding LayerZero from First Principles

Bryan Pellegrino is co-founder and CEO of LayerZero Labs

aididiaojp.eth, Foresight News

There was a lot of discussion about LayerZero on Twitter yesterday, including a lot of misconceptions, so I'm going to start with first principles about LayerZero. What is it? How does it work? How can developers keep it secure?

What is LayerZero?

LayerZero is an interoperability protocol that can be used for messaging, allowing any call across a chain contract that contains a payload.

How does it work?

Developers deploy contracts on multiple chains, which we collectively call chains A and B. The transaction is submitted on chain A, and the message containing the result can be delivered to the contract on chain B. The contract interacts with the LayerZero endpoint, and the application-selected predictor and repeater retrieve the appropriate block header and tx proof. They wait for confirmation from A specified number of blocks on chain A and independently transmit their information to chain B. On chain B, this information is validated by a verifier or proof library, and then a message contract is passed on chain B.

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

What guarantees do infrastructure providers have?

There are four real components: repeater, predictor, verifier, proof library, block validation

The application has complete control over each of these components, as described below:

Repeaters - Repeaters are fully open and require no permission. The application can select any existing repeater, which can be a network of Repeaters or simply a single signer.

Seer - Seer is also fully open and permissionless. The application can select any existing seer, which can be a network of seers or a single signer.

Proof Library - Verification libraries are published in a registry that can only be appended, new libraries can also be published, but existing libraries can never be modified, and are completely irrevocable and immutable. The application can select any existing library (which all have public auditing) to perform its validation. With the invention of new proof mechanisms, advances in areas such as zero-knowledge proof, and the emergence of optimized protocols around Gas and adoption rates, the registry allows for unlimited flexibility.

Block acknowledgment - Block acknowledgment is the number of blocks that must be completed on the current source chain before the message can be delivered to the target chain. This number, which varies widely between consensus mechanisms and systems with probabilistic finality, is the way an application controls the final certainty of a given block, much like what a centralized trading platform does before accepting deposits from a given chain.

If the application configured these parameters, it would look like this

If the application is not configured with parameters, then it uses the "default" setting, which has certain adaptability and functional limitations.

In scenario A, when the configuration of [ULN v2, Relayer A, Oracle Z, Block Confs X, and Proof Lib V1] is set by the application, these parameters cannot be modified by any other system. At this point, repeater A will be used with Predictor Z, and all messages will be verified by ULN v2 and Proof Lib v1 after waiting for X blocks.

In scenario B, when the application uses the default Settings, it means that they give the choice of parameters to LayerZero for multi-signing. The only thing LayerZero multiple signers can do is add new libraries and change default values.

So, let's talk about the current situation.

Most interoperable systems today work like this:

Wormhole, Nomad and other interoperable systems work in a similar way. All controls reside in [systems] and can be upgraded by the administrator who controls those systems (Wormhole requires a 13/19 multiple signature from the validator). This is risky, resulting in multiple security issues for Wormhole and Nomad. With LayerZero, the default is the same as for these systems, where the application delegates control of the parameters to a set of external administrative keys, and the system relies on the secret key manager to do no evil.

The difference is that in none of these systems does the application have any control and can never be prevented from [the system] forcing them to upgrade and change the trust assumptions of the underlying messaging or protocol.

LayerZero provides a way for each application to explicitly select 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.