14 posts tagged with "correction"

I got one sentence wrong in the post I published earlier today. I wrote that a CoinTool XEN refund did not make its block cheaper because EIP-7778 already kept block gas accounting before refunds. EIP-7778 is scheduled for Glamsterdam, but it is not active on mainnet. Under today's rules, a refund lowers both the user's receipt gas and the gas counted in the block.

Adding the refund back changes the block story quite a lot. In the same 14 complete UTC days, at least 2,405 of 100,388 canonical blocks carried more gas before refunds than their historical gas limit. The worst reached a lower-bound 72.94 million gas against a 60 million limit.

Ethereum's move from a 45 million to 60 million gas limit looked like a coordinated step from a distance. At block grain it was a fight. Across the 7,866 canonical blocks in the network-level ramp, 3,958 took the maximum legal step up and 3,714 took the maximum legal step down.

That is 97.5% of blocks pulling the limit as hard as the protocol allowed, one way or the other.

In February I described Ethereum's block timestamps as a tight but noisy clock: 12.05 seconds on average, with 0.38% of blocks supposedly arriving more than 14 seconds after the previous one. That was the wrong clock. Execution payload timestamps are protocol slot time, so consecutive canonical blocks in the fixed seven-day reconstruction are either 12 seconds apart or, when one slot has no canonical block, 24 seconds apart.

The embarrassing bit is that the old 0.38% was close to a real number. It just measured empty-slot cadence, not late block arrival.

In March I wrote that Ethereum lost finality for roughly two and a half hours. It did not. The query behind that post mislabelled ordinary canonical blocks as orphans because a non-GLOBAL join ran against distributed ClickHouse tables.

The corrected March 2 peak is 0.33% orphaning, not 68.5%. Minimum canonical attestation participation was 99.10%, not 0%. The finalized checkpoint stayed exactly two epochs behind throughout the claimed incident, which is normal.

In February I published a chart with 7.4 million observations and called them slots. Ethereum produced 50,400 scheduled slots in that seven-day window, so that should have stopped me cold. It didn't.

The three arrival waves are real. The denominator on the original histogram was not.

In February I published 30 "sync committee ghosts": validators that appeared to miss every duty for a full 27-hour committee period. The result looked clean. The SQL was not.

ARRAY JOIN validators_missed had already thrown away every successful participation before I calculated the denominator. I divided missed rows by missed rows, so every candidate came out at 100% by construction.

I went back to March's zombie-state post because its biggest number had started to smell wrong. Forty-one million XEN storage slots supposedly woke up in three days, then almost nothing. That was not an Ethereum event. It was a model backfill that I mistook for block time.

The corrected 55-day count is 3,833,522 reactivation rows, not 97,466,839. XEN accounts for 2,142,144, not 48,302,239. The alleged Dec 20-22 spike is 225,421 XEN rows, not 41,816,729.

validation failed sounds like a verdict on the bytes. It is not that clean.

Across 668 PeerDAS data-column rows carrying that libp2p reason, three exact message IDs had already been delivered near slot time. Other observers logged them as duplicates, then one observer rejected the same ID 11 to 15 minutes later.

I called hundreds of thousands of engine_getBlobsV2 rows proof that some execution-client builds did not support the method. That was too clean. UNSUPPORTED was a label added by the collector, not a status returned by the execution client.

This corrects both The Blob Blindspot and engine_getBlobsV2 is still fragmented. The counts in those posts were real counts of rows carrying that label. The interpretation was wrong.

I called 38.6% of Ethereum gas a permanent-storage bill in February. That sentence was wrong. The table was a research allocation model, not a meter attached to physical state growth, and a quarter of the SSTORE gas it put in state_growth came from transactions that added no net-new storage slot at all.