Original compilation: aididiaojp.eth, Foresight News
Original compilation: aididiaojp.eth, Foresight News
What is Layer Zero?
What is Layer Zero?
LayerZero is an interoperability protocol for messaging that allows any cross-chain contract call that includes a payload.
How does it work?
Developers deploy contracts on multiple chains, we collectively refer to these as Chain A and Chain B. A transaction is committed on chain A, and a message containing the result can be delivered to a contract on chain B. The contract interacts with the LayerZero endpoint, and the oracles and relayers chosen by the application retrieve the corresponding block headers and tx proofs. They wait for a specified number of blocks to be confirmed on chain A, and then independently transmit their information to chain B. On chain B, the information will be verified by a verifier or a proof library, and then the message contract will be transmitted on chain B.
A simple example is that users can bridge on Stargate, exchange using SushiXSwap, or trade NFT assets across chains.
What guarantees does the infrastructure provider have?
There are four real components here: relayer, oracle, validator\proof library, block confirmation
Applications have full control over each of these components, as detailed below:
Relays - Relays are completely open and permissionless. Applications can choose any existing relayer, which can be a network of relayers or a simple single signer.
Oracles - Oracles are also completely open and permissionless. Applications can choose any existing oracle, which can be a network of oracles or a single signer.
Proof Repositories - Verification repositories are published in an append-only registry, new repositories can also be published, but existing repositories can never be modified and are fully irrevocable immutable verification repositories. Applications can choose any existing library (they all have public audits) to perform their verification. With the invention of new proof mechanisms, advancements in areas such as zero-knowledge proofs, and optimized protocols around gas and adoption rates, registries allow for unlimited flexibility.
Block Confirmations - Block confirmations are the number of blocks that must be completed on the current source chain before a message can be delivered to the target chain. This number varies widely between consensus mechanisms and systems with probabilistic finality, and is how applications control the finality of a given block, much like what centralized exchanges do before accepting deposits from a given chain .
If the application configures these parameters it will look like this
If the application does not configure parameters, it will use the default settings, which will have some 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, relayer A will work with oracle Z, and all messages will be verified by ULN v2 and Proof Lib v1 after waiting X blocks.
In Scenario B, when applications use the default settings, it means they hand over the choice of parameters to LayerZero multisig. The only thing LayerZero multisig can do is add new libraries and change defaults.
So, lets discuss the status quo that currently exists.
Most interoperating systems today work like this:
Interoperable systems like Wormhole and Nomad all work in a similar fashion. All controls reside in [systems] and can be upgraded by administrators controlling those systems (Wormhole requires 13/19 multisig for validators). This is risky and has resulted in multiple security issues with Wormhole and Nomad. With LayerZero the default is the same as for these systems, the application delegates parameter control to a set of externally managed keys, and the system relies on the key manager not to do evil.
The difference is that in none of these systems does the application have any control and can never prevent [the system] from forcing an upgrade on them and changing the trust assumptions of the underlying messaging or protocols.
Original link
