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.

Correction, 2026-08-12: The query below expands only validators_missed, so its denominator contains missed rows and nothing else. That makes every returned miss_rate equal 100% by construction. A corrected pass over 25 complete committee periods found 17 selected validators with no participation in any recorded canonical sync aggregate, across 13 periods. The early-index skew survived, but the published count of 30 complete ghosts across 22 of 27 periods was wrong, and one of the corrected 17 had already exited before its period began. The full correction reproduces the bug and rebuilds the denominator from both participation arrays. The original text remains below.

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_reads is 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_bytes as "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.

Ethereum's block gas limit doubled in 2025. Not through a hard fork. Not through a governance vote. Through three coordinated waves of validators updating their configuration files.

The limit went from 30 million to 60 million gas—a 100% increase in block capacity—between February and November 2025. Each wave moved faster than the last. The final surge, from 45M to 60M, took just 22 hours.

Ethereum had 660 chain reorganizations in the last 30 days. That's a 0.31% reorg rate across roughly 216,000 slots — normal background noise for a live PoS network.

But here's something nobody talks about: if you ask Lighthouse how deep those reorgs were, you'll get a completely different answer than if you ask Prysm. Same event. Same block hashes. Different depth. Every single time.

One validator missing an attestation isn't a crisis. A few hundred validators missing 1 in 8 attestations, every slot, for three months straight — that's a different story. And it's concentrated in a way that the aggregate participation numbers don't show.

The xatu dataset tracks missed attestations at the entity level. When you sort by miss rate, a clear hierarchy emerges — and a handful of operators sit far outside the expected range.

There's a counterintuitive pattern buried in Ethereum's block-building data: the most valuable blocks — the ones where MEV extractors collect the most ETH — consistently contain fewer transactions than ordinary blocks.

Not slightly fewer. Significantly fewer.

A block worth 0.2–1 ETH in MEV carries, on average, 185 transactions. A normal low-MEV block carries 293. That's 108 fewer transactions — a 37% drop from peak — in a block that everyone in the market fought hardest to produce.