Cross-Rollup Bridge

The security of a cross-rollup bridge is defined by its trust assumptions. Key models include:

• Optimistic (Fault Proofs): Relies on a challenge period where watchers can dispute invalid state transitions, similar to Optimistic Rollups themselves.
• ZK-Proof Based: Uses cryptographic validity proofs (e.g., zk-SNARKs) to verify the correctness of state transitions instantly and trustlessly.
• External Committee/Multi-sig: A faster but more centralized model where a predefined set of entities signs off on transfers.

These bridges enable generalized message passing, allowing not just token transfers but also contract calls and arbitrary data exchange between rollups. Core mechanisms involve:

• Lock-and-Mint / Burn-and-Mint: Assets are locked on the source rollup and minted as a representation on the destination, or vice-versa.
• State Root Relays: A light client or prover relays the state root (a cryptographic commitment to the entire rollup state) from one rollup to another, enabling verification of specific transactions.

Bridges handle asset representation in two primary ways:

• Canonical (Native) Bridging: The asset moves natively using the rollup's official bridge to L1 (e.g., Ethereum) as a hub, preserving its original contract and properties.
• Wrapped Asset Bridging: A third-party bridge locks the asset on the source chain and mints a new, wrapped token (e.g., wETH) on the destination. This introduces counterparty risk with the bridge custodian.

Most cross-rollup bridges leverage the underlying Layer 1 (L1) blockchain (e.g., Ethereum) as a neutral settlement hub and data availability source. Bridges often:

• Post transaction proofs or state commitments to the L1.
• Use the L1 as a verification layer where fraud or validity proofs can be settled.
• Rely on the L1's consensus for the final ordering and security of cross-rollup messages.

To avoid locking capital in bridges, some solutions use liquidity network models. These involve:

• Atomic Swaps: Peer-to-peer trades that settle across chains simultaneously using Hash Time-Locked Contracts (HTLCs), requiring no intermediary custody.
• Liquidity Pools: Providers deposit assets on both rollups; users swap assets instantly via the pool, with the bridge later reconciling net balances. This improves speed and capital efficiency.

An emerging architecture for ZK-Rollup interoperability uses a unified prover or shared proving system. A single, powerful ZK-proof can attest to the validity of state transitions across multiple independent ZK-Rollups. This allows for near-instant, trust-minimized bridging without relying on optimistic periods or external committees, as the cryptographic proof is the sole source of truth.

A bridge where the destination chain independently verifies the state of the source chain using light client proofs. This is the most secure but computationally expensive model.

• Example: The IBC protocol, which uses Tendermint light clients to verify state proofs between Cosmos app-chains.
• Security: Inherits the full security of the underlying chains; no external trust assumptions.
• Challenge: High gas cost for on-chain verification, making it less suitable for all environments.

A bridge that uses a fraud-proof mechanism, similar to Optimistic Rollups. Transactions are assumed valid unless challenged during a dispute window.

• Example: Nomad, which used a system of optimistic verification with watchers to flag invalid state roots.
• Trade-off: Lower operational cost and latency than light clients, but introduces a withdrawal delay (e.g., 30 minutes) for the challenge period.
• Risk: Relies on at least one honest watcher to submit fraud proofs.

A bridge that uses Zero-Knowledge proofs (e.g., zk-SNARKs, zk-STARKs) to cryptographically prove the validity of state transitions on the source chain.

• Example: zkBridge projects, which generate succinct proofs that can be verified cheaply on-chain.
• Advantage: Offers strong security with near-instant finality, as the proof verification is fast and cheap.
• Challenge: Requires complex trusted setups or significant computational resources to generate proofs.

The most common model, where a committee of external validators (a federation) signs off on cross-chain messages. Security depends on the honesty of this committee.

• Examples: Early versions of Polygon PoS Bridge, Multichain (formerly Anyswap).
• Characteristic: Fast and cheap, but introduces a trust assumption in the validator set.
• Risk: Centralization point; a majority compromise of the validator keys can lead to fund loss.

These bridges don't mint wrapped assets. Instead, they use atomic swaps and liquidity pools on both chains to facilitate cross-chain transfers.

• Example: Connext's Amarok protocol, which uses a network of liquidity providers (routers).
• Mechanism: A user locks funds on Chain A, a router provides liquidity on Chain B, and a cryptographic condition (hashlock/timelock) ensures atomicity.
• Benefit: No canonical wrapped asset risk; the bridge is a messaging layer for coordinated liquidity.

Official bridges deployed by the rollup or L2 team to mint canonical wrapped assets (e.g., WETH on Arbitrum). These are often the most trusted entry/exit points.

• Examples: Arbitrum Bridge, Optimism Gateway, zkSync Era Bridge.
• Function: Lock tokens on L1, mint a 1:1 representative token on L2 (and vice-versa).
• Security: Typically relies on the rollup's own fraud proof or validity proof system for message passing, making them relatively secure.

Bridges for optimistic rollups (e.g., Arbitrum, Optimism) inherit a security delay known as the challenge period (typically 7 days). During this window, a bridge validator must monitor and be ready to submit a fraud proof if invalid state transitions are detected. This creates a withdrawal latency and requires active, honest watchdogs. A successful fraud proof can slash the malicious validator's bond.

Bridges for ZK-rollups (e.g., zkSync, StarkNet) rely on cryptographic validity proofs (ZK-SNARKs, STARKs). The bridge contract on the destination chain verifies a succinct proof that the source rollup's state transition is valid. This offers near-instant, cryptographically guaranteed finality for withdrawals, removing the trust assumptions and latency of fraud proofs. The primary risk shifts to the correctness and trustworthiness of the prover system and initial trusted setup (if applicable).

A malicious or malfunctioning rollup sequencer can censor bridge withdrawal transactions, creating a liveness failure. While users can force transactions via the L1 (e.g., Ethereum) delay inbox, this is slower and more expensive. Bridges must have robust mechanisms to handle sequencer downtime or censorship to ensure users can always exit. This is a form of economic denial of service risk.

Most rollup and bridge contracts are upgradeable via a multi-sig or DAO to allow for protocol improvements. This introduces admin key risk, where the entity controlling the upgrade keys could maliciously modify bridge logic to steal funds. The security model is only as strong as the governance process. Users must assess the time-lock duration, multi-sig threshold, and decentralization of the governing body.

All rollup bridges fundamentally depend on data availability. The transaction data (calldata) must be posted and available on the base layer (L1). If this data is withheld (data availability problem), the bridge and its fraud/validity proofs cannot be verified, freezing assets. This risk is mitigated by Ethereum's strong data availability guarantees but is a critical consideration for bridges to other data availability layers or validiums.

Cross-rollup communication often uses a message passing paradigm. The bridge must correctly authenticate messages from the source rollup's outbox. This relies on relayers to transmit messages and proofs between chains. While the cryptographic verification is trustless, the system requires at least one honest, active relayer for liveness. Permissionless relay networks or economic incentives are used to mitigate this relay risk.