What's wrong with bridges？
Perils, Present and Future of Cross-Chain Communication: the road after Layer Zero
Key Takeaways:
The cross-chain design space has no clear winner yet. We expect to see further iterations after IBC/Layer Zero.
We compared all mainstream bridging designs in cost, safety, and efficiency:
Centralized exchanges (CEX) remain, ironically, the best option for whoever has access.
Asset bridges have fatal flaws of non-native wrapping.
Omnichain DEXes involve middle-chain liquidity lock-ups, which means more attack vectors and higher fees to compensate nodes and LPs.
(Moving beyond asset transfer toward generalized communication)
IBC is a generalized protocol with no external trust assumptions. IBC is secure and efficient. The only drawback is the high deployment cost.
Layer Zero is a variant of IBC that shifts the deployment cost towards a pay-per-use variable cost with the help of Chainlink. L0 is optimized for infrequent use cases but is less scalable in high-frequency communications.
Given the painful trade-offs, we believe design iterations are bound to continue. In Section IV, we will flash three ideas:
CLOBs: make cross-chain liquidity pools more capital efficient
zk-SNARKs: mitigate on-chain verification cost
Chain level SDK integrations: remove dependency on centralized external “relayers”
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 I: State of Cross-Chain Communication
In this section:
Multi-chain reality is here to stay
Value and use-cases of cross-chain infrastructure
Love-hate relationship between cross-chain and L1 wars
Value capture of cross-chain protocols: why it is (and should be) thin
The Design Space
In the short- to medium-term future, we will live with more chains, not less:
Technology is iterating: No final technical solution to scalability has matured. Scalability design choice iterations are bound to continue.
Capital is land-grabbing: Mountloads of money thrown behind top ecosystems means land-grabbing is not ending soon.
Protocols want to issue L1 tokens: Practically, the enticing economics of issuing Layer 1 tokens means successful app-layer protocols have incentives to launch use-case chains (example: Axie Infinity and Ronin).
Cross-chain interoperability is a structurally important design space:
Money interoperability: For users, money is money. Unconnected money is just store credits. Creating interoperability increases asset value.
Data interoperability: Facebook and Google have become the world’s most valuable businesses for capturing value in otherwise unconnected data. Similar data is now wasted in siloed blockchain databases.
Use cases: credentialing, credit score, metaverse identity, protocol rewarding users for behaviors on another chain
For those who are interested in the war of L1s, the Cross-Chain Communications space has deep ties to Blockchain Scalability too:
Competitive: If cross-chain communications become smooth enough, it may abstract L1s away. After all, who would care about the specs of Facebook’s servers as long as it lets us talk to friends without borders? On the margin, a more smooth cross-chain experience would likely favor smaller upstart chains against established ecosystems.
Synbiotic: Like the United Nations and SWIFT cannot live without sovereign nations, cross-chain protocol design and specs depend a lot on the design choices of L1s. Given the divergence in L1 design paradigms (High TPS, Sharding, Rollups, Sidechains, App chains …), the most critical parameters of the cross-chain space remain undecided. It is too early to call anything.
The Investment Case
A valuable cross-chain protocol should be a non-extractive, stateless thin protocol with little defensibility, like the IP layer of the World Wide Web. Some common ways of building protocol moat are, in our opinion, suboptimal or value destructive to a cross-chain utility:
Locking up liquidity → fragmentation, friction, and cost
Unified liquidity pool → great attack surface and capital inefficiency
Wrap user assets → systemic financial risk
Trust in off-chain relayers → beware of rug, monopoly, and censorship
The immediate implication: the primary investment drivers in cross-chain infrastructure would likely be ecosystem funds and VCs with vested interests. Chains could offer cross-chain as an essential utility. In such cases, credible neutrality becomes a rare virtue — a separate topic of interest that we shall not expand on here.
Therefore, our discussion of cross-chain’s structural importance does not necessarily imply their proportional token investment value.
Section II: Asset Cross-chain: Trusted Intermediaries
In this section:
Centralized Exchanges
Asset Bridges
Omnichain DEX
Tokens are one of the most salient Web 3 primitives. They make up most cross-chain use cases.
Historical analogy: people find banks to help facilitate the transfer of value between two otherwise siloed sovereigns.
Centralized exchanges (CEX)
It is like a commercial bank with currency reserves in many countries. A simple, intuitive way still serves the top use case quite well -- if one can access it.
Benefits
Simple UI/UX
Minimal cost -- most exchanges only charge gas fees for simple transfers—no complicated on-chain computation.
Limitations
KYC and taxation -- it is not accessible to many.
Permissioned Listing -- most of the time, one may only transfer CEX-listed coins.
Counterparty risks: we are not trusting smart contracts but Binance’s IT and integrity — though only momentarily.
No smart contract composability.
Asset Bridge
It is like a traveler’s check (if anyone is old enough to know what that is), a credit instrument called wrapping in Web 3.
Sample Projects: Wormhole, Ronin Bridge, Terra Bridge, Avalanche Bridge, Ren Bridge
How it works
Consortium bridges deploy smart contracts on both chains to lock native assets and issue custom-wrapped assets on credit.
e.g. Lock 100 ETH on Ethereum --> Mint 100 wormhole-wETH on Solana
The wrapped assets are, in theory, backed 1:1 by locked assets on another chain.
Such bridges have whitelisted off-chain verifiers. Verifiers observe native asset lock-up on Chain A before issuing wrapped assets on Chain B. In the case of Wormhole, there are 19 validators in the “Guardian Network,” most of the Guardians are top Solana validators
Benefits
More permissionless than CEX -- No KYC
Smart contract composability
No external liquidity lock-up because of wrapping
Little extra gas as most computation is done off-chain
Limitations
Trust assumptions on federated verifiers. Frequently attacked or rugged.
February 2022, ETH-SOL Wormhole bridge hacked for $325+ million
March 2022, the ETH-RON bridge hacked for $600+ million
Interaction with off-chain federated verifiers introduces additional layers of networking and smart contract vulnerabilities.
Fragmentation of wrapped liquidity (wETH/ETH/xyzETH are different tokens), especially if multiple bridges are to compete. Wrapping creates an undesirable trade-off between decentralization (many bridges) and liquidity efficiency.
Wrapped assets (like wETH on SOL), issued on the credit of the protocol, are perpetually exposed to hack and depeg, limiting confidence and use case of wrapped assets and increasing systemic financial risk.
The asset list is still permissioned by the bridge protocol.
Omnichain DEX
Can we decentralize the commercial bank?
Yes. Here’s the DEX chain implementation.
Sample 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: protocol swaps everything twice (ETH-RUNE-SOL) to facilitate the swap of long-tail assets.
Often, though not necessarily, Omnichain DEXs launch a special-purpose chain for DEX computation.
Benefits
More permissionless than CEX -- No KYC.
Smart contract composability.
Unified liquidity: all chains tap the same XXX-RUNE liquidity pool.
i.e., BNB/ETH/LUNA - SOL all draw from the same RUNE-SOL pool.
Native assets: no more trust assumptions of the integrity of the DEX once the swap is complete. Essentially, DEXs move depegging risks to LPs, not users.
Open asset list: anyone can add liquidity to the DEX to allow for new asset pairs.
Limitations
No immediate finality: due to the possibility of concurrent calls from multiple chains to the same RUNE-XXX liquidity pool, there is no guarantee at submission that a transaction can go through at a specific price. This introduces additional frictions around reverting/refunding. Stargate claims to have resolved this problem.
The middle chain is a single point of failure.
Multiple layers of fees and slippage: THOR and OSMO issue native tokens as one side of the trade (that is to say, all trading pairs are THOR/XXX). Native tokens are usually necessary to maintain economic incentives to operate the dedicated chain.
The XXX-THORChain bridges and relayers are still centralized.
Summing things up: intermediaries compared
We do not like Asset Bridges. Wrapped assets are not sovereign; they are illiquid IOUs of protocols vulnerable to attacks.
For those who have access (KYC, tax, and the assets one wishes to move), Centralized Exchanges remain the easiest and cheapest options with only a momentary counterparty risk.
Outside CEX, one has to work with Omnichain DEXs. They feature native assets and unified liquidity. Users will have to pay for multiple layers of protocol costs: liquidity cost, middle chain validation cost or relayer-oracle cost, swap slippage, and more.
Section III: Generalized Cross-chain: Trust but Verify
In this section:
IBC is the first general-purpose cross-chain communication protocol. Biggest innovation: it can natively verify transactions on the counterparty chain — by maintaining on-chain light clients.
Layer Zero tries the mitigate IBC’s biggest problem: high gas to enable on-chain verification. Layer Zero involved Chainlink to make a different set of design choice regarding trust, fixed cost and variable cost.
The next tier of cross-chain communication concerns generalized communication. It is not hard to see why generalized communication can be structurally valuable:
As Web 3 primitives mature, more use cases than fungible token transfer can use cross-chain communication: NFTs, gaming, governance, credentialing, natively multichain dApps.
To serve as an infrastructure/API layer for more end-user applications to build and iterate on omnichain DEX design choices.
A Step Back: High-Level Design of Inter-System Communications
The puzzle of cross-chain communication has three pieces:
Some more details and discussions, one may skim if not technically minded:
Monitor & Alert: A system must receive some signal to start processing a communication request.
In Web 2, a typical implementation is “Listener Code,” which means the server constantly (loops once every millisecond) its portal for network requests. This paradigm is impossible for Web 3 because of the prohibitive cost of having a blockchain loop high-frequency computation.
In Web 3, self-running smart contracts need to be notified that something is up. Current solutions rely on nodes that need to validate both chains-- “Relayers.” We will discuss what they do in the next section.
Data: detailed data about the transaction (called “payload”) must be communicated between systems.
In Web 2, this question is trivial. Google can send whatever to Facebook via the physical internet infrastructure.
In Web 3, the concern is that we need to be economical with computing. Luckily, thanks to some smart Ethereum design, we do not have to send entire blocks: to describe a transaction and prove it has happened on an Ethereum block, one only needs to send data sized less than 0.1% of an Ethereum block. (See: Patricia-tree) In both IBC and Layer Zero, Relayers are responsible for transmitting the data.
Verification: the receiver needs to be convinced the data is transmitted by the right sender’s authority
In Web 2, this question is similarly straightforward. Facebook uses established protocols (like HTTPS) to verify Google’s server signature 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 hard because reorg can happen even after a block has been verified and signed. How to do this is the main difference between IBC and Layer Zero.
IBC: Relayers + Light Client
IBC splits the three elements between Relayers and On-Chain Light Clients.
The Workflow
Monitor and Activation + Transaction Data-- Relayers: As discussed, Relayers are a set of nodes that can validate both chains on the same physical machine. Relayers use cheap cloud computing power to scan Chain A for networking requests. They submit transactions to Chain B if it finds an A-->B networking request.
Verification -- Light Client: The IBC also needs to deploy an on-chain light client (see definition). The smart contract on Chain B can independently verify on-chain if the transaction has been canonicalized at the source chain, a final step before IBC can endorse the transaction.
*Definition - On-chain Light Client: On-chain light clients are programs deployed on chain A that observe and record chain B’s newest block headers (i.e., The longest chain).
Key Design Choice Discussions
IBC’s operation relies on off-chain relayers who run light clients on both Chain A and Chain B. IBC relayer software is open-source and permissionless so that anyone can join. They do not need to be trusted for security as on-chain smart contracts will verify all transactions. Relayer redundancy is only for service availability.
The on-chain verification can be costly on high-gas chains like ETH since IBC Contracts on ETH need to constantly save new block headers from other chains to maintain live verification.
“… [light clients cost] tens of millions of dollars per day per pairwise chain on Ethereum,” according to Layer Zero
Cosmos solves the IBC gas problem with a custom chain design: making IBC a chain-level module. Cosmos asks validators to maintain Cosmos Hub light client at the chain level, not the smart contract level. -- The computational cost is implicitly borne by validators instead of a specific smart contract account.
Layer Zero: Relayers + Oracles
LayerZero versus IBC has two main differences:
Form of Deployment: Layer Zero is a smart contract implementation of IBC (so it can natively work on chains like EVM and Solana) -- IBC is only live on Cosmos chains as of March 2022.
Replaces Costly Light Client: Instead of requiring smart contracts on each chain to sync the block headers of all other connected chains, it outsources canonicalization checks to Chainlink.
The Workflow
Monitor and Activation + Transaction Data-- Relayers: the same as IBC.
Verification -- Oracles: LayerZero uses Chainlink’s Decentralized Oracle Network to inspect the block commitment. For example, Layer Zero smart contracts will ask Chainlink:
"whether Terra block 129634 with merkle root 0xbbcc is in your version of the full Terra ledger and has at least X child blocks"
Meanwhile, the “data” part says,
"Here's a Terra transaction of Address 0x1927 sending 10 LUNA to Smart Contract Address 0x7878. This transaction is included in a block with merkle root 0xbbcc, here's the merkle path proof of block inclusion."
Taking two pieces together, we will have both “data” and “verification” to prove a transaction has happened on another chain.
Design Choice Discussions
Compared to fully on-chain light clients, the use of Chainlink sacrifices some security and runtime latency.
Introduces additional protocol dependency and smart contract risks
Calling Chainlink’s contracts instead of examining on-chain data introduces additional latency and gas cost
It is a fixed-cost versus variable cost trade-off
Light clients have high fixed costs (needs updating to maintain liveness regardless of usage) on some high-gas chains but little to no variable cost-per-use.
Oracle networks have marginally increasing cost-per-use — as the Chainlink network becomes congested.
Given the differentiated optimization, we expect IBC and Layer Zero to coexist.
IBC is suitable for the following use cases:
Native environment and well-optimized economics: chains within the Cosmos ecosystem
Low-gas chains: BSC, Solana,…
High frequency of communication (to sufficiently dilute fixed cost): perhaps Polygon - Ethereum channel, or pairs of chains to make it going forward.
Conversely, Layer Zero can be a good fit for connecting high-gas chains (ETH) with low-frequency chains.
Section IV: Looking Ahead
In this section:
Complexities in Layer 2s and sharded chains will further complicate the cross-chain communication problem.
Our speculations of future evolutions:
CLOBs — central limit order books — to improve capital efficiency
zk-SNARKs to optimize on-chain verification
Chain-level SDKs to fully decentralize
More Complexities Ahead
Here we only discussed the interchain communication between simple sovereign layer 1s. The design space remains mostly open for interoperability solutions for more complicated blockchain designs. Here’s some examples.
Layer 2 roll-ups: Since the commitment/settlement of layer 2 is on Ethereum, Ethereum layer 1 will probably need to be involved in proving finality.
Optimistic Roll-ups: the fatal flaw of ORs, the lengthy 7-day lock-up for fraud detection, will likely exacerbate the difficulty of interoperability with ORs on one side.
Sharded chains: As of March 2022, the Ethereum foundation has not made up its mind on the design choices of ETH2 yet. We are watching two things:
When the Ethereum Foundation releases sharding design choice: data shard v. execution shard v. ZK-SNARK v. ..., and their implications on how other L1 chains may talk to ETH2.
Internal communication protocol among ETH2 shards, if designed to communicate with each other at all.
Some speculations in our mind
Central Limit Order Books (CLOBs)
Similar to how AMM DEXs offer a more open yet expensive alternative to CLOB CEXs, the most significant pain point of omnichain DEXs today is low capital efficiency.
Maybe omnichain DEXs can borrow from Serum in offering central limit order books to offer a different design choice regarding fees, finality, and latency. Alternatively, Serum itself can have a try if it moves fast enough.
ZK-SNARKs
The design question of zero-knowledge roll-ups is very similar to ours:
How to prove something has happened on another chain with finality?
While there is no time to dive into zk math here, we would be thrilled to see the marriage between zk and cross-chain communication bring some or all of the following features:
O(log n) succinct computation for verification on the destination chain
Further optimization of IBC light client cost and on-chain data cost
Chain-level SDK standardization for complete decentralization
All current cross-chain solutions involved relayers. As we discussed, the poor economics of a cross-chain utility means relayers almost always are ecosystem heavyweights. They share a common interest and can, if necessary, collude — posing a significant risk of centralization in extreme circumstances.
So is a fully decentralized cross-chain bridge technically conceivable? We believe yes:
The two elements in green are already decentralizable by deploying an on-chain light client:
"The purpose of the light client protocol is to allow users in low-capacity environments (embedded smart property environments, smartphones, browser extensions, some desktops, etc) to maintain a high-security assurance about the current state of some particular part of the Ethereum state or verify the execution of a transaction"
One final step to decentralization: Monitor and Alert.
Naive solution: A naive solution would require Chain B to scan entire blocks of Chain A to discover if there is any transaction requesting cross-chain communication. The naive solution is impossible if one imagines Ethereum scanning Solana.
SDK Integration: Consider a proposal: Chain A mandates a dedicated space in its block, or even once every few blocks. Chain A’s data rules require miners to place all networking requests in that block space (the "networking bytes"). Then Chain B only needs to scan networking bytes for new connections. The design can reduce Chain B’s scanning workload, similar to how light clients are 2500x lighter than a full node. (This is because light clients only sync a very limited scope of metadata.)
A block-space formatting proposal is by no means a crazy idea. Cosmos has done it in its Tendermint SDK. Solana has similar block-space formatting rules, not for networking but for optimized parallel execution, see SeaLevel. There are undoubtedly further optimizations possible down the line.
Bravos! Thank you for reading through the long long piece. The design space is young and ambitious. Let us stay tuned and build together. We are excited about the prospect of a fully decentralized, whale-free cross-chain communication protocol.
Messages are always welcome:
Directly on substack
Twitter @TheAntiApe
Email: theantiape@gmail.com
Acknowledgments
We want to thank our thought partners for the brainstorming chats, reviews, comments, and edits that have made this piece possible.
Rebecca, Building @Pentagon, https://twitter.com/rebeccadai0
Rui, HashKey Capital, https://twitter.com/YeruiZhang
Cathy, Xerse Ventures, https://twitter.com/cc0987xx