Blockchain & Web3. LayerZero v2 Protocol Architecture. Part 2
Architecture
The basic idea and purpose of the LayerZero protocol are very simple: to deliver a message from one blockchain to another as securely and reliably as possible. The message contains a payload and routing information for this payload.
Endpoint
Everything starts with the OApp on the source network and ends with the OApp on the destination network. The main interface for the OApp is the Endpoint smart contract.
The endpoint processes incoming and outgoing messages, all messages are wrapped in packets during sending. A packet consists of a header and a body. The header includes routing information and service data; the body contains the transmitted data.
The endpoint performs the following tasks:
- Transaction Fee: The network charges the OApp for the transaction in the network's native currency or in an ERC20 token (lzToken).
- Prepare the packet for sending: Consists of several stages:
- Assign nonce and GUID: Assigns a unique number (nonce) to each message for its one-time execution and generates a GUID for tracking this message. GUID is keccak256(nonce, srcId, sender, dstId, receiver), where srcId and dstId are network identifiers (they were introduced because not all blockchains have chainId).
- Message Serialization and Packet Formation: Converts the message (payload and routing information) into a serialized packet for sending via the LayerZero protocol.
3. Send Notification: Emits a PacketSent event after sending a message.
4. Incoming Packet Check: Checks the validity of incoming packets.
5. Execution: Endpoint has a lzReceive function that ensures packets are delivered to the destination network.
6. Correct Packet Handling: Ensures the channel’s “survivability” and guarantees internal security.
Lossless Channel
One of the main tasks of the Endpoint smart contract is to ensure a reliable data transmission channel. To achieve this, two key requirements for the consistency of the message channel are set: lossless transmission and exactly-once delivery. To meet these requirements, Endpoint inherits the MessagingChannel smart contract.
Each message receives a unique sequence number (nonce). Although the system allows out-of-order delivery of messages, it guarantees that all previous messages are processed. For this, the “lazy” inbound nonce is used — the largest nonce up to which all previous messages have been processed or skipped. lazyInboundNonce starts from zero, and packets can only be executed when all packets from lazyInboundNonce to the nonce of the current packet have been verified.
For example, if packets with nonce 1 and 2 have not been verified, the packet with nonce three cannot be delivered and executed until the previous nonces are verified. After nonce 1, 2, and 3 have been verified, if nonce 2 fails to execute (e.g., due to gas or application logic issues), nonce 3 can still be executed.
Verified packets may be executed out of order, but the settings offer an option to force strict sequential execution.
Additionally, functions are available that add nonce management logic, such as skip, clear, nilify, and burn:
- In the case of erroneous or malicious messages, OApps can use the clear function to skip delivery of a specific message, or skip to skip both verification and delivery.
- The nilify function invalidates a verified packet, preventing it from being executed until a new packet is received via MessageLib. This is useful for invalidating malicious packets that may have been generated by compromised DVNs (decentralized verifiers).
- The burn function allows OApps to delete a packet without knowing its contents. This is useful if a faulty security stack has detected an invalid hash on an Endpoint or if an OApp needs to clear a previously nilified nonce.
The MessageLib smart contract plays a key role in providing external security. Each OApp must define which MessageLib it will work with. If the library is not specified in the OApp configuration, a default library (ULN) will be used. There is a registry of such libraries (MessageLib Registry), and there can be many of them, but for the interaction of two OApps, the same library must be used in both networks in a single copy.
Each MessageLib can implement arbitrary verification mechanisms as long as it conforms to the ISendLib protocol interface. This design prevents locking into a single verification mechanism, which is common in other cross-chain messaging systems.
The library’s primary goal is to ensure the secure sending and receiving of a packet. To do so, it checks for compliance with all external security requirements (which can be configured by OApp). The remaining tasks are performed by executors, which minimizes the amount of code in MessageLib and simplifies adding new features by developing new executors.
After the message is processed in MessageLib, the packet is passed back to Endpoint to create an event and notify all participants. The MessageLib on the destination network inspects the packet and logs this to Endpoint, after which the Endpoint::lzReceive() function can be called.
Library versioning and migration
Once a library is added to the MessageLib registry, no one, including the LayerZero administrator, can modify or delete it. To provide extensibility of external security while protecting existing OApps from in-place updates, the MessageLib registry is append-only and allows new libraries or versions. New libraries can be added, but existing libraries remain unchanged.
A unique ID and a version in the format major identify each MessageLib in LayerZero.minor (e.g., 1.0). A message can only be sent between two Endpoints if both use a MessageLib with the same major version.
- The major version determines the compatibility of serialization and deserialization of packages.
- The minor version is intended for bug fixes and other changes that do not break compatibility.
Each version of the LayerZero package is tied to a version of MessageLib, which helps DVNs (decentralized verifiers) determine which library to use to verify the package on the target blockchain. Libraries are numbered with three digits, where the last digit represents the Endpoint version
- First digit: The major version of the library. Such versions are incompatible with each other. If the source network has one major version and the destination network has another, they will not be able to pass a message to each other.
- Second digit: Minor version, minor versions are compatible with each other.
- Third digit: Endpoint version (for example, for LayerZero v2, it is version 2).
The current version of ULN (default library) looks like this
function version() external pure override returns (uint64 major, uint8 minor, uint8 endpointVersion) {
return (3, 0, 2);
}Migration between major versions occurs in stages to ensure security and the ability to perform asynchronous actions.
Hey, professionals, let’s connect on LinkedIn! 🤝
https://www.linkedin.com/in/dmytronasyrov
Feel free to drop a “Hi” at Pharos Production, where we bring software to life! 👋✨
Join our exciting journey with Ludo — the reputation system of the Web3 world! 🌍✨
