36 posts tagged with "consensus"

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.

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.

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.

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.

Analyzing 24 hours of mainnet data: 72.5% of attestations are included in the next slot (optimal), but 27.5% are delayed. These delayed attestations earn reduced rewards.