LayerZero — A Deep Dive
All you need to know about LayerZero
Welcome!
We recently published a 10,000-word document comparing seven of the most well-known arbitrary messaging bridges (AMBs).
To make the doc a bit more digestible, we are breaking it up into a series of “Deep Dives” on Substack, which will also include a link to a Twitter Spaces with the AMB being covered (our first was with Hyperlane).
Introduction
Today’s AMB deep dive features LayerZero! You can find an in-depth write-up below and our Twitter Spaces here.
This article will explore the design, security, and trust assumptions of LayerZero, an arbitrary messaging bridge (AMB) focused on connecting blockchains with as little additional trust as possible.
Here, we will cover the following:
LayerZero — An Overview
How It Works — Transaction Lifecycle
Security features
Trust Assumptions
Team
Community & Resources
Let’s dive in!
Overview
LayerZero is a generalized data messaging protocol that describes itself as an “omni-chain” solution. It is designed to carry lightweight messages across a bevy of chains via gas-efficient, non-upgradeable smart contracts.
LayerZero’s main selling point is a lack of extra trust assumptions when validating cross-chain transactions. Some of LayerZero’s best features include:
Simplicity — The goal for LayerZero is to put developers first. User applications building with LayerZero simply needs to implement two functions — send and receive. If it can be written in Solidity, Rust, etc., then an application can be built on-chain right now. Furthermore, as there is no middleman in the system, two high-throughput chains can interact without constraint.
Lightweight Clients — running smart contracts on Layer 1 can be extremely expensive. Therefore, LayerZero exports storage and fetching of transaction data to Oracles and Relayers, the two off-chain entities whose relationship ensures valid transactions, allowing the Ultra Light Node endpoints to be small and cost-effective. Furthermore, its lightweight clients’ low operating costs allow for the quick incorporation of new chains.
Potential — LayerZero, as its name suggests, is a ground-level piece of infrastructure that can be utilized by liquidity networks, multi-chain yield aggregators, multi-chain lending protocols, and many other dApps to build out super interesting and uniquely multi-chain crypto use cases.
LayerZero Scan — Cross-chain transactions are now tied together in a single database via LayerZero Scan, which allows users and developers to easily pull state, status, and timing of transactions.
Additionally, LayerZero is already receiving major attention and enjoys the following network effects:
Funding — The LayerZero team came out of stealth recently with a funding round led by crypto giants Multicoin Capital and Binance Labs and has since received more funding from A16z, Sequoia, and FTX as tri-leads in a $135M round, raising at a $1B valuation. LayerZero is also backed by Coinbase, Gemini, PayPal, and Uniswap, among others.
Apps building on it — Major dApps like Stargate have already built cross-chain applications on top of LayerZero. Other examples include Radiant, which is building a multi-chain lending protocol, and SushiSwap, which recently launched a cross-chain AMM. You can find the growing list of LayerZero-based dApps here.
Network connectivity — As of September 2022, LayerZero supports 11 chains: Ethereum, BNB Chain, Avalanche, Polygon, Arbitrum, Optimism, Fantom, Swimmer, DFK, Harmony, and Moonbeam.
How It Works — Transaction Lifecycle
The most basic component of LayerZero are the “Endpoints” found on supported chains. These endpoints are implemented as a series of smart contracts that allow domains to communicate with each other, with each chain having its own “Library” in the LayerZero system. Each Endpoint comes with a messaging library native to the domain the Endpoint sits on, along with a proxy, which makes sure the Endpoint uses the correct library version. Once deployed, the Endpoints are like smart contracts that cannot be shut down, allowing for an immutable flow of messages.
From there, LayerZero relies upon two off-chain entities, an Oracle and a Relayer, to pass messages between the endpoints found on different domains. In this setup, an oracle (like Chainlink) forwards a block header from domain A to domain B, while a separate relayer passes a transaction proof from domain A to domain B. If the two match and the proof is validated by the block header, then the cross-chain message is sent to the destination address.
To summarize the relationship between relayers and oracles:
The job of a LayerZero oracle is to simply relay generic data (aka block headers) from the source domain to the destination domain. It is a third-party service expected to be run via ChainLink.
The job of a relayer, which is also a third-party entity, is to fetch the proof of a specified transaction. Notably, under the parameters laid out by LayerZero, anyone can be a relayer, which helps make sure it is a decentralized system.
The only condition for Oracles and Relayers that matters is that they are run independently and do not collude. If they do not collude, LayerZero is secure. If somehow, Oracles and Relayers end up colluding, LayerZero’s security structure is majorly compromised.
A LayerZero transaction/message only requires source gas in a single call. A transaction begins with a User Application (UA) starting a transaction (aka doing something on-chain). This transaction is then broken up into multiple parts (proof and block header) via the Oracle and Relayer in a flow that is facilitated by a LayerZero Endpoint. Once the Oracle and Relayer send their respective information from the source chain and the LayerZero Endpoint validates that the information is correct, the message is translated and executed on the destination chain.
A general transaction on LayerZero would go as follows:
Let’s break that down step by step:
Step 1 — A User Application (like Stargate) uses LayerZero’s reference Relayer and executes a series of actions as part of a transaction. The User Application sends a request to LayerZero’s Communicator with information about the transaction, such as a transaction identifier, data to be transferred from A to B (payload), or identifier pointing to the User Application’s smart contract on Chain B (dst), etc.
Step 2 — The Communicator sends this data in the form of a LayerZero Packet to the Validator.
Step 3 — The Validator sends the transaction identifier and the identifier for the smart contract on Chain B to the Network. As a result, the Network gets notified that the block header from Chain A needs to be sent to Chain B.
TL;DR of Steps 1–3 — A User Application packages and transmits the data on Chain A to LayerZero’s endpoint on Chain A.
Step 4 — The Validator forwards this information to the Relayer. As a result, the Relayer is notified to prefetch the transaction proof and send it to Chain B.
Step 5 — The Network sends the identifier for the smart contract on Chain B along with the block ID of the transaction to the Oracle. As a result, the Oracle is notified to fetch the block header for the current block on Chain A and send it to Chain B.
TL;DR of Steps 4–5 — LayerZero’s Endpoints on Chain A send the transaction’s information to LayerZero’s reference Relayer, whereas the block ID of the transaction is sent to the Oracle.
Step 6 — The Oracle then obtains the block header from Chain A.
Step 7 — The Relayer receives the transaction proof from Chain A and stores it off-chain.
Summary of Steps 6–7 — The Relayer and the Oracle receive the transaction proof and block header, respectively, from Chain A.
Step 8 — The Oracle waits for a certain number of block confirmations before confirming that the block has been successfully committed on Chain A. Post confirmation, the Oracle sends the block header to the Network on Chain B.
Step 9 — The Network sends the block hash to the Validator.
Step 10 — The Validator forwards the block hash to the Relayer.
Step 11 — The Relayer sends a list of any data structures that match the current block.
Step 12 — The Validator ensures that the transaction is valid and committed by going through the transaction proof and the block headers stored by the Network. If the block header and transaction proof match, the transaction information is sent to the communicator in the form of a Packet.
Step 13 — The Communicator emits the information (Packet) to the User Application on Chain B.
Summary of Steps 9–13 — LayerZero’s Endpoint on Chain B obtains the information initiated by the User Application on Chain A using the block header and emits it to the User Application on Chain B.
This way, the User Application uses LayerZero to send transaction information (like tokens) from Chain A to Chain B.
Security
LayerZero Offers the following security features:
Valid delivery — The Independence of the Oracle and Relayer is the basis for LayerZero’s security. If a block header and transaction proof provided by two independent entities match, then the delivery of a transaction is valid. If they do not match, then it is not valid. This is a highly secure mechanism, as the statistical probability of a transaction proof and blockhead matching without knowledge of the other beforehand is low.
High cost of attack — In the worst-case scenario, an Oracle and Relayer could be run by the same entity and collude maliciously — meaning that a block header and a transaction proof provided by an Oracle and Relayer are invalid, yet still match due to collusion overriding the system. However, this is a siloed risk even if Oracle 1 and Relayer A collude maliciously, as only the applications using Oracle 1 as the oracle and Relayer A for information will be affected. All the other oracles and relayers continue to operate as usual. Therefore, the cost of the attack becomes very high for little reward as you can only attack a specific pool of funds and not the entire funds in the system. This is a small risk, however, because if a User Application has a specific risk profile and doesn’t trust either the Oracle or Relayer of a particular configuration they can opt to run one part of this themselves to eliminate any possibility of collusion.
Simple and effective design — As LayerZero does not add any extra bells and whistles to its bridging mechanism via a token, lock and mint mechanisms, etc., the security of LayerZero can be traced down to the chains wherein its Endpoints reside.
Risk sharding — LayerZero allows user applications to choose different Oracle/Relayer combinations to spread out the risk of someone attempting to make two independent entities collude via bribing or malicious attack.
Risk shielding — Users can run their own relayers — meaning that for a user to trustlessly depend on LayerZero, then all they need to do is run their own relayer and trust that the Oracle is independent of themselves.
Pre-Crime — This feature allows a relayer to stop a hack before it happens. Relayers can fork a destination blockchain before the delivery of a message and run a transaction locally, allowing the relayer to verify that no malicious action (defined by each User Application) occurred. This acts as an additional layer of security on top of audits and bug bounties for dApps.
Audits — LayerZero has gone through 20+ formal audits including Quantstamp, Zokyo, Zellic, and Trail of Bits, according to the team. Furthermore, LayerZero currently hosts a $15 million bug bounty via ImmuneFi and has already shown a propensity for rewarding whitehats, as evidenced here and here.
Trust Assumptions
LayerZero makes the following trust assumptions:
Progressive decentralization — The number of relayers on the network will grow, progressively decentralizing the messaging system’s most important security mechanism.
Dependence on Relayer and Oracle — LayerZero users are dependent on the security of the Relayer and the Oracle to pass messages across chains. There is not really anything on-chain related to the ownership of the funds and data themselves.
Operational risks — LayerZero relies on third parties (oracles and relayers) for its functioning, which adds operational risks beyond LayerZero’s control.
Reliance on chains’ security — LayerZero does not add an intermediary to cross-chain transactions, however, it does rely on the native chain of an Endpoint to function correctly. If a chain was to be 51% attacked, it is unclear how LayerZero would be able to handle such an event.
Community & Resources
You can learn more about LayerZero and stay updated about its community through the following:
Closing Thoughts
LayerZero hopes to provide secure infrastructure to enable developers to start building cross-chain dApps with as little friction as possible in a safe manner. We are super excited by what LayerZero is building and can’t wait to see what the AMB structure unlocks for the crypto space.
And, of course, LI.FI is thankful for all the feedback and cooperation from the LayerZero team for the doc/Twitter spaces.
There is a whole ecosystem of AMBs, enabling complex cross-chain functionality for dApps. If you’re interested in learning more about the different types of AMBs, check out LI.FI’s comparison framework, which enables readers to quickly assess the pros and cons of an AMB.
Get Started with LI.FI Today
Enjoyed reading our research? Please clap for the blog and show us your support! To learn more about us:
Head to our link portal at links.li.fi
Read our SDK ‘quick start’ at docs.li.fi
Join the official Discord server
Subscribe to our newsletter on Substack
Follow our Telegram Newsletter
or try our any-2-any swaps NOW at transferto.xyz