LayerZero from First Principles
There was a lot of discussion yesterday and a lot of misconceptions so I’m going to walk through LayerZero from first principles. What it is, how it works, what guarantees developers have and the best practices for security.
What is it?
LayerZero is a messaging protocol allowing arbitrary contract invocation across chains with an included payload.
How does it work?
A developer deploys a contract on multiple chains, let’s call these Chain A and Chain B. A transaction is committed on Chain A which constructs a resulting message to be passed to the contract on Chain B. The contract interacts with LayerZero Endpoint and then a few things happen — The application’s selected oracle and relayer retrieve the corresponding block header and tx proof. They wait for the application-specified number of block confirmations on the source chain, and then each delivers their piece independently to Chain B. On Chain B these pieces are validated via a Validation/Proof Library, followed by delivering the message contract on Chain B.
A simple example of this in production might be bridging on Stargate, a swap using SushiXSwap, or moving your Lil Pudgy across chains.
What guarantees do developers have?
Well, there are four real components here: Relayer, Oracle, Validation/Proof Library, Block Confirmations
The application can have complete control over each of these components. I’ll walk through what those controls look like below:
Relayer — Relayers are completely open and permissionless. The application may select any existing Relayer, including the ability to operate their own and select themselves. Relayers can be a network of relayers or as simple as a single signer.
Oracles — Oracles are completely open and permissionless. The application may select any existing Oracle, including the ability to operate its own and select itself. Oracles can be a network of oracles or as simple as a single signer.
Validation/Proof library — Libraries are published in an append-only registry, new libraries can be published but existing libraries can never be modified and are completely and irrevocably immutable. The application may select any existing library (which all have public audits) to perform its validation. An append-only registry allows for unlimited flexibility as new proofing mechanisms are invented, advances in fields such as zero-knowledge proofs emerge, and general optimizations around gas and utilization are made.
Block Confirmations — Block confirmations are the number of blocks that must be completed on the current source chain before a message can be passed to the destination chain. This number varies widely across consensus mechanisms and in systems with probabilistic finality are ways for applications to control the finality of a given block — much like centralized exchanges do before accepting deposits from a given chain.
If an application configures these parameters it will look like this
If an application does not setup its configuration then it uses the ‘Default’ settings which basically is just a pointer to some pointer.
In Scenario A, when an application has set its config of [ULN v2, Relayer A, Oracle Z, Block Confs X and Proof Lib V1]] there is nothing any other system in the world can do to modify these selections. At this point, Relayer A will be used with Oracle Z, all messages will be validated through ULN v2 and Proof Lib v1 after waiting for X block confs.
In scenario B when an application is using the default settings, it means that they are ceding control of the selection of these items to the LayerZero multisig. The only things that the LayerZero multisig can do is to add new libraries and change the defaults. Selecting this means that the application is delegating trust to the LayerZero multisig in selecting these items and not acting maliciously.
So, let’s discuss what the current state of the world is and what can and can’t be done.
Most generic messaging systems today work something like this
Messaging systems such as Wormhole, Nomad, etc. all work in a similar manner. All of the control sits in the [system] and can be upgraded by whoever controls the admin keys for those systems (In Wormhole’s case this is the 13/19 multisig of validators). This has previously been extremely problematic resulting in multiple issues for Wormhole and Nomad and is generally seen as unsafe practice for applications. Using LayerZero’s defaults is exactly equivalent to these systems, the application is delegating control of parameters to an external set of admin keys and relying on those parties to not act maliciously.
The difference is with each of those systems an application does not have any control and cannot ever prevent the [system] from forcing these upgrades on them and changing the underlying messaging behavior or the trust assumptions for the protocols.
LayerZero gives each application a way to explicitly choose a concrete set of security parameters that can never be modified or changed on them. We believe critical infrastructure should be immutable, open source, and always owned by user applications.