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.
In December 2025, Ethereum's Fulu upgrade raised the blob cap from 6 to 15, then to 21 in January. That's a 3.5× increase in the data availability space available to rollups per block — the single biggest capacity jump since EIP-4844 launched blobs in March 2024.
Three months later, not a single major rollup has used more than 6 blobs in a single transaction.
Ethereum's base fee is so low right now — bouncing between 0.025 and 0.97 gwei — that something unexpected has emerged in the mempool: a class of transactions that aren't too cheap to ever be included. They're just cheap enough to wait.
At 0.027 gwei, the median time to inclusion is 2.6 hours. At 0.030 gwei, it's 57 seconds. Three thousandths of a gwei separate an hour of waiting from near-instant inclusion — and whether you wait depends almost entirely on what time UTC it is when you submitted.
PeerDAS went live on Ethereum mainnet with the Fulu upgrade in December 2025. Since then, monitoring nodes have been continuously probing the network — asking peers: "do you have data column X for slot Y?" Over the past seven days, those probes generated 92.5 million responses. And 2.4 million of them came back empty.
Most of that emptiness isn't random. It's concentrated in a specific class of node.
Every 6.4 minutes, Ethereum's consensus clients have a problem. At the boundary between epochs, they need to do expensive work — update validator balances, compute committee assignments, tick the justification/finalization machinery. While they're doing it, the network doesn't stop. Blocks keep arriving. Attesters keep committing to what they see.
What happens to validators whose client is still mid-computation when the attestation window opens? They vote for the wrong head.
On May 7, 2025, Ethereum's Pectra upgrade (fork name: Electra) activated EIP-7251 — the Maximum Effective Balance change. The idea was to let validators hold up to 2,048 ETH each, unlocking two things: compounding rewards for validators who opt in, and simpler operations for large stakers who no longer need to manage thousands of 32-ETH keys.
Most coverage focused on the compounding angle. The real story turned out to be something else.
In the nine months since Pectra, Ethereum's active validator set has shrunk by 110,007 validators — from 1,068,860 to 958,853. Meanwhile, 3,055 mega-validators holding more than 1,024 ETH each have emerged from essentially nowhere.
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 27 hours, Ethereum rotates its sync committee — a randomly selected group of 512 validators who sign every block header during their term. Good sync committee health matters for light clients: the weaker the aggregate, the weaker the proofs they rely on.
Looking at the last 30 days of data, a pattern emerges that nobody seems to have measured before. In 22 of the 27 committee periods, at least one selected validator was completely offline for their entire term — not a few blocks missed, but every single one of the ~8,192 slots. Dead weight drawn by lottery.
Buried in the USDT contract source code is a comment that reads: "additional variables for use if transaction fees ever became necessary." Beneath it: basisPointsRate = 0 and maximumFee = 0. Both initialized to zero. Never changed. The fee mechanism was coded in 2017 in case Tether ever wanted to charge for transfers. They never did.
But the code that reads those variables runs on every USDT transfer. And USDT transfers happen in virtually every Ethereum block.
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.