Rollup Contract

The rollup contract is the immutable, trust-minimized root deployed on the parent chain (L1). It is the only component users must trust, as it:

• Holds all deposited funds in escrow.
• Publishes and verifies state roots or validity proofs.
• Finalizes withdrawals after a challenge period or proof verification. Its security is inherited directly from the underlying L1 consensus.

In an Optimistic Rollup, the contract assumes state updates are valid but allows for fraud proofs. Key mechanisms include:

• State Commitment: Publishes compressed transaction data and a new state root.
• Challenge Period: A mandatory delay (e.g., 7 days) where anyone can submit a fraud proof.
• Verification Game: If a fraud proof is successful, the contract reverts the fraudulent state update and slashes the sequencer's bond.

In a ZK-Rollup, the contract verifies cryptographic proofs (e.g., zk-SNARKs, zk-STARKs) for every state transition. This model ensures:

• Immediate Finality: Withdrawals can be processed as soon as the proof is verified on L1.
• No Challenge Period: Security is mathematical, not economic.
• Data Availability Requirement: The contract still requires transaction data to be posted to L1 so users can reconstruct the state and generate proofs.

A critical security feature is allowing users to exit the rollup even if the sequencer is malicious or offline. The contract enables:

• Forced Withdrawals/Tx Inclusion: Users can submit transactions directly to the L1 contract.
• State Exit: Users can provide a Merkle proof of their funds directly to the contract to withdraw, using only the data published on L1. This ensures self-custody is never compromised.

The contract's upgrade mechanism is a central security consideration. Models include:

• Immutable: Highest security, but no bug fixes (rare).
• Timelock + Multisig: Changes are delayed and require multiple signatures.
• Security Council: A decentralized set of entities for emergency upgrades. Admin keys represent a trust assumption and potential centralization vector if misused.

The contract enforces economic security through bonded sequencers/provers.

• Sequencer Bond: In optimistic rollups, sequencers post a bond that can be slashed for submitting fraudulent state roots.
• Prover Staking: In some ZK-rollups, provers may stake to ensure liveness. These bonds are held by the rollup contract and act as a deterrent against malicious behavior.

The primary node responsible for ordering transactions off-chain before submitting them to the base layer (L1). It provides fast transaction confirmations and can be centralized for efficiency or decentralized for censorship resistance. Key functions include:

• Batching transactions into compressed blocks.
• Posting data or proofs to the L1.
• Generating state roots for the new rollup state.

The mechanism that ensures transaction data is published and accessible so anyone can reconstruct the rollup's state and verify correctness. This is a core security requirement. Solutions include:

• Ethereum calldata: The original, secure but expensive method.
• EigenDA / Celestia: External data availability layers offering lower costs.
• Data Availability Committees (DACs): A trusted, permissioned model for validiums.

A cryptographic commitment (like a Merkle root) that represents the entire state of the rollup (account balances, contract code, storage) at a given point in time. The rollup contract stores the latest state root on the L1. Any proposed state transition must be accompanied by a proof (ZK or fraud) that verifies the new root is the correct result of executing the batched transactions.

A smart contract on the base layer (L1) that verifies zero-knowledge proofs (ZKPs) for ZK-Rollups. It contains the verification key and performs a computationally cheap check on the cryptographic proof submitted by the prover. A successful verification by this contract is the final authorization for the rollup contract to update its state root.

A critical security parameter in Optimistic Rollups. It is the delay period (typically 7 days) during which any honest participant can challenge an invalid state transition by submitting a fraud proof. During this window, assets bridged from the rollup cannot be withdrawn on L1. This window provides time for decentralized verification and is a trade-off for faster and cheaper proving under normal conditions.

A set of contracts that facilitate the trust-minimized movement of assets between the base layer (L1) and the rollup (L2). It typically consists of two parts:

• L1 Escrow: Holds deposited assets and authorizes withdrawals.
• L2 Minting: Mints a representative token on the rollup when assets are deposited, and burns it upon withdrawal initiation. The rollup contract's state root is the source of truth for withdrawal authorization.