Design a Layer-2 Rollup for Ethereum

Problem statement

Design a layer-2 (L2) rollup for Ethereum: a system that executes transactions off-chain at high throughput, then commits to Ethereum (L1) only a compressed record of the data needed for anyone to reconstruct and verify L2 state. The product must accept user transactions, order and execute them, publish data availability (DA) to L1, post state commitments, prove or defend those commitments, and let users move assets in and out without trusting the L2 operator.

Ethereum's base layer settles roughly 1.0-1.5 million transactions per day at 12-second slots, i.e. on the order of 12-17 TPS, bounded by a block gas limit that the ecosystem raised toward 36 million gas during 2025. A rollup's job is to multiply that throughput by one to two orders of magnitude while inheriting L1's security for availability and, ultimately, for correctness.

Why the problem is distinctive

A conventional backend retries a failed write. A rollup cannot retry history: every commitment posted to L1 is immutable, and every user must be able to independently recompute L2 state from L1 data alone. The design therefore separates four planes with different trust assumptions:

1. Execution plane: the sequencer and L2 execution engine that produce blocks and soft confirmations in seconds.
2. Data-availability and settlement plane: batches, blobs (EIP-4844), and inbox messages written to L1, which define the canonical transaction order.
3. Proof plane: either validity proofs (zk) that certify state transitions, or a fraud-proof game (optimistic) that lets anyone challenge a bad commitment within a window.
4. Bridging plane: the canonical bridge contracts that lock, mint, burn, and release assets, plus fast-exit liquidity layers.

The invariant that separates a rollup from a sidechain: correctness and availability are checkable from L1. If the sequencer vanishes, users can still force transactions through the L1 inbox and still exit with their funds. If the prover vanishes, an optimistic rollup remains secure because any honest validator can challenge; a zk rollup degrades to delayed withdrawals, not lost funds.

Public operating baseline versus design assumptions

Public evidence makes the category concrete. EIP-4844 (Dencun, March 2024) introduced 128 KiB blobs at 3 target / 6 max per block; EIP-7691 (Pectra, May 2025) raised this to 6 target / 9 max; Fusaka (December 2025) shipped PeerDAS (EIP-7594) so blob-parameter-only upgrades can push capacity further. Arbitrum One (August 2021, Nitro in 2022, BoLD permissionless fraud proofs in 2025), OP Mainnet and Base (OP Stack, Bedrock 2023, permissionless Cannon fault proofs on OP Mainnet in June 2025), Starknet and StarkEx (STARKs, SHARP recursive proving), and zkSync Era (EraVM, SNARK-based validity proofs) are all production instances of this design space. L2BEAT's Stage 0/1/2 framework remains the public yardstick for how much of that security is actually enforced by code rather than by committees.

Unless a number is tied to such a public fact, it is an explicit design assumption of this answer, stated in sec-003 and reused consistently: 2,000 TPS sustained L2 load, 45-byte average compressed transaction, 60-second batch cadence, a 2-blob-per-12s DA budget, and a 7-day optimistic challenge window with a zk one-step backstop.

The four architectural planes as an interview map

Keep the planes separate in your answer. The execution plane is a latency problem (sub-second soft confirmations). The DA plane is a cost and durability problem (bytes on L1 are the scarcest resource in the system). The proof plane is a compute and soundness problem (GPU farms, recursion, or dispute games). The bridging plane is a correctness and liquidity problem (withdrawal proofs, fast exits, reorg safety). Most weak answers collapse all four into one box labelled 'the rollup' and then cannot answer what happens when the prover stalls or the sequencer censors.