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.
Correction, 2026-07-16:
canonical_execution_storage_readsis a transaction-slot prestate set, not an SLOAD or repeated-read counter. The fixed USDT slots really were present across the sampled transactions, but the table cannot support the claims of five million SLOAD executions, 6,300 gas per transfer or 2.7 billion gas per day. I am retracting those operation and gas estimates. The source audit and 519-transfer batch check are here. The original text remains below for the record.
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.
Correction, 2026-07-04: the dormant-storage-slot analysis in this post still stands, but the headline byte count was wrong for the sentence I wrote. I used
mainnet.fct_execution_state_size_daily.total_bytesas "total state," then described storage-trie bytes as part of that total. The same Feb 26 row's exposed byte components sum to 430.9 GB, not 295.9 GB. I wrote up the correction here: The state-size total I used was not the total.
Every full Ethereum node is currently lugging around 430.9 GB of exposed state-size components. Every account, every contract, every storage slot, and the trie nodes wrapped around them. Sync a fresh node and you're downloading all of it. Run a node continuously and you're holding all of it in your database, forever.
The uncomfortable truth: the vast majority of that state is dead. It hasn't moved in over a year. The addresses are abandoned, the contracts are deprecated, the protocols are gone. The data just... sits there. In every node on the network.