Rollup Contract (L1)

The contract's primary function is to store and verify the state root, a cryptographic commitment (like a Merkle root) that represents the entire state of the rollup's L2 chain (account balances, contract code, storage). Sequencers post new state roots to this contract, which L1 validators can challenge during a dispute window.

For Optimistic Rollups, the contract accepts and stores transaction calldata batches. For ZK-Rollups, it accepts validity proofs. This ensures transaction data is available on the secure L1, allowing anyone to reconstruct the L2 state and verify correctness, which is fundamental to the rollup's security.

In Optimistic Rollup designs, this contract enforces a challenge period (typically 7 days). During this window, any watcher can submit a fraud proof to challenge an invalid state root. The contract acts as a judge, verifying the proof and slashing the sequencer's bond if fraud is confirmed.

For ZK-Rollups, the contract contains the verification key and logic to cryptographically verify a zero-knowledge proof (e.g., a SNARK or STARK). Only state roots accompanied by a valid proof are accepted and finalized, providing instant cryptographic assurance without a challenge period.

The contract manages the canonical bridge between L1 and L2. It locks user funds deposited from L1 and mints corresponding tokens on L2. For withdrawals, it burns L2 tokens and releases the locked L1 assets, with the process governed by the verified state roots or validity proofs.

The contract often includes logic for permissioned or permissionless sequencer/prover selection. It may hold staked bonds, distribute fees, and enforce slashing conditions for malicious actors (e.g., submitting invalid state roots). This defines the economic security of the network.

The rollup contract on the L1 (e.g., Ethereum) is the single source of truth for the rollup's state. It does not execute transactions but verifies state transitions proposed by rollup sequencers. Finality is achieved when the L1 contract accepts a state root, making the rollup's security inheritable from the underlying L1's consensus and data availability.

The contract's verification logic depends on the rollup type:

• ZK-Rollups: Verifies a zero-knowledge validity proof (e.g., SNARK, STARK) for each batch, cryptographically guaranteeing state correctness.
• Optimistic Rollups: Assumes state transitions are valid but enforces a fraud-proof window (typically 7 days) during which any watcher can challenge and prove fraud.

The verification cost (gas) is a primary constraint on throughput.

For the L1 to act as a dispute resolver or proof verifier, transaction data must be available. The rollup contract typically requires sequencers to post transaction data as calldata on the L1. This creates a permanent, verifiable record. Solutions like EIP-4844 (blobs) and validiums modify this model, trading off pure L1 security for lower costs.

Most rollup contracts have upgrade mechanisms controlled by a multi-sig or DAO. This introduces a trust assumption separate from the L1's cryptography. A malicious upgrade could alter verification rules or steal funds. The security model must consider:

• Timelocks on upgrades
• Multisig thresholds
• Paths to decentralization and eventual immutable status

The L1 contract manages the canonical bridge for moving assets between L1 and L2. Withdrawal requests are proven or disputed via the same verification mechanism (proofs or fraud proofs). A critical security property is withdrawal finality: once a withdrawal is proven valid on L1, it cannot be reverted, even if the rollup's sequencer is malicious.

While the L1 contract defines rules, a centralized sequencer can create liveness issues. The contract may include:

• Force-inclusion mechanisms allowing users to submit transactions directly to L1 if censored.
• Proof-of-Stake (PoS) based sequencer selection for decentralized operation.
• MEV resistance designs to mitigate centralized sequencer extraction.

The cryptographic commitment (typically a Merkle root) posted to the L1 contract that represents the entire state of the rollup chain (account balances, contract code, storage). This root is the single point of truth that the contract verifies. The rollup sequencer posts a new state root with each batch of transactions.

A cryptographic proof submitted to the L1 contract to challenge an invalid state transition in an Optimistic Rollup. It demonstrates that a posted state root is incorrect. If valid, the contract reverts the faulty state and slashes the sequencer's bond. This mechanism enforces correctness through economic incentives.

A cryptographic proof (like a ZK-SNARK or ZK-STARK) submitted with each batch to the L1 contract in a ZK-Rollup. The proof cryptographically guarantees the correctness of the state transition. The contract verifies this proof; if valid, it instantly finalizes the new state root without a challenge period.

The node responsible for ordering transactions, executing them off-chain, batching them, and submitting data with the new state root to the L1 contract. In decentralized models, sequencers may stake bonds in the contract. The contract defines the rules for sequencer operation and slashing conditions.

The requirement that transaction data for a rollup batch must be published and accessible, typically by posting calldata to the L1. The L1 contract may enforce this. Without it, users cannot reconstruct the rollup state or generate fraud proofs, breaking the security model. Solutions include Ethereum calldata, blobs, or separate DA layers.

Often part of the main rollup contract, this component manages the deposit and withdrawal of assets between L1 and L2. To deposit, users lock funds in the L1 contract, which are minted on L2. To withdraw, users initiate a request on L2, and after the challenge window (Optimistic) or proof verification (ZK), the L1 contract releases the funds.