Interoperability and Bridges

Module 3 of Advanced Protocols

The Multi-Chain Problem

Each blockchain is an isolated system:

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│  Ethereum   │     │   Solana    │     │   Cosmos    │
│             │     │             │     │             │
│  State A    │     │  State B    │     │  State C    │
│  Rules A    │     │  Rules B    │     │  Rules C    │
└─────────────┘     └─────────────┘     └─────────────┘
      │                   │                   │
      └───────────────────┼───────────────────┘
                          │
                     No direct
                    communication

Blockchains can't natively verify each other's state. Bridges solve this.

How Bridges Work

Basic Mechanism: Lock and Mint

Source Chain (Ethereum)          Destination Chain (Polygon)
┌──────────────────────┐        ┌──────────────────────┐
│                      │        │                      │
│  User: Lock 1 ETH    │───────▶│  Bridge: Mint wETH   │
│  in Bridge Contract  │  msg   │  to User             │
│                      │        │                      │
└──────────────────────┘        └──────────────────────┘

On Return:
┌──────────────────────┐        ┌──────────────────────┐
│                      │        │                      │
│  Bridge: Unlock ETH  │◀───────│  User: Burn wETH     │
│  to User             │  msg   │                      │
│                      │        │                      │
└──────────────────────┘        └──────────────────────┘

The hard part: How does the destination chain know the lock really happened?

Bridge Trust Models

1. Externally Verified (Multisig)

Validators: Alice, Bob, Carol, Dave, Eve (3 of 5 required)

Lock on Ethereum
      │
      ▼
Validators observe and sign attestation
      │
      ▼
Submit attestation to Polygon
      │
      ▼
Polygon mints wETH

Trust: Majority of validators are honest Examples: WBTC, Multichain (defunct), many early bridges

2. Optimistic (Fraud Proofs)

Relayer posts claim: "User locked 1 ETH"
      │
      ▼
Challenge period: Anyone can dispute
      │
      ▼
No dispute? → Execute
Dispute? → Verify on-chain, slash if fraud

Trust: At least one honest watcher Examples: Connext, Across (in part)

3. Light Client (Header Verification)

Run light client of source chain on destination:

Source Block Header
      │
      ├── Block Hash
      ├── State Root
      └── Signatures/Proofs
      │
      ▼
Destination verifies header is valid
      │
      ▼
Prove transaction inclusion via Merkle proof

Trust: Source chain consensus Examples: IBC (Cosmos), Snowbridge

4. ZK Light Client

Source chain produces blocks
      │
      ▼
Generate ZK proof of header validity
      │
      ▼
Destination verifies proof (cheap!)
      │
      ▼
Prove transaction inclusion

Trust: Source chain consensus + cryptographic proof Examples: Succinct, zkBridge, Polyhedra

Trust Spectrum

More Trust Required                    Less Trust Required
      │                                      │
      ▼                                      ▼
Custodian → Multisig → Optimistic → Light Client → ZK Light Client
   1/1        3/5      1-of-N      Consensus      Consensus+Math

Types of Bridged Assets

Wrapped/Synthetic Assets

Representation of locked asset:

1 ETH locked on Ethereum → 1 wETH minted on Polygon

wETH is an IOU backed by locked ETH
Risk: If bridge is hacked, wETH loses backing

Canonical vs Non-Canonical

Canonical wETH: Official bridge, one version
Non-Canonical: Multiple bridges → Multiple versions!

Problem: USDC.e vs axlUSDC vs ceUSDC
         All represent USDC, but different bridges
         Not fungible with each other!

Native Asset Transfers

Some bridges move actual assets (not wrapped):

• Use liquidity pools on each chain
• Market makers provide liquidity
• No wrapping, but limited by pool size

Bridge Security Incidents

Largest Bridge Hacks

Common Vulnerabilities

1. Key Compromise

Multisig: 3 of 5 keys required
Attacker: Compromises 3 keys
Result: Full control of bridge funds

2. Smart Contract Bugs

// Vulnerable pattern (simplified)
function processMessage(bytes calldata proof) {
    // Bug: Didn't verify proof correctly
    if (proof.length > 0) {  // Too weak!
        mint(receiver, amount);
    }
}

3. Replay Attacks

Valid message on Chain A
      │
      ▼
Replayed on Chain B (where it shouldn't work)
      │
      ▼
Free minting!

Modern Bridge Designs

Liquidity Networks

Instead of Lock-Mint:

Chain A                              Chain B
┌─────────────┐                    ┌─────────────┐
│  Pool: USDC │                    │  Pool: USDC │
│  Liquidity  │◀──────────────────▶│  Liquidity  │
└─────────────┘   Rebalancing      └─────────────┘
      │                                  │
   User deposits                    User receives
   1000 USDC                        1000 USDC
      │                             (from pool)
      ▼                                  ▲
  Pool balance                    Pool balance
  increases                       decreases

Advantages: Native assets, fast, no wrapped tokens Disadvantages: Limited by liquidity, slippage

Examples: Hop, Across, Stargate

Intent-Based Bridges

User: "I want 1 ETH on Arbitrum"
      │
      ▼
Solver/Relayer: Fills order on Arbitrum
      │
      ▼
User: Sends ETH on Mainnet to relayer
      │
      ▼
Settlement ensures atomicity

Examples: Across, Socket, Li.Fi

Canonical Rollup Bridges

Ethereum ←→ Arbitrum (Native Bridge)

Security: Inherits L1 security
Speed: 7 days for withdrawal (optimistic)
       Hours (ZK rollups)
Cost: Cheapest per tx

Cross-Chain Communication

Message Passing

Beyond asset transfer - send arbitrary messages:

Contract A (Ethereum)           Contract B (Polygon)
┌─────────────────────┐        ┌─────────────────────┐
│  function send() {  │        │  function receive() │
│    bridge.send(     │───────▶│    // Execute       │
│      chainId,       │  msg   │    // cross-chain   │
│      data           │        │    // logic         │
│    );               │        │  }                  │
│  }                  │        │                     │
└─────────────────────┘        └─────────────────────┘

Use Cases:

• Cross-chain governance
• Multi-chain NFTs
• Cross-chain DeFi

Protocols

IBC: The Cosmos Standard

Inter-Blockchain Communication - the most mature cross-chain protocol:

Chain A (Cosmos SDK)            Chain B (Cosmos SDK)
┌──────────────────┐           ┌──────────────────┐
│  IBC Module      │◀─────────▶│  IBC Module      │
│                  │           │                  │
│  Light Client B  │           │  Light Client A  │
└──────────────────┘           └──────────────────┘
         │                              │
    Relayers observe and relay packets

How IBC Works

1. Connection: Chains establish relationship
2. Channel: Applications create channels over connections
3. Packets: Data sent through channels
4. Light Clients: Each chain tracks other's consensus

IBC Advantages

• Trust-minimized (light client verification)
• Standardized (works across Cosmos ecosystem)
• Battle-tested (billions transferred)

Aggregators and Meta-Bridges

Finding the best route across bridges:

User Request: 10,000 USDC from Ethereum to Arbitrum

Aggregator checks:
├── Stargate: $9,990 received, 2 min
├── Hop: $9,985 received, 5 min
├── Official Bridge: $9,995 received, 7 days
└── Across: $9,992 received, 1 min

Recommendation: Across (best speed/cost ratio)

Examples: Li.Fi, Socket, Bungee

Security Best Practices

For Users

1. Use canonical bridges when possible (slower but safest)
2. Check bridge TVL and track record
3. Diversify across bridges for large amounts
4. Wait for confirmations before considering finalized
5. Verify contract addresses independently

For Protocols

1. Minimize trust assumptions (ZK > Light Client > Multisig)
2. Rate limiting - cap transfer amounts
3. Monitoring - detect anomalies quickly
4. Bug bounties - incentivize finding bugs
5. Upgrade delays - time to respond to issues

The Future of Interoperability

Shared Security

Multiple chains sharing validator set:

• EigenLayer restaking
• Mesh security
• Cross-chain slashing

ZK Everywhere

• ZK light clients for all chains
• Proof aggregation
• Near-instant finality

Chain Abstraction

User doesn't think about chains:

User: "I want to buy this NFT"
System: Automatically routes funds from wherever
        Executes on target chain
        User never knows which chain

Key Takeaways

1. Bridges are high-value targets - billions stolen in hacks
2. Trust models vary widely - ZK > Light Client > Multisig > Custodian
3. No perfect bridge - trade-offs between speed, cost, security
4. Wrapped assets have risk - dependent on bridge security
5. Liquidity networks offer native asset transfers
6. IBC is the gold standard for trust-minimized bridging
7. Aggregators help find optimal routes
8. The future is chain abstraction - users shouldn't see chains