Bridges and Cross-Chain Communication

Imagine 200 islands, each with its own currency, banks, and laws. People want to trade between islands, but the ferries between them transport gold with no security. Over three years, pirates have robbed the ferries of $2.5 billion. Ronin Bridge lost $625M because of five stolen keys. Wormhole lost $325M because of one missing signature check. Nomad was looted for $190M by a crowd of people because a contract update accidentally made the vault door transparent. Blockchains are those islands, and bridges are the ferries. How do you build a ferry that won't get robbed?

• **$2.5B+ lost** in bridge hacks - more than all other DeFi attacks combined. Bridges hold enormous liquidity (locked assets) in a single contract, making them the most attractive target for hackers
• **IBC (Cosmos)** has processed $30B+ in cross-chain transfers with zero hacks, using light client verification - each chain independently verifies the other's block headers through cryptography, not trust
• **LayerZero, Chainlink CCIP, Hyperlane** provide generic message passing - arbitrary data and commands between chains. This enables cross-chain lending, governance, and NFT marketplaces operating simultaneously on multiple blockchains

Предварительные знания

• Rollups: the Scaling Idea

Lock-and-Mint: Moving Assets Between Chains

Blockchains are isolated by default. Ethereum knows nothing about Solana's state; Arbitrum can't see balances on Polygon. But users want to move assets between networks - buy ETH on Ethereum, use it in DeFi on Arbitrum, transfer it to Polygon for NFTs. This is what **bridges** are for - protocols that connect isolated blockchains. The most basic bridge mechanism is **lock-and-mint**: an asset is locked on the source chain, and a "wrapped" copy is minted on the target chain.

Not all bridges are the same. There are three fundamentally different architectures, and the difference between them is like the difference between "my bank" and "Western Union".

**AMM-based vs Intent-based - the evolution of bridges.** The first generation of liquidity bridges (Hop, Stargate) used AMM pools: transfer cost was determined by the x*y=k formula and pool balance. The second generation (Across, deBridge) works through **intents**: the user declares what they want to receive, and professional **solvers** (market makers) compete to execute it. This is analogous to the shift from order books to RFQ (request for quote) in traditional finance. Intent-based bridges offer better price and speed, but depend on solver competition.

The critical question for any bridge is - **who confirms that the deposit on the source chain actually happened?** A canonical bridge relies on L1 consensus. A third-party bridge - on its own validator set (MPC, multi-sig). A liquidity bridge - on economic incentives (LPs risk their own funds). An intent-based bridge - on a settlement mechanism that confirms execution via optimistic or ZK proof. Each model has its own trust assumption - and this is exactly where the cause of billion-dollar hacks lies.

Light Client Bridges: Trustless Verification

Lock-and-mint via MPC or multi-sig validators requires trusting those validators. If their keys are compromised - the bridge is hacked. A **light client bridge** solves this radically: instead of trusting a group of people, the target chain **independently verifies block headers** from the source chain. It's like the difference between "someone told me the payment went through" and "I checked the bank statement myself".

The gold standard for light client bridges is **IBC (Inter-Blockchain Communication)** in the Cosmos ecosystem. Each Cosmos chain runs a light client of another chain within its own state. When Osmosis (a DEX) wants to confirm a transfer from Cosmos Hub, the Cosmos Hub light client on Osmosis verifies the block header, validator signatures (2/3 Tendermint BFT), and the Merkle proof of the transaction. No external validators, no MPC - pure cryptographic verification.

For Ethereum, light client verification is especially complex due to the scale of the validator set. **Succinct proofs** solve this problem: instead of verifying 512 BLS signatures from the Sync Committee on the target chain, a **ZK proof** is generated confirming that "512 signatures are valid and total stake > 2/3". The target chain verifies one compact proof instead of hundreds of signatures - reducing verification cost from millions of gas down to ~200–300K gas.

**Latency tradeoff - the fundamental compromise.** Light client bridges sacrifice speed for trustlessness. An IBC transfer takes ~30 seconds (Tendermint finality time). zkBridge adds proof generation time (3–15 minutes). A liquidity/intent bridge (Across, Stargate) can execute in seconds, but requires trusting economic incentives. This is a spectrum: the less trust required - the slower the transfer.

Generic Message Passing: Data, Not Just Tokens

Lock-and-mint and light client bridges solve the problem of transferring **assets**. But what if you need to send **arbitrary data** between chains? For example: a governance vote on Ethereum that executes a command on Arbitrum. Or an NFT marketplace that, when a sale happens on Polygon, updates the seller's reputation on Ethereum. This requires **generic message passing** - protocols that transmit arbitrary messages (bytes) between blockchains, not just tokens.

**LayerZero** is one of the most widely used messaging protocols. Its architecture is built on the concept of an **ultra-light node**: instead of a full light client on every chain, LayerZero uses a combination of an **Oracle** (delivers block headers) and a **Relayer** (delivers transaction proofs). Security is built on the assumption that the Oracle and Relayer are **independent** entities, and their simultaneous compromise is unlikely.

**Delivery guarantees - levels of delivery assurance.** Messaging protocols differ in their guarantees: **at-most-once** (message delivered 0 or 1 times - no duplicates, but may be lost), **at-least-once** (guaranteed delivery, but duplicates possible - application must be idempotent), **exactly-once** (the ideal guarantee - technically the hardest). Most protocols provide at-least-once, and exactly-once semantics are implemented at the application layer via nonce and deduplication.

Generic message passing opened a new class of applications - **cross-chain dApps**. Aave V3 uses **Portals** to move liquidity between deployments on different chains. Uniswap governance on Ethereum L1 controls deployments on Arbitrum, Optimism, Polygon, and BSC through messaging bridges. Lido allows staked ETH (stETH) to be used in DeFi on L2 through canonical and messaging bridges. The future is **chain-abstracted** applications, where the user doesn't know which chain their transaction is executing on.

Bridge Security: $2.5B+ in Losses

Bridges are the most attacked part of crypto infrastructure. As of 2024, bridge hacks have resulted in losses of over **$2.5 billion**. The reason is fundamental: a bridge is the point where two different security domains meet. The contract on the target chain must "believe" that an event on the source chain actually happened. Any mistake in the mechanism of that trust is an attack vector with potential damage equal to all locked liquidity.

Every hack demonstrates the same fundamental problem: **verification of cross-chain events is the weakest link**. Ronin - validator key compromise. Wormhole - bug in signature verification code. Nomad - initialization error that nullified all checks. Multichain - centralization of MPC keys. The more liquidity in a bridge and the weaker the verification mechanism, the more attractive the target.

**Upgrade keys - the hidden attack vector.** Even a trustless bridge may have an admin key allowing contract upgrades. If that key is compromised, or if the admin is a low-threshold multi-sig, an attacker can replace the verification logic with `return true` and drain all funds. That's why when evaluating bridge security, people check not just the verification mechanism, but also: who controls upgrades? Is there a timelock? How many signatures are needed for an update? Immutable contracts are safer, but can't be patched for bugs.

The industry is moving toward **defense in depth** - multi-layered protection. Chainlink CCIP adds an independent Risk Management Network that can block suspicious transactions even if the main network is compromised. Hyperlane lets each application choose its own combination of Security Modules. New bridges use rate limiting (restricting withdrawal speed), which doesn't prevent a hack but limits damage: instead of an instant $500M drain, an attacker can only withdraw up to $10M per hour - giving time for detection and response.

Key Takeaways

• **Lock-and-mint** is the basic bridge mechanism: an asset is locked on the source chain, a wrapped copy is minted on the target. Canonical bridges inherit L1 security, third-party bridges rely on their own validators, and liquidity/intent bridges use native asset pools and solvers for instant transfers
• **Light client bridges** (IBC) achieve trustless verification: the target chain hosts a light client of the source and verifies headers + Merkle proofs cryptographically. zkBridge uses ZK proofs for compact verification, reducing gas from millions to ~200–300K
• **Generic message passing** (LayerZero, CCIP, Hyperlane, Axelar) transmits arbitrary data between chains, not just tokens - the foundation for cross-chain dApps: lending with collateral on one chain and a loan on another, L1→L2 governance, and chain-abstracted applications
• **Bridge security** is a critical challenge: $2.5B+ lost in hacks. Ronin ($625M - validator keys), Wormhole ($325M - verification bug), Nomad ($190M - zero Merkle root), Multichain ($125M - MPC centralization). The industry is moving toward defense in depth: ZK verification + rate limiting + independent monitoring + circuit breakers
• The islands with ferries from the hook are more than a metaphor. Blockchains really are isolated, and bridges are the only way to connect them. But a secure ferry doesn't need guards (multi-sig) - it needs engineering solutions: a storm-proof hull (ZK proofs), radar (monitoring), bulkheads (rate limiting), and a black box (audit trail)

Related Topics

Bridges and cross-chain communication connect scaling infrastructure with inter-network interaction:

• Rollups: Introduction — Canonical bridges are a built-in part of rollup architecture. Understanding data availability and settlement on L1 explains why a canonical bridge inherits L1 security and why withdrawal from an Optimistic Rollup takes 7 days
• Optimistic Rollups — The challenge period (7 days) directly determines the withdrawal speed through canonical bridges and creates a market for fast/liquidity bridges (Across, Hop) that front liquidity for a fee
• Cosmos and Sovereign Chains — IBC (Inter-Blockchain Communication) is the reference implementation for light client bridges. The Cosmos ecosystem has proven that trustless cross-chain communication scales to 100+ chains with $30B+ transferred without a single hack
• Threshold Cryptography — MPC (Multi-Party Computation) and threshold signatures are used in third-party bridges (Multichain, Wormhole Guardians). Understanding threshold crypto explains why key compromise is the primary attack vector against bridges

Вопросы для размышления

• IBC has had zero hacks over 3+ years, while EVM bridges have lost $2.5B+. Can this be explained by technical architecture alone (light client vs multi-sig), or are there other factors: TVL size as hacker motivation, codebase maturity, audit culture in different ecosystems?
• Intent-based bridges (Across, deBridge) rely on competition among professional solvers. What happens if the number of solvers shrinks (oligopoly)? Could this lead to centralization, censorship, or worse prices for users - and how does this differ from MEV centralization?
• If ZK light client bridges become the standard (trustless, fast, cheap), will messaging protocols like LayerZero or CCIP still be needed - or will they become a thin routing layer on top of ZK infrastructure?

Связанные уроки

• dist-07-transactions