This article is the article “What’s wrong with bridges? Perils, Present and Future of Cross-Chain Communication: the road after Layer Zero” published by The Anti-Ape in substack. The article compares centralized exchanges, asset bridges, The cost, security and efficiency of mainstream bridge designs such as Omnichain DEX and cross-chain communication protocols IBC and Layer Zero.
There is no clear winner in the cross-chain design space. We hope to see further iterations after IBC/Layer Zero.
This article compares the cost, safety, and efficiency of all mainstream bridge designs:
- Ironically, centralized exchanges (CEXs) are still the best option.
- Asset bridges have the fatal flaw of non-native packaging.
- A full-chain (Omnichain) DEX involves interchain liquidity locking, which means more attacks and higher fees to compensate nodes and LPs.
(from asset transfer to generalized communication)
- IBC is a general protocol with no assumption of external trust. IBC is safe and efficient. The only downside is the high cost of deployment.
- Layer Zero is a variant of IBC that turns deployment costs into pay-per-use variable costs with the help of Chainlink.L0 is optimized for uncommon use cases, but is less scalable in high frequency communications.
Given the painful tradeoffs, we believe that design iterations are bound to continue. In Section 4, we will present three ideas:
- CLOBs: Make cross-chain liquidity pools more capital efficient
- zk-SNARKs: Reducing on-chain verification costs
- Chain-level SDK integration: Eliminate reliance on centralized external “repeaters”
Projects mentioned in the article: Ethereum 2.0, Cosmos, IBC, Layer Zero, Solana, Serum, Optimistic Roll-ups, StarkNet, Terra, THORChain, Osmosis, Anyswap, Wormhole, Ronin Bridge, Terra Bridge, Avalanche Bridge, Ren Bridge, Axie Infinity
Section 1: Status Quo of Cross-chain Communication
In this section:
- The multi-chain reality is here to stay
- The value and use cases of cross-chain infrastructure
- The love-hate relationship between cross-chain and L1 war
- Value capture for cross-chain protocols: why it is (and should be) rare
In the short to medium term, we will have more public chains, not less:
- Technology is iterating: The final technological solution for scalability is not yet mature. The scalability design choice iteration is bound to continue.
- Capital is looting: The sheer amount of money behind top ecosystems means that looting won’t end anytime soon.
- Protocols want to issue L1 tokens: In fact, the attractive economics of issuing Layer 1 tokens means that successful application layer protocols have an incentive to roll out use case chains (eg: Axie Infinity and Ronin).
Cross-chain interoperability is a structurally important design space:
- Currency Interoperability: For users, currency is currency. Unconnected currency is just store credits. Creating interoperability increases asset value.
- Data Interoperability: Facebook and Google have become the most valuable businesses in the world, and they can derive value from otherwise unconnected data. Similar data is now wasted in siloed blockchain databases.
Use Cases: Credentials, Credit Scores, Metaverse Identity, Protocols That Reward Users for Actions on Another Chain
For those interested in the L1 battle, cross-chain communication also has a deep connection to blockchain scalability:
- Competitiveness: If cross-chain communication becomes smooth enough, it may abstract L1 away. After all, as long as Facebook’s servers allow us to talk to our friends without borders, who cares? On the margins, a smoother cross-chain experience may benefit smaller upstart chains over established ecosystems.
- Symbiosis: Just as the United Nations and SWIFT cannot live without sovereign states, cross-chain protocol design and specification largely depends on L1’s design choices. Given the divergence of L1 design paradigms (high TPS, sharding, rollup, sidechains, application chains…), the most critical parameters of the cross-chain space remain undetermined. It’s too early to stand in line.
A valuable cross-chain protocol should be a non-extractive, stateless, thin protocol with few defenses, like the IP layer of the World Wide Web. In our opinion, some common approaches to building protocol moats are sub-optimal or value-destroying for cross-chain utilities:
- Lock in liquidity → fragmentation, friction and cost
- Unified liquidity pool → huge attack surface and capital inefficiencies
- Packaged user assets → systemic financial risk
- Trust off-chain repeaters → beware of runaways, monopolies, and censorship
Immediate impact: The main investment drivers for cross-chain infrastructure are likely to be ecosystem funds and VCs with vested interests. Public chains can provide cross-chain as a basic utility. In this context, credible neutrality becomes a rare virtue — a separate topic of interest, which we won’t expand on here.
Therefore, our discussion of the importance of cross-chain structures does not necessarily imply their proportional token investment value.
Section 2: Asset Cross-Chain – Trusted Intermediary
In this section:
- centralized exchange
- Asset Bridge
- Full chain DEX
Tokens are one of the most prominent Web 3 primitives. They make up most of the cross-chain use cases.
Historical analogy: Banks have been found to facilitate the transfer of value between two otherwise isolated sovereign states.
Centralized Exchange (CEX)
It is like commercial banks with currency reserves that exist in many countries. A simple, intuitive way to serve top-level use cases well – if it’s accessible.
- Simple UI/UX
- Lowest cost – most exchanges only charge gas fees for simple transfers – no complicated on-chain calculations.
- KYC and Taxes – Many people do not have access to services.
- Licensed Tokens – Most of the time, one can only transfer tokens listed on the CEX.
- Counterparty Risk: We don’t trust smart contracts, but Binance’s IT and integrity — albeit temporarily. For example, Binance suspended Dogecoin withdrawals.
- There is no composability of smart contracts.
It’s like a traveler’s check (if anyone is old enough to know what that is), a credit tool called wrapping in Web 3.
Example items: Wormhole, Ronin Bridge, Terra Bridge, Avalanche Bridge, Ren Bridge
how it works
- Alliance Bridge deploys smart contracts on both chains to lock native assets and issue custom-packaged assets on credit.
For example, lock 100 ETH on Ethereum –> mint 100 wormhole-wETH on Solana
- In theory, wrapped assets are backed 1:1 by locked assets on another chain.
- Such bridges have whitelisted off-chain validators. Validators observe native asset locks on Chain A, and then publish packaged assets on Chain B. In Wormhole’s case, there are 19 validators in the “Guardian Network”, and most of the guards are top Solana validators.
- Less permissionless than CEX – no KYC
- Smart Contract Composability
- No external liquidity lock-in due to packaging
- Since most computation is done off-chain, there is little extra gas
Trust assumption for federated validators. Often attacked or run away.
- ETH-SOL Wormhole bridge hacked for $325 million in February 2022
- ETH-RON bridge hacked for over $600 million in March 2022
1. Interaction with off-chain joint validators introduces additional network layers and smart contract vulnerabilities.
2. Fragmentation of packaging liquidity (wETH/ETH/xyzETH are different tokens), especially when multiple bridges compete. Wrapping creates an unwelcome trade-off between decentralization (many bridges) and liquidity efficiency.
3. Packaged assets issued on the credit of the protocol (such as wETH on SOL) are forever subject to hacking and decoupling, limiting the confidence and use cases of packaged assets and increasing systemic financial risk.
4. The asset list is still licensed under the bridge agreement.
Full chain DEX
Can we decentralize commercial banks?
Yes. This is the implementation of the DEX chain.
Example projects: THORChain, Osmosis, Anyswap
how it works
- Omnichain DEX introduces liquidity providers for native liquidity on multiple chains.
- Omnichain DEX introduces proprietary tokens (RUNE, OSMO, …) to bridge liquidity: the protocol swaps everything twice (ETH-RUNE-SOL) to facilitate the exchange of long-tail assets.
- Usually, though not necessarily, Omnichain DEX launches a dedicated chain for DEX computation.
- Less permissionless than CEX – no KYC.
- Smart contract composability.
- Unified liquidity: All chains use the same XXX-RUNE liquidity pool. That is, BNB/ETH/LUNA-SOL all come from the same RUNE-SOL pool.
- Native Assets: Once the exchange is complete, the integrity assumption of the DEX is no longer trusted. Essentially, DEXs transfer decoupling risk to LPs, not users.
- Open Asset List: Anyone can add liquidity to the DEX to allow new asset pairs.
- No immediate certainty: Since multiple chains may call the same RUNE-XXX liquidity pool at the same time, there is no guarantee at the time of submission that a transaction will be available at a specific price. This introduces additional friction in recovery/refund. Stargate claims to have fixed the problem.
- The intermediate chain is a single point of failure.
- Multiple layers of fees and slippage: THOR and OSMO issue native tokens as one aspect of the transaction (that is, all trading pairs are THOR/XXX). Native tokens are often necessary to maintain the economic incentives to operate private chains.
- XXX-THORChain bridges and repeaters are still centralized.
Summary: Intermediary Comparison
We don’t like Asset Bridge. Wrapped assets are not sovereign; they are illiquid instruments (IOUs) for vulnerable protocols.
Centralized exchanges remain the easiest and cheapest option for those with access to services (KYC, taxes, and wishing to transfer assets) with only temporary counterparty risk.
Outside of CEX, Omnichain DEX must be used. They have native assets and unified liquidity. Users will have to pay multi-layered protocol costs: liquidity costs, intermediate chain validation costs or repeater-oracle costs, exchange slippage, etc.
Section 3: Generalized cross-chain – trust but verify
In this section:
- IBC is the first universal cross-chain communication protocol. Biggest innovation: It can natively verify transactions on counterparty chains by maintaining an on-chain light client.
- Layer Zero attempts to alleviate the biggest problem with IBC: high gas fees to enable on-chain verification. Layer Zero involves Chainlink making different design choices regarding trust, fixed costs, and variable costs.
The next layer of cross-chain communication involves generalized communication. It’s not hard to see why generalized communication is structurally valuable:
- As the Web 3 primitives mature, there are more use cases than homogenized token transfers that can use cross-chain communication: NFTs, games, governance, credentials, native multi-chain dApps.
- As an infrastructure/API layer for more end-user applications to build and iterate full-chain DEX design options.
Taking a Step Back: High-Level Design of Intersystem Communication
The mystery of cross-chain communication is divided into three parts:
Some more details and discussions, you can skip if you don’t know the technology:
- Monitor & Alert: The system must receive some signal to start processing communication requests.
In Web 2, a typical implementation is a “Listener Code”, which means that the server is constantly (looping every millisecond) listening for its network requests. This paradigm is not possible for Web 3 because the cost of having a blockchain looping high-frequency computation is prohibitive.
In Web 3, automatically running smart contracts need to be notified that something has happened. The current solution relies on nodes – “relayers” – that need to verify both chains. We will discuss their role in the next section.
- Data: Detailed data about the transaction (called “payload”) must be communicated between systems.
In Web 2, this problem is trivial. Google can send anything to Facebook over the physical internet infrastructure.
In Web 3, the concern is that we need to be economical in computing. Fortunately, thanks to some smart design in Ethereum, we don’t have to send the entire block: to describe a transaction and prove that it happened on an Ethereum block, just send less than 0.1% of the Ethereum block (see: Patricia- tree). In IBC and Layer Zero, repeaters are responsible for transmitting data.
- Authentication: The receiver needs to be confident that the data was authorized for transmission by the correct sender
In Web 2, the problem is equally straightforward. Facebook uses established protocols such as HTTPS to verify Google’s server signatures and decrypt signed messages.
In Web 3, it is not enough to know a transaction and its block XYZ (data), but the receiving smart contract needs to know that block XYZ is included on the source chain. Confirmation is difficult because reorganizations can occur even after a block has been verified and signed. How to do this is the main difference between IBC and Layer Zero.
IBC: Repeater + Light Client
IBC separates three elements between relayers and on-chain light clients.
- Monitoring and Activation + Transaction Data – Relay: As mentioned earlier, a relay is a group of nodes that can verify both chains on the same physical machine. The repeater uses cheap cloud computing power to scan Chain A for network requests. If A–>B network requests are found, they submit the transaction to chain B.
- Verification – Light Client: IBC also needs to deploy an on-chain light client. Smart contracts on Chain B can independently verify on-chain that the transaction has been normalized on the source chain, which is the last step before IBC endorses the transaction.
On-chain light client: An on-chain light client is a program deployed on chain A to observe and record the latest block header (i.e. the longest chain) of chain B.
Discussion of key design choices
- The operation of IBC relies on off-chain relayers running light clients on Chain A and Chain B. The IBC Repeater software is open source and permissionless, so anyone can join. They do not need to be trusted to be safe, as the on-chain smart contract will verify all transactions. Relay redundancy is for service availability only.
- Since IBC contracts on ETH need to constantly save new block headers from other chains to maintain real-time verification, on-chain verification can be expensive on gas-heavy chains like ETH. “… tens of millions of dollars per paired chain [light client cost] per day on Ethereum,” according to Layer Zero.
- Cosmos solves the IBC Gas problem with a custom chain design: making IBC a chain-level module. Cosmos requires validators to maintain the Cosmos Hub light client at the chain level rather than the smart contract level. – Computational costs are implicitly borne by validators, not by specific smart contract accounts.
Layer Zero: Repeater + Oracle
LayerZero has two main differences from IBC:
- Deployment form: Layer Zero is a smart contract implementation of IBC (so it can run natively on chains like EVM and Solana) – as of March 2022, IBC only runs on the Cosmos chain.
- Replacing costly light clients: Instead of requiring smart contracts on each chain to sync block headers from all other connected chains, it outsources normalization checks to Chainlink.
- Monitoring and Activation + Transaction Data – Repeater: Same as IBC.
- Validation – Oracles: LayerZero uses Chainlink’s decentralized oracle network to check block submissions. For example, a Layer Zero smart contract would ask Chainlink:
“Is Terra block 129634 with merkle root 0xbbcc in your full Terra distributed ledger and has at least X subblocks”
Meanwhile, the “Data” section says,
“This is a Terra transaction at address 0x1927, sending 10 LUNAs to smart contract address 0x7878. The transaction is included in the block at the merkle root 0xbbcc, which is the merkle path proof that the block includes.”
Putting the two parts together, we will have both “data” and “validation” to prove that the transaction happened on the other chain.
Design Choice Discussion
- The use of Chainlink sacrifices some security and runtime latency compared to a fully on-chain light client.
- Introduces additional protocol dependencies and smart contract risks
- Invoking Chainlink contracts instead of checking on-chain data introduces additional latency and gas costs
- This is a trade-off between fixed and variable costs
- Light clients have a high fixed cost on some high gas chains (requiring updates to stay alive regardless of usage), but little variable cost per use.
- As the Chainlink network becomes congested, the cost per use of the oracle network increases slightly.
Given the differentiated optimization, we expect IBC to coexist with Layer Zero.
IBC is suitable for the following use cases:
- The Economics of Native Environments and Optimization: Chains in the Cosmos Ecosystem
- Low Gas Chains: BSC, Solana, …
- High-frequency communication (to dilute the fixed cost sufficiently) : Possibly a Polygon-Ethereum channel, or a pair of chains to move it forward.
Conversely, Layer Zero is great for connecting high-gas chains (ETH) with low-frequency chains.
Section 4: Looking to the future
In this section:
- The complexity of layer 2 and sharded chains will further complicate the cross-chain communication problem.
- Our speculation on future evolution:
- CLOB – Central Limit Order Book – for capital efficiency
- zk-SNARKs optimize on-chain verification
- Chain-level SDK is fully decentralized
The future is more complicated
Here we only discuss inter-chain communication between simple sovereign layer 1 public chains. The design space remains largely open for interoperability solutions for more complex blockchain designs. Here are some examples.
Layer 2 Rollup: Since layer 2 commitment/settlement is on Ethereum, Ethereum 1 layer may need to participate in proof of finality.
- Optimistic Rollups: The fatal flaw of ORs, the 7-day lock-up period for fraud detection, and the difficulty of interoperating with ORs.
Sharded chains: As of March 2022, the Ethereum Foundation has not decided on the design choice for ETH2. We are observing two things:
- When the Ethereum Foundation published sharding design choices: Data sharding v. Execution sharding v. ZK-SNARK v. …, and their impact on how other L1 chains communicate with ETH2.
- Internal communication protocol between ETH2 shards, if designed to communicate with each other.
Some guesses in our minds
Central Limit Order Book (CLOB)
Similar to how AMM DEX provides a more open but more expensive alternative to CLOB CEX, the most important pain point of current full-chain DEX is capital inefficiency.
Perhaps a full-chain DEX can learn from Serum to provide a central limit order book to provide different design options in terms of fees, finality, and latency. Or, if Serum moves fast enough, it can try it out on its own.
The design problem of zero-knowledge Rollup is very similar to ours:
How to conclusively prove that something happened on another chain?
While there is no time to delve into zk math here, we are excited to see that the combination between zk and cross-chain communication brings some or all of the following features:
- O(log n) compact computation for verification on the target chain
- IBC light client cost and on-chain data cost are further optimized
Chain-level SDK optimization to achieve complete decentralization
All current cross-chain solutions involve relays. As we discussed, the poor economics of cross-chain utilities mean that relayers are almost always the heavyweights of the ecosystem. They have common interests and, if necessary, collusion – in extreme cases the risk of centralization is high.
So, is a fully decentralized cross-chain bridge technically feasible? We believe yes:
By deploying an on-chain light client, the two green elements in the image above can already be decentralized:
“The purpose of the light client protocol is to allow users in low-volume environments (embedded smart property environments, smartphones, browser extensions, some desktops, etc.) to maintain highly secure guarantees about the current state of some specific parts. Ethereum state or verifying the execution of transactions” – a light client protocol
The final step in decentralization: Monitor and Alert .
Naive solution: A naive solution requires chain B to scan the entire block of chain A to discover if any transactions request cross-chain communication. Naive solutions are impossible if you imagine Ethereum scanning Solana.
SDK integration: Consider a proposal: Chain A requires a dedicated space in its blocks, even every few blocks. Chain A’s data rules state that everything involving validators must place all network requests in that block space. Let’s call it network bytes. Then chain B just needs to scan the network bytes for new connections. This design can reduce the scanning workload of chain B, similar to the light client is 2500 times lighter than the full node.
Blockspace formatting advice is by no means a crazy idea. Cosmos already does this in its Tendermint SDK. Solana has similar block space formatting rules, not for the network, but for optimizing parallel execution, see SeaLevel. No doubt there may be further optimizations in the future.
The design space is young and ambitious. Let’s keep watching and building together. We are excited about the prospect of a fully decentralized, whale-free, cross-chain communication protocol.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/the-dangers-present-and-future-of-cross-chain-communication-what-to-do-after-layer-zero/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.