Rollup Contract

The contract's primary role is to store the official, finalized state root of the rollup. It receives and validates state transitions (new state roots) proposed by the sequencer or proposer. For Optimistic Rollups, this state is considered pending during the challenge period; for ZK-Rollups, it's finalized upon verification of a validity proof.

It enforces the data availability requirement by accepting and storing transaction data. For validium or certain ZK-Rollup designs, it may only store data availability certificates. The contract ensures all necessary data to reconstruct the rollup state is published to the L1, enabling trustless execution and fraud proofs.

In Optimistic Rollup architectures, the contract facilitates fraud proofs. It allows verifiers to challenge an invalid state root during the challenge window (typically 7 days). The contract manages the interactive verification game or fault proof process, ultimately slashing the malicious proposer's bond and rewarding the challenger.

For ZK-Rollups, the contract's critical function is to verify cryptographic proofs (e.g., ZK-SNARKs, ZK-STARKs). It runs a verification key to check the proof's validity, ensuring the proposed state transition is correct without re-executing all transactions. This allows for instant finality on L1.

It acts as the secure bridge hub between L1 and L2. Users deposit assets by locking them in the contract, which mints corresponding tokens on L2. Withdrawals are initiated on L2 but finalized on L1 by the contract, which burns L2 tokens and releases the locked assets after any required delay or proof.

The contract often encodes the rules for sequencer or proposer selection and incentives. It holds stake or bonds to disincentivize malicious behavior. Some designs allow for decentralized sequencer sets or proposer committees, with the contract managing their permissions and slashing conditions.

The primary role is to securely store the state root of the rollup. This single hash (e.g., a Merkle root) represents the entire state of accounts and balances on Layer 2. All withdrawals and cross-chain interactions are verified against this committed state. The contract's integrity is paramount, as a corrupted state root can lead to loss of funds.

The contract validates cryptographic proofs to update its state. For ZK-Rollups, it verifies a Zero-Knowledge Succinct Non-Interactive Argument of Knowledge (zk-SNARK/STARK) proving the correctness of a batch of transactions. For Optimistic Rollups, it accepts state updates optimistically but enforces a fraud proof window (typically 7 days) during which invalid state transitions can be challenged and reverted.

The contract's security is intrinsically linked to data availability. For validity proofs (ZK-Rollups), transaction data must be published to Layer 1 to allow users to reconstruct state and exit. For fraud proofs (Optimistic Rollups), this data is mandatory for constructing challenges. If data is withheld (a data availability problem), the system can halt, preventing users from proving ownership of funds.

Many rollup contracts are upgradeable, controlled by a multi-sig or DAO. This introduces a trust assumption in the upgrade governors. A malicious upgrade could alter proof verification logic or steal funds. Time-locked upgrades and security councils are common risk-mitigation strategies. The degree of decentralization of this control is a critical security consideration.

To protect users if the rollup sequencer fails (e.g., censors transactions), the contract implements forced transaction or escape hatch mechanisms. Users can submit transactions directly to the contract to withdraw their assets, often requiring them to provide a Merkle proof of inclusion in the latest state root. This ensures censorship resistance is inherited from Layer 1.

The rollup contract is paired with one or more bridge contracts that manage the deposit and withdrawal of assets. Users lock assets in the bridge on L1, which signals the rollup contract to mint equivalent tokens on L2. Withdrawals require proof to the bridge that the L2 state includes the burn. A vulnerability in the bridge logic directly compromises the rollup's asset security.

The component of the Rollup Contract that manages the deposit and withdrawal of assets between the L1 and the rollup. Users lock funds into this contract to mint assets on L2, and prove withdrawals to retrieve funds back to L1. It enforces security by requiring valid fraud or validity proofs.

The on-chain logic that validates cryptographic proofs submitted by rollup sequencers. For a ZK-Rollup, it verifies a zero-knowledge validity proof (e.g., a SNARK or STARK). For an Optimistic Rollup, it facilitates the fraud proof challenge window, allowing verifiers to contest invalid state transitions.

The node responsible for ordering transactions and constructing blocks on the rollup (Layer 2). It batches transactions and posts compressed data (calldata) and state roots to the Rollup Contract on L1. It can be a single permissioned entity or a decentralized network.

The guarantee that transaction data is published and accessible. Rollups typically post this data to the L1 (e.g., Ethereum calldata), making it available for anyone to reconstruct the rollup state. Data Availability Layers (like Celestia or EigenDA) are emerging as alternative, cost-effective publishing locations.

A cryptographic commitment (like a Merkle root) representing the entire state of the rollup (account balances, contract code, storage). The sequencer periodically posts the latest state root to the Rollup Contract. This root is the canonical reference that the L1 accepts as the official rollup state.

A safety mechanism in the Rollup Contract that allows users to directly withdraw assets back to L1 without relying on the rollup's normal operational integrity. This can be triggered if the sequencer censors a user or becomes unresponsive for a prolonged period, though it involves a significant delay.