Sino Global Capital: A Detailed Explanation of LayerZero's Main Features and Advantages
LayerZero's core is an omnichain interoperability protocol. It can be seen as a key infrastructure layer that connects any given contract on each given chain.Author: Sino Global Capital
Original Title: 《Why we invested in LayerZero Labs》
Compiled by: Linqi, Chain Catcher
A Multi-Chain, Multi-Layer Future
In the past few years, the adoption of blockchain technology has been steadily increasing. The search volume for the keyword "Ethereum" on Google peaked in May 2021, coinciding with a record daily transaction volume of 1.65 million on the Ethereum network. At the same time, as network participants on Ethereum competed for limited block space, the average fee for each transaction on Ethereum skyrocketed to nearly $70. This is because, in its current state, Ethereum can only support 15-45 transactions per second, with users incentivizing miners to prioritize their transactions by paying higher fees. This has made it prohibitively expensive for the vast majority of retail users to pay such high fees just to process a single transaction.
Source: Blockchain Encryption
Source: Coin Metrics
Unsurprisingly, this has paved the way for various L1 blockchains and L2 scaling solutions to serve this vast market composed of edge retail investors and use cases. Since the beginning of 2021, Ethereum's dominance (in terms of TVL) has dropped from 90% to 65%. The popularity of Binance Smart Chain (BSC) in April 2021, which supports low-cost transactions for users at about $1-2 per transaction (albeit at the cost of decentralization), has contributed to this shift.
Since then, multiple L1 and L2 solutions have emerged, each vying for a piece of the pie, often offering generous incentive programs to users bridging their assets through liquidity mining or airdrops.
Source: DeFi Llama
Each of these L1 or L2 projects seeks to contribute its own advantages, primarily by ensuring lower transaction fees, higher TPS, or a more user-friendly experience for retail users. They may also aim to accommodate different use cases, supporting protocols that exist on their own parachains or promising to provide high-fidelity data or high-performance blockchains to compete with existing real-world enterprises like Visa that handle over 15,000 TPS. Currently, the potential for a multi-chain, multi-layer future seems quite significant. Ethereum is likely to maintain its "king of the hill" dominance, becoming the most battle-tested public chain and addressing scalability issues through Ethereum 2.0. Meanwhile, platforms like Polygon, Solana, and Polkadot have gained significant attention in the developer community and are likely to coexist based on their respective use cases.
Additionally, protocols have begun to modularize different aspects of their applications across various blockchains. For example, a game may require a very high TPS blockchain to support in-game actions while utilizing a high-security, low-throughput blockchain to trade valuable in-game assets.
Cross-Chain Architecture and Cross-Chain Bridge Introduction
This vision of a multi-chain, multi-layer future introduces a demand for cross-chain infrastructure to bridge the gaps between various blockchains and cross-scaling solutions. Consequently, a series of unique problems arise that hinder or undermine the core goals of decentralized public chains.
Current Issues
1. Centralization
Using Centralized Exchanges as Asset Cross-Chain Bridges
When users bridge assets from one chain to another, they often use centralized exchanges (CEX) as intermediaries to bridge assets to their target chains. While this may seem like a convenient method for some users, it essentially trades convenience for potentially higher costs:
- Lack of privacy and anonymity—CEX requires KYC, which may not meet the needs of many users who wish to protect their privacy.
- Regulatory risks—CEX has repeatedly blocked users from accessing certain jurisdictions or prohibited withdrawals/trading of certain assets for regulatory reasons.
- Counterparty risk—users must trust CEX to custody their assets.
Using Non-Decentralized Cross-Chain Bridges
Currently, there are multiple bridges available for users to choose from when bridging their assets. Some of these options utilize a not fully decentralized intermediate consensus layer. This may be due to a small number of permissioned validators or the cross-chain bridge being protected by multi-signature. This is very insecure because the target chain implicitly trusts the intermediate chain, which has full signing authority over the target chain. This means that any hack on the intermediate chain could potentially drain all liquidity locked in the target chain's pool. Additionally, the use of an intermediate consensus layer may be an unnecessary resource or cost-intensive, as it adds redundant overhead.
2. Lack of Composability
Use of Synthetic Intermediate Tokens
Some cross-chain bridges use intermediate tokens to address the issue of fragmented liquidity or achieve decentralization. This intermediate token adds unnecessary overhead and complexity, especially when users end up receiving intermediate tokens due to errors or insufficient liquidity on the target chain. This not only leads to a poor user experience but may also leave users with a non-composable useless token, as few protocols will accept abcUSD. Users must wait for liquidity in the abcUSD-USD pool to be replenished before they can proceed with their operations.
The additional inefficiency here is the liquidity locked in the abcUSD-USD pool, which would have been entirely unnecessary if native tokens were used from the start. Furthermore, many bridge providers will offer a liquidity pool for each chain they support, effectively repeating the same inefficient liquidity demand on every additional chain.
Limited Composability
Currently, when protocols consider which protocol to build on or integrate with, they often limit their scope to other dapps built on the same blockchain or within the same ecosystem. However, if protocols could compose with the entire world of decentralized applications and smart contracts across all blockchains, there would be no reason to limit themselves to a single ecosystem. Yet, if protocols can compose with decentralized applications and smart contracts across all blockchains, they have no reason to restrict themselves to a single ecosystem.
3. Inefficient and High Costs
Use of On-Chain Nodes
The solution to overcome the aforementioned points 1 and 2 is to use on-chain nodes that sequentially receive and verify each block header from the source chain to the target chain and validate against each forwarded transaction proof. However, this approach is not feasible for most blockchains, as running such a system requires substantial computational resources and costs.
Inefficient Current User Flow
Currently, when users consider using different protocols across different blockchains, they must undergo a cumbersome process for each new chain they transfer assets to, including token approvals, transfers, and bridging transactions. This process may involve numerous different token addresses, web applications, and bridges, making each node prone to errors. For new users, the inefficient user flow can be costly and extremely confusing.
As we gradually understand some of the current issues with cross-chain architecture, we will reveal LayerZero and how it addresses these existing problems.
LayerZero Labs
At the core of LayerZero is an omnichain interoperability protocol. It can be seen as a key infrastructure layer that connects any given contract on each given chain. It is a critical messaging primitive that brings a new dimension of cross-chain composability and functionality.
Solution
First, we must delve into the design that enables LayerZero to achieve this.
To verify blocks on-chain, we need two pieces of information:
- Block header, which contains the receipt root
- Transaction proof, which is the Merkel-Patricia proof on the EVM
LayerZero separates these two components in the following way:
- An oracle forwards the block header, with any chosen oracle (e.g., Chainlink, Pyth)
- A relayer forwards the transaction proof
Both oracles and relayers are 100% open and permissionless, allowing anyone to act in either role.
Assuming these two entities are independent, and the combination of the block header and its corresponding transaction proof is verified on the target chain, it can be guaranteed that the forwarded message is valid and has been submitted on the source chain.
We must note two important security properties here. First, the worst-case security of the system is equivalent to the security of the chosen oracle. This scenario occurs when the oracle and the relayer are the same entity, in which case we inherit the foundational security of the oracle, such as the consensus mechanism established by Chainlink's decentralized oracle network. Second, protocols can choose or even run their own relayers to obtain proofs for given transactions. This means that the protocol itself can ensure that the oracle and the relayer are independent entities.
This outlines a design for trustless effective delivery, requiring no potential centralized intermediary entities or tokens.
Power of the Protocol
Another core feature of LayerZero is that applications themselves can fully control all security parameters. Each protocol can accurately specify which oracle and relayer they wish to use. This implementation will also be modular enough that protocols can choose an oracle that aggregates optimal prices from several queries or even leverage a two-thirds consensus from multiple oracles. Additionally, protocols can specify the number of confirmations they need to obtain from the source chain.
Key Advantages of LayerZero
Isolated Risk Infrastructure
Existing cross-chain infrastructure relies on specific entities to verify transactions or transmit messages across chains. In recent exploits, a common failure point has been compromised or malicious relayers. Some cross-chain designs implicitly trust any message from the relayer network as valid. Attackers can exploit this vulnerability to drain entire liquidity pools, leading to catastrophic financial losses. This poses a significant "systemic risk" to the entire ecosystem, as any protocol that brings additional liquidity will increase capital risks for any potential consensus failures or exploits.
In LayerZero's design, the permissionless use of oracles and relayers empowers protocols to independently choose them, providing the advantage of isolating the risks borne by the protocols and their users. Since attacks must be jointly executed by specific oracles and specific relayers, any other protocol without the exact same oracle-relayer pair will not be affected. This effectively segments the risks borne in any ecosystem into a narrowband of "application-specific risks." This is a significant advancement in security, as any black-hat hacker can only attack a small portion of vulnerable liquidity, while the rest of the honeypot remains secure. This design greatly increases the cost of any given attack while reducing the profit from theft.
LayerZero Efficiency
As mentioned above, cross-chain designs with intermediate chain layers typically come with additional computation, consensus, and/or intermediate tokens. These are both inefficient and unnecessary, increasing security issues and throughput limitations. LayerZero aims to add as little additional complexity as possible while still maintaining the security of trust-minimized communication.
In the simplicity of LayerZero's design, neither the relayer nor the oracle forms any consensus or verification; they simply transmit messages. Since all verification is done on their respective source and target chains, speed and throughput limitations are entirely dependent on the properties of the two transaction chains.
True Cross-Chain Composability (Not Just Asset Transfers)
Most cross-chain implementations primarily focus on supporting asset bridging. This is understandable, as bridging tokens can be considered the most common use case. However, there are many possibilities that can be unlocked through cross-chain messaging.
LayerZero is a universal messaging primitive, meaning any application can connect any contract on blockchain A to any other contract on blockchain B. This opens up a whole new design space for developers, extending their vision of composability and compatibility beyond any other native blockchain. Below, we will expand on two examples that fundamentally change the composability experience for users and protocols.
User Perspective: Multi-Chain Money Market Aggregation
Currently, when users deposit collateral to borrow assets, they are limited to the blockchain where their assets reside. If applications on any other chain offer better interest rates, or if they want to deposit borrowed assets into a liquidity pool on another chain, they must use an asset cross-chain bridge and pay several transaction fees in the process.
With LayerZero, users deposit their collateral into the application they want on chain A. A message is sent to chain B, verifying that the collateral is in order, allowing users to simply borrow native assets on chain B and deposit those tokens into a farm on chain B. After completing yield farming, users can repay the borrowed assets on chain B and unlock their collateral on chain A. The user experience is simple and intuitive, with all complexities related to multiple swaps, bridges, and intermediate tokens abstracted away.
Protocol Perspective: Cross-Chain Governance
We have seen multiple blue-chip DeFi applications deployed across multiple chains. This raises an interesting question for governance. With users and token holders of the protocol dispersed across up to 9-10 different chains, governance can become very cumbersome. Should the protocol host governance on the largest chain? Or should there be separate proposals or votes for each chain? Or perhaps off-chain governance?
LayerZero supports unified governance, allowing users and token holders on each chain to vote locally from any chain they are on through simple messaging.
First Application: Stargate (Asset Cross-Chain Bridge)
With the official launch of LayerZero's mainnet, it has already built its first application, Stargate. It will leverage LayerZero's cross-chain architecture to showcase the new design space it opens up.
Currently, each DEX/AMM has multiple copies of the same paired liquidity pools on every new chain they deploy to. If we multiply this by the number of different AMMs on each chain, we end up with a very inefficient and fragmented system.
Stargate is the true composable asset cross-chain bridge that addresses this issue. It has three main features:
- Native Assets: This means no synthetic/intermediate tokens are needed; Stargate will only provide the native tokens users want. This eliminates intermediate tokens and unnecessary transactions.
- Unified Liquidity: There will be a single liquidity pool shared across all available chains. These will also be single-sided pools without impermanent loss. This greatly improves the capital efficiency of all locked liquidity.
- Instant Guaranteed Finality: Applications on the target chain can be certain that submitted transactions will resolve on the source chain. This overcomes the critical issue of transaction reversals due to a lack of liquidity on the target chain.
Implementing any cross-chain integration can be very time-consuming and technically complex. Moreover, the biggest risk for any application is that fraudulent cross-chain messages could drain all their liquidity. These obstacles have hindered many protocols from achieving any cross-chain integration. LayerZero addresses these issues by simplifying integration, requiring no changes to existing protocols and posing no risk to the liquidity pools of the protocols themselves. All risks are entirely borne by Stargate.
Conclusion
In summary, as we steadily move towards a multi-chain, multi-layer world, we believe that LayerZero's cross-chain architecture will become a core component, serving as the key infrastructure layer driving a truly permissionless and trustless omnichain future.
