A Comprehensive Understanding of How the Multi-Chain Interoperability Protocol LayerZero Solves the "Three Difficulties" of Cross-Chain Bridges

Author: notion

Compiled by: Moni

In September this year, the multi-chain interoperability protocol LayerZero completed a $6 million Series A financing round, co-led by Multicoin and Binance Labs, with participation from Sino Global Capital, Defiance, Delphi Digital, Robot Ventures, Spartan, Hypersphere Ventures, Protocol Ventures, Gen Block Capital, and others. The project had previously raised $2 million in seed funding.

The Future Belongs to Multi-Chain

• In the past 12 months, we have seen explosive growth in the Layer 1 space, with notable examples like Solana and Avalanche.

• Undoubtedly, as the crypto ecosystem becomes more vibrant, the current multi-chain market is becoming even stronger.

• At this stage, many applications are based on isolated single blockchains… In the near future, we may see a DEX that can communicate across chains.

• Ultimately, users can offload parts of these applications. For example, the blockchain game Axie Infinity only needs to run on one blockchain and can perform various computations on other blockchains.

What is LayerZero?

• LayerZero is a multi-chain interoperability protocol—designed to provide the purest interoperability, LayerZero's interoperability depends on the transmission of information between chains; current solutions achieve this through intermediate chains (centralized radiation model), such as Polkadot or running pairs on light nodes on-chain (like Cosmos IBC). The former solution centralizes security around a single hub, allowing cheap transactions at the cost of a single point of failure. The latter achieves high security through on-chain verification but is also capital and resource-intensive.

LayerZero combines the advantages of both solutions through a novel on-chain "Ultra Light Node," achieving the security of light nodes and the cost-effectiveness of intermediate chains, with the mission to: connect every contract on one blockchain and every contract on any other blockchain.

### Current Methods for Achieving Interoperability Between Blockchains in the Market:

1. Place your own source chain between two atomic chains and separate chains to allow communication (95%+)

• Write transactions from the source chain --> Intermediate chain reaches consensus on validity --> Write out transactions

• The target chain must implicitly trust the intermediate chain as a complete signature authority

• If the intermediate chain is compromised (like the previous attack on Poly Network), it can immediately affect the liquidity of all paired chains

• Protecting all blockchains is very difficult (due to block reorganization and security incentives)

1. Run a full light node on each chain—similar to Cosmos IBC style

• Obtain the entire block history from one blockchain --> Get the block header --> Sequentially write to another chain --> Submit transactions and verify proofs

• This method is significantly more costly because if paired with Ethereum, it involves handling tens of millions of transactions daily, not to mention pairing with all other chains.

In summary, neither of the above cross-chain interoperability solutions seems to be the optimal choice.

Creating an Ultra Light Node

This is essentially a process of isolating blocks and streaming them on demand. If you need to directly verify blocks on-chain, you need:

1. Block headers, forwarded by oracles

2. Transaction proofs, forwarded by relayers (open permissionless system)

In the first method, the large risk pool is effectively isolated and fragmented, but this approach does not perform well in terms of security because your oracles and relayer chains are the same entities, meaning you must choose the most secure oracle. However, the advantage of this method is that even if the oracle colludes with relayer A to attack, only the applications receiving messages from those specific entities are affected, while those using relayer B and other relayers, or any other oracle, are not impacted. Additionally, the protocol can be built as modular as possible so that all programming languages can be completed through multiple layers or across multiple chains.

User Application Control

• The relayer network is completely open, and anyone can run a relayer

• All user applications can specify the oracles and relayers they want, as well as the number of confirmations from the source chain

• Users should be the ones bearing the risks and liquidity

• Even if the oracle is malicious when forwarding transaction proofs, it cannot be parsed on the target chain, meaning liquidity is completely risk-free.

Cross-Chain Generic Messaging

• Now everyone is focusing on cross-chain asset transfers

• But in many cases, applications may need to share state, at which point generic messaging becomes very meaningful, such as yield aggregators needing to obtain shared data, or on-chain changes requiring rebalancing.

• Potential use cases for lending:

• Collateral on chain A --> Send message to chain B (confirm collateral) --> Directly borrow native assets on chain B

• All usual bridging, exchanging, and fees are abstracted away

• LayerZero Labs is very optimistic about future wallet integrations using this feature.

Stargate Overview

Methods for Building Cross-Chain DEX

1. There is an ETH pool on Ethereum and a SOL pool on Solana --> How to become a liquidity provider for the ETH-SOL cross-chain pool?

• Send transactions, then execute X*Y=K

• Problems and confusion arise because:

1. Most protocols do not have unilateral liquidity providers and do not encourage becoming unilateral liquidity providers

2. X*Y=K needs to be processed sequentially on the liquidity pool (executed unidirectionally on one chain)

3. You also need other trading pairs, such as ETH-AVAX, ETH-MATIC, etc., so a larger liquidity pool is required.

4. Retain existing liquidity pools but bridge assets with liquidity pools, such as USDC

• There is no need to recreate new liquidity pools, but unilateral liquidity pools + all matched paths are still needed

• If Uniswap implements this, all other DEXs will also need to implement the same liquidity transfer layer

• All of this needs to be abstracted away.

Stargate, a Very Important Composable DeFi Lego Block

• Stargate is a perfect compromise solution that allows asset transfers with 100% native assets

• Now, any DEX can use Stargate to execute swaps and bridge transactions in a single transaction on the source chain

• DEXs will not make any changes to existing protocols, and liquidity risk is zero

• Directly integrated into the user interface.

Bridging the Three Difficulties

The three difficulties mean that you can often only have one of three, or two of three.

1. Unified Liquidity

• Currently, all liquidity is matched. For example—you need a liquidity pool on chain A and a liquidity pool on chain B, plus another set for liquidity pools for A-C, A-D, A-E, etc.

• The more chains you have, the thinner the liquidity in each pool, and the less liquidity yield you obtain.

• Unified liquidity means binding a liquidity pool on chain A to all other chains simultaneously.

• When sending a transaction from chain A to chain B, if other chains send requests and deplete the liquidity pool, then you do not have enough liquidity to meet the transaction request. So, do users need to pay to restore transactions on the target chain? Will users need to pay double gas fees to get a refund when they are refunded? (This seems to be a simple attack vector issue.)

1. Real-Time Guaranteed Finality

• This means that the concept known on the source chain, where transactions will be resolved on the target chain before they are resolved on the source chain.

• Currently, cross-chain does not have unified liquidity, and the reason for this is the lack of real-time guaranteed finality.

1. Native Assets

• Most cross-chain bridges require bridging to synthetic assets minted on the target chain when locking assets on chain B, and then destroying them to unlock native assets.

• The problem with this situation is that wrapped assets seem useless, so it is necessary to deploy exchange functions and liquidity for native asset exchanges.

• Native assets have restrictions.

User Experience of Stargate

• By allowing bridging of native assets, Stargate eliminates the complex steps users must take to exchange synthetic assets on the target chain and pay additional gas fees.

• Stargate believes that over 95% of bridging transaction volumes should be completed and driven by applications, not users.

• Current market bridges focus only on independent individual bridges but are not suitable for the application layer.

• Applications must integrate a custom process (which can be completed in 15 clicks), and also need to adjust multiple wallets and different gas assets.

• Once applications like Uniswap or Sushi complete Stargate integration, users only need to click once, and (native) assets will be placed in wallets on the target chain.

Chains Supported by Stargate

• Stargate is essentially a library of on-chain smart contracts that handle verification and messaging.

• Its endpoints can exist on every chain.

• Applications only need to handle two functions - sending and receiving.

Note: "In reality, users are just sending byte payloads, i.e., a generic byte, along with a payload containing a small header for the target chain."

• EVM-first (supporting Ethereum, Avalanche, BSC, Polygon, Fantom, Arbitrum, Optimism)

• It is important to note that oracles need to support passing block headers between each path (both Chainlink & Band oracles currently support this).

• After integrating the first EVM chain, others will be easy.

• Non-EVM integration is more like a technical upgrade --> needs to "translate" proofs.

## ? LayerZero and Stargate Tokens?

Disclaimer: The following content is hypothetical

• For LayerZero, tokens will help adjust the incentives of the entire system through some leverage:

1. Oracles: Will have their own security models and structures, allowing those providing price feed information to be rewarded.

2. Relayers: Relaying messages can earn small fees or pay small fees per message.

• A large number of messages can be sent to relayers, with a small portion going to the network.

• There may be a desire for some kind of bonding system—each relayer may have an insurance fund that can allocate part of the fee income to the insurance fund.

• It would be even better if users could also bond and help protect the network and earn rewards.

1. Cross-Chain Contract Transactions: Incentivize transactions with native tokens (can provide discounts, such as trading native tokens for discounts).

• Stargate will have a more traditional structure.

• Provide liquidity release.

• Users (protocol and liquidity) will generate fees.

The Biggest Challenge Ahead for LayerZero

• From a technical perspective, LayerZero is smoother than most projects.

• LayerZero Labs co-founder and CEO Bryan Pellegrino attributes this to LayerZero's core technologist Danny Ryan being one of the world's top Solidity developers.

• Now everyone realizes that low-key BUIDL is a luxury.

• LayerZero's main challenge currently is scaling the company—every member of the project works 7 days a week, more than 18 hours a day.

• There is a need to scale up to handle the current transaction volume.