Design Layer 2 Scaling

Problem Statement: Layer-2 Rollup Scaling

A Layer-2 rollup scales Ethereum by executing transactions off-chain but settling their data and validity on-chain — you run a high-throughput chain that periodically posts its compressed transaction data and a state commitment back to Ethereum (L1), inheriting L1's security for ordering and data availability while escaping its ~15 TPS and high fees. The design splits into four moving parts: a sequencer (orders and executes L2 transactions), a batcher (compresses and posts data to L1), a prover/proposer (commits state roots and, for ZK, proves them), and a bridge (moves assets between L1 and L2).

The scale to anchor: ~2,000–5,000 sustained L2 TPS, a batch posted to L1 every 1–2 seconds, and ~200–400 bytes per compressed transaction — compression is what makes L2 cheap, because L1 data is the dominant cost. Real production systems: Arbitrum and Optimism/OP Stack (optimistic), zkSync, Starknet, Polygon zkEVM (validity/ZK).

The concept an interviewer most wants you to nail is the two finalities. A user gets a soft confirmation in ~1–2s when the sequencer signs their transaction — fast, but it is only the sequencer's promise. Hard finality comes later: after the batch lands on L1 and (for optimistic rollups) the 7-day challenge window elapses, or (for ZK) a validity proof is verified on L1, which can be sub-hour when the prover is healthy. Confusing L2 block time with Ethereum finality is the single most common mistake, and it is exactly what makes withdrawals slow even though L2 feels instant.

The failure stories that define this problem are L2-specific: a bridge exploit draining escrow (the bridge holds all locked funds and is the prime target — most large crypto hacks have been bridge hacks), a sequencer censoring or stalling withdrawals, a data-availability outage blocking batch posts, and a prover backlog delaying ZK exits. These, not a generic microservices diagram, are what the role is really testing.