ZK-Rollup

The defining feature is the use of Zero-Knowledge Succinct Non-Interactive Argument of Knowledge (ZK-SNARK) or Scalable Transparent Argument of Knowledge (STARK) proofs. These cryptographic proofs allow the rollup to verify the correctness of a batch of transactions without revealing any transaction details, ensuring data privacy and computational integrity. The main chain only needs to verify this small proof, not re-execute all transactions.

While computation is moved off-chain, transaction data (often in a compressed form called calldata) is posted to the main chain (Ethereum). This is critical for security and decentralization, as it allows anyone to reconstruct the rollup's state and challenge fraud if the operator acts maliciously. Solutions like EIP-4844 (proto-danksharding) are designed to make this data posting significantly cheaper.

Once the validity proof is verified and accepted on the main chain, the state transition is immediately finalized. This means users can withdraw their assets back to Layer 1 without a challenge period (unlike Optimistic Rollups). This provides a superior user experience for cross-layer transfers and defi interactions.

The zero-knowledge nature of the proofs can enable transaction privacy by default. While not all ZK-Rollups implement full privacy, the architecture allows for hiding sender, receiver, and amount details within the proof. Projects like Aztec leverage this to build private smart contract platforms on top of Ethereum.

The system relies on key actors:

• Sequencer: Orders transactions, creates blocks, and posts data to L1 (often a centralized entity initially, with plans for decentralization).
• Prover: A computationally intensive role that generates the ZK-proof for each batch. Provers require specialized hardware (GPUs/ASICs) and are incentivized by fees.

A major technical achievement is the development of zkEVMs, which are ZK-Rollups compatible with the Ethereum Virtual Machine. They come in types:

• Type 1 (Fully Equivalent): Matches Ethereum exactly (e.g., future goal of Taiko).
• Type 2 (EVM Equivalent): Looks like Ethereum but with minor changes (e.g., Polygon zkEVM, Scroll).
• Type 3 (Language Compatible): Supports Solidity/Vyper but not all opcodes (e.g., early zkSync Era). This allows developers to deploy existing smart contracts with minimal changes.

The core security guarantee of a ZK-Rollup is the validity proof (ZK-SNARK or ZK-STARK). This cryptographic proof, submitted with each batch of transactions, cryptographically verifies that the new state root is the correct result of executing all transactions in the batch. The main chain only needs to verify this proof, not re-execute the transactions, inheriting the security of the underlying cryptographic assumptions (e.g., computational hardness of certain mathematical problems).

For users to reconstruct the rollup state and exit, the transaction data (calldata) must be published and available on the base layer (e.g., Ethereum). This is the data availability requirement. If this data is withheld, the system defaults to a crypto-economic security model where honest actors can force-include data or trigger a mass exit. Systems that post full data are called validium if data is kept off-chain, introducing a separate data availability committee (DAC) as a trust assumption.

Most ZK-Rollups have upgradeable smart contracts controlled by a multi-sig or DAO. This introduces a trust assumption in the upgrade key holders, who could potentially upgrade the contract maliciously (e.g., to steal funds). This is a temporary social consensus and governance risk during the early stages. The security goal is to progress towards immutability or sufficiently decentralized governance over time.

Operational roles create centralization vectors:

• Sequencer: Orders transactions and creates batches. A malicious or censoring sequencer can affect liveness.
• Prover: Generates the validity proof, a computationally intensive task. Prover centralization is a liveness risk, not a safety risk, as the chain cannot progress without proofs. Decentralizing these roles is a key development focus, moving from a single trusted operator to a permissionless network.

Users have a fundamental right to withdraw assets even if the rollup operator is malicious or offline. This is enabled by:

• Priority Operations: Direct L1→L2 transactions.
• Force Exit (Escape Hatch): A mechanism allowing a user to submit a Merkle proof of their funds directly to the L1 rollup contract, bypassing the sequencer after a challenge period. This ensures censorship resistance and that user funds are always recoverable, assuming data availability.

The bridge contract on L1 that holds user funds and verifies proofs is a critical smart contract risk. It must be correctly implemented and audited. A bug here could lead to loss of funds. Additionally, applications deployed on the rollup inherit the rollup's security for consensus and data availability but have their own application-layer smart contract risk. Users must trust both the base bridge security and the security of the dApp's code.

The cryptographic engine of a ZK-Rollup. A validity proof is a succinct cryptographic attestation that proves the correctness of a batch of transactions without revealing their details. The two primary types are:

• ZK-SNARKs: Smaller and faster to verify, but require a trusted setup ceremony.
• ZK-STARKs: Larger proofs but offer quantum resistance and no trusted setup. These proofs are posted to the Layer 1 (e.g., Ethereum) to finalize state changes.

A critical security requirement ensuring transaction data is published and accessible. In a ZK-Rollup, compressed transaction data (calldata) is posted to the Layer 1. This allows anyone to reconstruct the rollup's state and verify the validity proofs. Solutions like EIP-4844 (proto-danksharding) and full danksharding on Ethereum are designed to drastically reduce the cost of this data availability layer.

The node responsible for ordering transactions and constructing blocks within the rollup. The sequencer:

• Receives and orders user transactions.
• Executes them to compute a new state root.
• Generates or coordinates the generation of the validity proof.
• Publishes the batch data and proof to Layer 1. Sequencers can be centralized for performance or decentralized for censorship resistance.

The mechanism for tracking user balances and contract state. A ZK-Rollup maintains a state tree (typically a Merkle or Verkle tree) where each leaf represents an account. The state root is a cryptographic commitment to the entire state. The sequencer publishes a new state root with each batch, and the validity proof cryptographically verifies that this new root is the correct result of applying the batched transactions to the old root.

The primary alternative scaling architecture. Optimistic Rollups assume transactions are valid by default (optimistically) and only run computation via a fraud proof if a challenge is submitted. Key differences from ZK-Rollups:

• Withdrawal Delay: Users face a 1+ week challenge period for withdrawals to L1.
• Inherited Security: Relies on economic incentives and at least one honest verifier.
• Generalized EVM: Historically easier to implement for full EVM compatibility.

Hybrid models that trade off between security and cost. Both use validity proofs for execution correctness.

• Validium: Uses proofs but stores data off-chain, relying on a committee or proof-of-stake for data availability. Higher throughput, but users cannot independently reconstruct state if data is withheld.
• Volition: Gives users a per-transaction choice between ZK-Rollup mode (data on L1) and Validium mode (data off-chain), balancing security and cost.