Every blob you add to a block makes it slightly harder for validators to attest to it on time. This isn't a theoretical concern — it shows up in the data today, at the current limit of 6 blobs per block. When Fulu raises that limit, the cost scales with it.
The mechanism is straightforward. The cost of getting it wrong is less obvious.
Every attestation Ethereum's 960,000-odd validators cast has a clock on it. The slot it belongs to ticks past, and then proposers have up to 32 slots to pick it up and include it in a block. Include it in the very next slot and the attester earns a full reward. Wait two slots and the head-vote component — about three-sevenths of the total attestation reward — is already gone.
Most people assume this is a solved problem. Look at the median inclusion delay and you'd agree: it sits at roughly 1.001 slots and barely moves. The typical attestation is included almost immediately.
The median isn't the story.
Ethereum has five execution clients and six consensus clients. Everyone has opinions about which is fastest — but almost nobody talks about what they do to your disk.
The short answer: your choice of client stack determines whether your SSD lasts four years or forty.
Ethereum block execution isn't a fixed-cost operation. For small blocks the state LRU cache handles nearly everything. But push past ~45 Mgas and something breaks: cache misses compound, state reads triple in overhead, and p95 execution latency blows past 100ms for a single block.
Nobody talks about this because mgas/s benchmarks measure throughput — not the hidden cost of cold cache reads. The gas limit doubling from 30M to 60M made this matter.
Every 12 seconds, your execution client gets a new block and has to tell the consensus layer: valid or not. The call is engine_newPayload, and how long it takes determines how fast your validator can attest to the new head.
That window matters. A faster EL client means earlier head votes, better attestation accuracy, and more flexibility in how you run your validator. The timing game, MEV extraction, and late block handling all happen inside this gap.
So which execution client is fastest? The data is messier than the win-rate leaderboards suggest.
When people talk about the Ethereum Virtual Machine, they reach for the "world computer" metaphor — a globally shared processor executing smart contract code. That framing implies computation: arithmetic, cryptography, logic. In practice, the EVM spends more than half its gas budget on something far more mundane: reading and writing persistent state.
Every week, roughly 1,440 gigagas of EVM execution passes through the mainnet. More than half — 56.7% — goes to exactly two opcodes.
I started this looking for evidence that high-MEV blocks are harder for execution clients to process. The intuition is obvious: MEV blocks are full of complex DeFi interactions, sandwich attacks, arbitrage — all the state-thrashing stuff. Surely they're heavier to execute.
They're not. The correlation between MEV block value and newPayload execution time is r = −0.004. Essentially random noise.
What actually predicts execution latency is simpler and more boring: how much gas the block used.
Analyzing 52,104 blocks over 7 days: mean interval is 12.05s, median is 12s. Only 0.38% of blocks are delayed beyond 12 seconds. The network maintains remarkably tight timing.