The Scaling Stack
How rollups conquered the throughput problem
Optimistic vs ZK, data availability, blobs, sequencers — the full architecture of how Ethereum scales without breaking.
Why L1 hits a wall
The blockchain trilemma frames the fundamental constraint: security, decentralization, scalability — you can optimize for two but not all three simultaneously. Ethereum chose security and decentralization. That choice has consequences measured in dollars per transaction.
In practice, this means every full node processes every transaction. Ethereum runs on 9,000+ nodes globally. The result: ~15 transactions per second, $2–10 for a simple transfer during congestion, and ~12-second block times. Not a bug — the direct arithmetic of running on thousands of independent machines simultaneously.
Why you can't just increase the block size
The naive fix is appealing: bigger blocks, more transactions per block, problem solved. It doesn't work. Larger blocks mean more data every node must download and process on every block. Nodes on slower connections get left behind. Only powerful servers can keep up. Only powerful servers run nodes. Decentralization collapses into a small set of data-center operators — at which point you've built a fast database with worse properties than existing ones.
The historical attempts
State channels (the Lightning Network model) work well for payment channels between fixed parties. They fail for general computation — you can't open a state channel to an AMM you've never interacted with.
Plasma moved execution off-chain and used fraud proofs to L1 — promising in theory, but it collapsed against the data availability problem. If the Plasma operator withholds transaction data, users can't compute fraud proofs. The theoretical exit hatch never worked in practice.
Sharding proposed horizontal splitting of Ethereum's load across parallel chains. Technically sound, but deferred indefinitely in favor of rollups, which arrived faster and proved more practical.
The rollup-centric roadmap
In 2021, Ethereum's core developers formalized a strategic pivot: Ethereum L1 becomes a settlement and data availability layer. Execution moves to L2s. Every subsequent Ethereum upgrade — EIP-4844, the Danksharding roadmap — is designed to make rollups cheaper, not to increase L1 throughput directly. This was a deliberate architectural choice, not a temporary workaround.
The results are visible in the numbers. Ethereum L1 today processes roughly 1 million transactions per day. Arbitrum, Base, OP Mainnet, and zkSync collectively process several million per day — at a fraction of the cost. The scaling happened. It just happened one layer up.
Optimistic rollups
Optimistic rollups execute transactions off-chain, batch them, and post the batch plus a resulting state root to Ethereum L1. "Optimistic" names the core assumption: posted state transitions are valid unless someone proves otherwise. The system doesn't verify every computation — it bets that no one is cheating, and provides a mechanism to catch it if they are.
Fraud proofs
During a 7-day challenge window, any observer can submit a fraud proof demonstrating that a specific transaction was computed incorrectly. If the proof is valid, the state rolls back to the last correct point and the fraudulent sequencer is slashed. If no challenge arrives within 7 days, the state is considered final. The system's security relies on at least one honest, watching participant — a reasonable assumption for any high-value network.
Arbitrum One
Arbitrum uses interactive fraud proofs — a bisection protocol. When challenged, the sequencer and challenger alternate bisecting the disputed transaction until a single instruction is isolated and verified on L1. More complex to implement than single-round proofs, but dramatically more gas-efficient for dispute resolution. Arbitrum One holds roughly $3B in TVL and by most measures is the largest L2 by activity.
OP Stack and the Superchain
The OP Stack, developed by Optimism Foundation and MIT licensed, uses single-round fault proofs — simpler but more expensive to contest. It powers Optimism Mainnet, Coinbase Base, Zora, Mode, and 30+ others. The "Superchain" vision ties these together: all OP Stack chains sharing bridges and governance under a common security model, creating a horizontally scalable family of L2s with interoperability built in.
The 7-day withdrawal and fast bridge workarounds
Withdrawing native ETH from an optimistic rollup back to Ethereum takes 7 days — the fraud proof window must fully expire. The UX solution in practice: third-party bridges like Across and Hop provide fast withdrawals using relayers who front capital and get reimbursed later, once the canonical bridge settles. Users get speed; relayers get a fee; the cryptographic security of the canonical bridge is preserved underneath.
ZK rollups
ZK rollups execute transactions off-chain and generate a zero-knowledge proof — either a ZK-SNARK or ZK-STARK — that mathematically proves the state transition was computed correctly. The proof and resulting state root are posted to L1. The L1 verifier contract checks the proof cryptographically. If valid, the state is immediately final. No challenge window. No 7-day wait.
ZK-SNARKs vs ZK-STARKs
SNARKs (used by zkSync Era, Polygon zkEVM) produce compact proofs — roughly 200 bytes — that verify cheaply on-chain. The trade-off is a trusted setup ceremony: a multi-party computation that generates the cryptographic parameters. If every participant in the ceremony is malicious simultaneously, the setup could be compromised. In practice, large ceremonies with diverse participants make this vanishingly unlikely.
STARKs (StarkWare, StarkNet) produce larger proofs but require no trusted setup and are theoretically quantum-resistant. The verification cost on L1 is higher, but the security assumptions are simpler — just hash functions, not elliptic curve pairings.
zkEVM — proving the EVM
The EVM was not designed with ZK in mind. Proving arbitrary EVM execution in zero knowledge is computationally expensive and technically difficult. Different projects solve this at different levels of fidelity. Full EVM equivalence — Scroll and Linea — runs actual EVM bytecode in the prover, meaning any Ethereum contract deploys identically. EVM compatibility — zkSync Era, Polygon zkEVM — runs a slightly modified VM, which is faster to prove but requires code changes for some contracts. Full equivalence is slower to prove; compatibility is faster but introduces subtle differences that catch developers off guard.
Proving costs and StarkNet's different bet
Generating a ZK proof for a block costs real compute — currently $0.01–0.10 per transaction in prover infrastructure. The cost curve is falling as hardware and software improve. Specialized ZK proving hardware (ASICs) is an active area of development, and the expectation is that proving costs drop by orders of magnitude over the next several years.
StarkNet takes a different approach entirely: Cairo, a custom VM purpose-built for ZK proving efficiency. It is not EVM-compatible at the bytecode level — developers write Cairo or use transpilers. The trade-off pays off in proving performance: Cairo-native code proves dramatically faster than equivalent EVM bytecode. Immutable X, dYdX v4, and many gaming applications have taken this trade, accepting the new programming model in exchange for the throughput.
Data availability
Data availability is the property everyone ignores until it fails. For a rollup to be trustworthy, the underlying transaction data must be publicly accessible. Without it: for optimistic rollups, no one can compute fraud proofs against a dishonest sequencer; for ZK rollups, no one can reconstruct state if the sequencer disappears. A rollup that posts only state roots but withholds data is a black box. This is exactly what killed Plasma.
Ethereum calldata and EIP-4844
Before March 2024, rollups posted transaction data as Ethereum calldata — permanent on-chain, expensive, and during peak congestion the dominant cost driver for L2 fees. EIP-4844 (the "blobs" upgrade) introduced a new transaction type carrying data packages of ~128 KB each. Blobs have three key properties: they use a separate fee market (much cheaper than calldata), they are available for approximately 18 days rather than permanently, and they are cryptographically committed via KZG polynomial commitments so their availability can be verified.
The fee impact was immediate. Arbitrum fees fell from ~$0.15 to ~$0.01 per transaction. Base dropped from $0.20 to $0.001. EIP-4844 is the single most impactful L2 cost reduction in Ethereum's history.
Danksharding — the endgame
The full Danksharding roadmap scales blobs from the current ~3–6 per block to hundreds per block. The enabling technology is data availability sampling: light clients randomly sample small chunks of blobs to probabilistically verify availability without downloading everything. If enough random samples are available, the full dataset is almost certainly available. This is what makes Ethereum a credible global DA layer at scale — not storing everything, but making it statistically impossible to hide missing data.
Alternative DA layers
Celestia is a purpose-built modular DA layer built on Cosmos. It ships data availability sampling at launch — not just planned. Rollups post data to Celestia nodes at roughly 1/10th the cost of Ethereum blobs. The trade-off: ~100 validators versus Ethereum's 9,000+. Different security assumptions, meaningful but not equivalent.
EigenDA is built on EigenLayer. EigenLayer restakers opt in to store DA data, with slashing conditions if they fail. Security is inherited from restaked ETH. AltLayer and many Orbit chains use EigenDA. Current target is 10 MB/s throughput, with a roadmap to 1 GB/s.
Sequencers and decentralization
The sequencer is the performance engine of every rollup. It receives user transactions, determines their order, executes them, batches them, and posts to L1. It is also, currently, the centralization bottleneck of every major L2 in production.
Who runs them
Offchain Labs runs Arbitrum's sequencer. The Optimism Foundation runs OP Mainnet's. Coinbase runs Base's. Sky Mavis runs Ronin's. Every major L2 has a single, centralized sequencer — operated by the same entity that built the chain. This is not a temporary state of affairs that was accidentally overlooked. It was the pragmatic choice: decentralized sequencing is hard, and shipping a working rollup was more urgent than decentralizing it immediately.
The risks of centralized sequencing
Downtime. A centralized sequencer can go offline. This has happened — both Arbitrum and OP Mainnet have experienced sequencer outages that halted the chain until the operator restarted. The L1 contracts are fine; transactions just stop processing.
MEV extraction. The sequencer controls transaction ordering. That control is worth money — it can frontrun users, insert its own transactions, and extract value that would otherwise go to searchers competing in a fair mempool.
Censorship. The sequencer can ignore specific addresses. It cannot steal funds — L1 is the ultimate arbiter — but it can delay exits and selectively exclude users. The crucial distinction: a hostile sequencer can harm you, but it cannot steal from you, because the L1 contract enforces the rules.
Force inclusion: the safety hatch
If the L2 sequencer ignores your transaction, you can submit it directly to the L1 rollup contract and force its inclusion. Arbitrum has a 24-hour delay on force inclusion — you wait a day, but your transaction goes through regardless of what the sequencer wants. This guarantees exit rights even against a hostile operator. The "users can always leave" property is what separates a rollup from a sidechain.
Decentralized sequencing — the roadmap
PoS-based selection applies Ethereum-style validator mechanics to the sequencer role — stake tokens, get randomly selected to sequence, get slashed for misbehavior. Most L2s have described this approach. None have shipped it in production.
Shared sequencer networks — Espresso Systems and Astria being the leading projects — let multiple rollups plug into a common sequencing layer. The benefit goes beyond decentralization: shared sequencing enables cross-rollup atomicity. If Arbitrum and Base share a sequencer, you can atomically swap tokens across both chains — the sequencer guarantees both legs happen or neither does. This eliminates bridge risk for cross-rollup operations. No major deployment in production as of mid-2024.
Based rollups take the most radical approach: L1 validators sequence L2 transactions directly. No separate L2 sequencer at all. Taiko is the main implementation. Inherits L1 decentralization and censorship resistance immediately, without any additional infrastructure. The trade-off: L2 throughput is gated by L1 block time. You cannot sequence faster than L1 produces blocks.