The chain didn't lie. It just didn't say anything.
Last week, I ran a stress test on a popular zk-rollup testnet. I sent zero transactions across 12 hours. The sequencer still produced blocks. Each block, timestamped, committed to the L1, with a batch of zero proofs. The gas cost? Non-zero. The L1 data availability cost? Still paid in ETH. The chain kept ticking, but it was breathing vacuum.
Empty blocks are not a bug. They are a feature of centralized sequencing. And they reveal a deeper rot in the Layer 2 scaling narrative.
Context: The Sequencer's Monopoly on Time
Every Layer 2 runs on a sequencer — a single entity that orders transactions. In optimistic rollups, the sequencer batches transactions, posts them to L1, and waits for a challenge window. In zk-rollups, it generates proofs. The sequencer decides what goes into a block. It also decides what doesn't.
When the mempool is empty, the sequencer can either wait or produce an empty block. Most sequencers produce empty blocks on a fixed cadence — every few seconds, regardless of activity. This is designed for liveness: the chain must appear alive even if no one is using it. But the cost is real. Each empty block burns L1 gas, inflates the state (by adding a block header), and creates a false signal of network health.
In my test, the sequencer produced 4,320 empty blocks over 12 hours. L1 calldata cost: 0.03 ETH — roughly $60 at current prices. For a testnet. Imagine mainnet with 100 active rollups, each producing empty blocks every 2 seconds. That's $600,000 per day in wasted L1 fees. The chain didn't lie. It just bled.
Core: Code-Level Analysis of Sequencer Logic
I pulled the sequencer source code from a major optimistic rollup implementation. The block production loop looks like this (simplified):
while true:
tx = mempool.pop()
if tx is None:
if time_since_last_block > MAX_BLOCK_INTERVAL:
produce_empty_block()
else:
sleep(POLL_INTERVAL)
else:
produce_block_with_tx(tx)MAX_BLOCK_INTERVAL is typically set to 2-5 seconds. The rationale: ensure the chain appears responsive. But this logic conflates liveness with throughput. A chain that produces empty blocks is live, but it is not useful. The sequencer is paying for a heartbeat that nobody asked for.
More critically, the empty block production rate is a function of sequencer configuration, not protocol constraints. The sequencer operator can change MAX_BLOCK_INTERVAL arbitrarily. If they set it to 0, the chain will produce blocks as fast as hardware allows — flooding L1 with empty batches. If they set it to 1 hour, the chain appears dead. This is a centralized parameter that affects user experience, cost, and even security (faster empty blocks mean more L1 data, but also more frequent state roots, which can reduce fraud proof windows).
In zk-rollups, empty blocks are even worse. The prover must generate a proof of correct execution for an empty block. That proof is computationally cheap (just a few gates), but the circuit still has to verify the absence of transactions. This adds latency to the prover pipeline. In one implementation I profiled, empty block proofs took 30% of the time that normal block proofs took — because the circuit setup overhead is fixed. The prover spends 30% of its capacity proving nothing.
Contrarian: Empty Blocks Are a Feature, Not a Bug — But for the Wrong Reasons
Most engineers defend empty blocks as necessary for liveness. They argue that a chain that stops producing blocks when idle is indistinguishable from a dead chain. Users might think the sequencer is down. So empty blocks maintain trust.
I call this the “fear of silence” argument. It is built on the assumption that users are watching block timestamps, not transaction finality. In reality, users care about whether their transactions are included, not whether the block explorer shows a new block every 2 seconds. The entire justification is a UX crutch for a centralized design.
Consider a decentralized sequencer pool. If multiple sequencers can produce blocks, empty blocks become a game-theoretic problem. Each sequencer wants to claim the next block reward. If they all produce empty blocks simultaneously, the network wastes resources. Coordination mechanisms (like leader election) are needed. But current Layer 2 designs avoid this problem entirely by using a single sequencer. Empty blocks are a symptom of that centralization.
Here is the blind spot: empty blocks inflate the state growth of the L2. Every new block adds a header, a state root, and a proof commitment. Over a year, with 2-second blocks, that's 15.7 million headers. For a chain that processes 10 transactions per second, the state grows by 70% more than necessary. This is not sustainable for light clients or full nodes.
Takeaway: The Sequencer Will Eventually Have to Choose Between Silence and Waste
Empty blocks are not a bug. They are a feature you didn't ask for — a tax on centralized sequencing. The real fix is not to increase block interval or to batch empty blocks. The fix is to move to a sequencing model where the decision to produce a block is driven by demand, not by a timer. That means mempool-driven block production, with a fallback mechanism for liveness.
Some projects are experimenting with “demand-based sequencing” — the sequencer only produces a block when the mempool contains at least one transaction, with a maximum timeout of, say, 1 minute. But this introduces latency variance. Users don't know if their transaction will be included in 1 second or 60 seconds. For DeFi, that's unacceptable.
The deeper question: why do we need a sequencer at all? If the rollup's state can be updated by anyone who posts a batch to L1 (as in the original rollup design), then empty blocks disappear. But that requires a permissionless batch submission mechanism, which most current rollups lack. The chain didn't lie. It told us the sequencer is a bottleneck. We just didn't want to hear it.