4 posts tagged with "timing-game"

Correction, 2026-08-13: The timing cliff in this post still reproduces, but the headline orphan total and both February "network split" sections were wrong. A non-GLOBAL join across distributed ClickHouse tables dropped canonical matches and mislabelled ordinary slots as orphans. Corrected peaks are 0.67% for both February windows, not 63% and 78%, and the corrected 30-day total is 390 unique orphan block roots, not 1,783. I retract the parallel-chain, self-healing-fork, entity-wide-incident, and 58%-of-month claims. The full correction reproduces the model bug and cross-checks finality.

Ethereum's block orphan rate should be nearly zero. It isn't — and the reasons why are more interesting than the number itself.

Over the last 30 days, 1,783 blocks were proposed on mainnet and then lost. Not missed (nobody tried), not reverted (execution failed) — proposed, gossiped, and then quietly discarded when another block won the fork choice. That's 59 blocks per day that disappeared into the void.

Most of them arrived on time.

Correction, 2026-08-13: I grouped a per-observer timing table into 200ms buckets, ran count(), and called the result slots. The old histogram therefore counted 7,438,781 observer rows, roughly 148 rows per corrected block, even though only 50,400 slots physically fit in the seven-day window. Rebuilding from exact canonical block roots at one-block-per-slot grain gives 32,694 / 11,502 / 6,006 blocks in Waves 1/2/3. The three waves and the Wave 2 versus Wave 3 accuracy cliff survive; the old y-axis, ~73,000-slot claim, 10,945 Wave 2 count, and 28× penalty ratio do not. Full correction and queries.

When a validator is chosen to propose a block, it has a choice: publish the moment the block is ready, or wait for MEV-Boost bids to arrive and raise the payout. Most discussions frame this as a binary — you either participate in the timing game or you don't.

The data says it's more complicated. There are three distinct groups, and the middle one has mostly gone unnoticed.

Every proposer using MEV-Boost faces the same tradeoff: wait longer to capture more value, but at some point your block arrives too late for attesters to see it before they commit their vote. The timing game is well-understood in theory. What hasn't been measured is exactly where the cliff is — and how steep the drop really is.

The cliff is at 3.0 seconds. What happens after it is sharper than you'd expect.

There's a 3-second cliff in Ethereum's attestation system. Blocks that arrive after it — when validators have already started forming their head votes — cause measurable drops in head accuracy. The earlier post established that with 50,000 slots of data.

What it didn't answer: who's responsible?