The ZK rollup architecture behind Ethereum layer-2 networks now informs the base layer’s own roadmap as the Glamsterdam upgrade moves through testnets. Glamsterdam activated on Sepolia on October 6 and introduces enshrined proposer-builder separation, which widens the window for proving layer-1 blocks from one to two seconds to six to nine seconds.
Core developers postponed the Hoodi activation set for October 26 to review gas repricing in EIP-8037, and mainnet has no date. Rollups run the pipeline Ethereum wants to reuse: a sequencer orders transactions, a prover generates a validity proof, and a verifier contract on layer 1 accepts or rejects the result.
Ethereum Reuses the Rollup Proof Pipeline for Layer 1
The Ethereum Foundation defines real-time proving as proofs for 99% of mainnet blocks within 10 seconds on hardware costing at most $100,000 and drawing at most 10 kW, with 128-bit security, open-source code, and proofs of 300 KiB or less without a trusted setup. In December 2025 the foundation reported proving latency falling from 16 minutes to 16 seconds and costs dropping 45 times.
Succinct’s SP1 Hypercube proved 99.7% of sampled blocks in under 12 seconds on 16 RTX 5090 GPUs, and the foundation set 128-bit provable security as the end-2026 milestone.
EIP-8025, which core developers propose for Hegotá, lets attesters accept a block after verifying execution proofs instead of re-executing transactions, with a working threshold of three valid proofs out of five from different client implementations. A research proposal would expose the same verification machinery to smart contracts, because every ZK rollup deploys its own verifier contracts.
The ZK rollup architecture has five components: the sequencer, the prover, the verifier contract, the data availability layer, and the forced-exit path.
Sequencers Order Transactions and Commit State Roots
In the ZK rollup architecture, the sequencer receives signed transactions, executes them on the layer-2 virtual machine, and groups them into batches. Most production chains run a single operator, and some rotate the role across a proof-of-stake validator set whose members risk slashing. The rollup stores balances in a Merkle tree, and the sequencer computes a new state root after each batch.
The layer-1 contract stores the current state root, and each submission carries four public inputs: the pre-state root, the post-state root, the batch root, and the transaction inputs. A proof passes only when the pre-state root matches the stored root, which keeps batches in a single linear chain.
Centralized sequencing leaves a risk proofs cannot remove in any ZK rollup architecture: the operator controls ordering and can delay or censor inclusion, while validity proofs only verify correct execution.
Provers Compress Execution Into Validity Proofs
The prover in a ZK rollup architecture takes a batch’s execution trace and produces a proof of correct state transition between the pre-state root and the post-state root. Teams build on a zkVM, which proves ordinary Rust or RISC-V programs instead of hand-written circuits: Scroll uses OpenVM, Taiko uses SP1 and RISC Zero, and Mantle uses SP1 Hypercube.
zk-SNARK and zk-STARK systems trade proof size against setup assumptions. SNARK proofs are small and verify in constant time, but a compromised trusted setup allows forged proofs. STARK proofs need no setup and resist quantum attacks, but they are larger and cost more to verify on layer 1. Rollups combine both by wrapping: Scroll wraps an OpenVM STARK in a Halo2 SNARK, and Lighter wraps a Plonky2 STARK in a gnark Plonk proof, letting the on-chain verifier check the cheaper SNARK.
Recursive proofs aggregate many block proofs into one, letting one layer-1 verification finalize several layer-2 blocks. Verifying a proof on Mainnet costs roughly 500,000 gas, which makes aggregation a direct route to lower per-transaction fees in the ZK rollup architecture.
Most rollups use proofs for succinctness and correctness, not secrecy, despite the name: published transaction data stays public, and privacy-focused chains like Aztec add confidentiality as a separate property.
Verifier Contracts and Blobs Settle State on Ethereum
The verifier contract in the ZK rollup architecture checks the proof against the public inputs, and the rollup contract adopts the post-state root only after the check succeeds. Settlement rests on three elements: the soundness of the proof system, the correctness of the verifier code, and data availability, which lets users rebuild state and exit if the operator disappears.
Rollups publish compressed transaction data or state differences as calldata or in blobs, which EIP-4844 introduced. Each blob holds 128 KB, and nodes must serve blob data for roughly 18 days, a serving obligation rather than permanent storage. Validiums keep validity proofs but store data elsewhere, removing Ethereum’s availability guarantee for the data.
Blob capacity for the ZK rollup architecture has grown with every upgrade since Dencun: the target and maximum per block moved from 3 and 6 to 6 and 9 at Pectra, 10 and 15 after the BPO1 fork on December 9, 2025, and 14 and 21 after BPO2 on January 7, 2026. PeerDAS supports the higher counts through data availability sampling, letting nodes check availability without downloading every blob.
Forced Transactions Protect Exits From Operator Failure
A forced transaction lets a user submit an operation directly to the layer-1 rollup contract when the sequencer censors or stops. In Linea’s implementation the sequencer must process the transaction before a deadline, and the layer-1 proof verification for the batch reverts if the sequencer skips it, blocking finalization. Withdrawals carry a Merkle proof of inclusion checked against the stored batch root.
The ZK rollup architecture separates two guarantees: proofs ensure executed transactions follow the rules, and forced inclusion ensures users reach the rollup contract without operator approval.
zkEVM Types and L2BEAT Stages Define Compatibility and Trust
Vitalik Buterin’s zkEVM types place each design choice in the ZK rollup architecture on a spectrum between Ethereum equivalence and proving speed. Type 1 changes nothing in Ethereum, Types 2 and 2.5 alter data structures or gas costs, Type 3 drops precompiles hard to prove, and Type 4 uses a custom virtual machine for the fastest proofs.
Taiko targets Type 1, Linea and Scroll target EVM equivalence, ZKsync Era runs EraVM, and Starknet runs Cairo, which breaks bytecode-level assumptions on the last two.
L2BEAT stages rate how much control privileged operators retain rather than code security, with Stage 0 meaning control by few entities. Stage 1 requires exits without permissioned operators, a seven-day exit window for upgrades outside the Security Council, and a council of at least eight members with a 75% threshold. Stage 2 requires a permissionless proof system, a 30-day exit window, and council powers limited to provable on-chain bugs.
Alchemy’s August 2026 review of L2BEAT data lists every general-purpose ZK rollup at Stage 0 except Starknet at Stage 1, while Aztec reached Stage 2 in June after governance revoked ownership of the rollup contract. The ZK rollup architecture can prove correctness at every stage, and the stage determines who can still change the rules around the proof.
FAQ
What are the five components of a ZK rollup architecture?
The sequencer orders transactions and builds batches, the prover generates a validity proof, the verifier contract on Ethereum checks the proof, the data availability layer publishes batch data through blobs or calldata, and the forced-exit path lets users reach the rollup contract without the sequencer.
Which inputs does the verifier contract check?
The contract checks the proof against four public inputs: the pre-state root, the post-state root, the batch root, and the transaction inputs. It adopts the post-state root only when the proof is valid and the pre-state root matches the root already stored.
Why does a ZK rollup publish data on Ethereum if proofs already show correctness?
Published data lets anyone rebuild the rollup state, submit batches, and exit when the operator stops. Blobs carry the data and nodes serve it for roughly 18 days. Validiums keep the proofs but store data elsewhere, which removes Ethereum’s availability guarantee.
Do ZK rollups keep transactions private?
Most do not. Validity proofs provide succinctness and correctness, and the published transaction data stays public. Zero knowledge is a separate property, and privacy-focused chains like Aztec add it on top of the proof system.
How does Ethereum’s L1 zkEVM roadmap affect ZK rollups?
EIP-8025 lets attesters verify execution proofs instead of re-executing blocks, and ePBS in Glamsterdam widens the proving window. Rollups still deploy their own verifier contracts, and a research proposal would expose native proof verification to smart contracts. Glamsterdam has no mainnet date yet.
