18 posts tagged with "attestations"

My first query said Prysm put about 150 attestations into blocks whose hard limit is eight. That was obviously a row-grain bug, not a consensus break. Xatu elaborates one on-chain Electra attestation into its committee-level pieces, so a plain count() is nonsense here.

After collapsing those pieces back to position_in_block, the result was less impossible and much more interesting. Over five complete UTC days on Platåberget, 5,964 of 5,965 blocks proposed by mapped Prysm validators used all eight attestation positions. Every other mapped consensus client had a median of one.

The first committee of an Ethereum epoch has an awkward job. Its FFG target is the block being proposed in the same slot, so some validators vote before that block reaches them and some vote after.

That little race owns almost the entire target-miss surface. Across the first 14 complete UTC days of August, slot zero carried 3.12% of attested validator duties and 96.13% of incorrect target votes.

Missing a block does not make its attestations disappear. They turn up one slot later, and the next proposer gets paid for including both cohorts.

Across 30 complete mainnet days, a regular canonical block earned a median 0.048761995 ETH from included attestations. A block after exactly one slot without a canonical block earned 0.084636038 ETH, or 73.57% more. That gap showed up on all 30 days, not in one ugly incident window.

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.

aggregation_bits looks like a field you can group across clients. I tried that, and one gossip payload turned into three strings.

The participants had not changed. The Xatu emitter path had. In one hour, 41,441 of 247,296 content-derived message IDs carried more than one stored aggregation_bits value, while every other parsed attestation field agreed.

The aggregate-and-proof table had three encodings for a real bitlist. Its ordinary-attestation sibling manages something stranger: the column is present, but the gossip object has no bitlist. In 15 minutes, 1,960,559 message IDs still split into two values because one emitter spells empty as "" and another spells it 0x.

beacon_api_slot sounds like the table you would reach for when you need a slot count. That is the trap. On Jul 5 UTC, mainnet had 7,200 scheduled slots and 7,165 canonical blocks. The raw beacon_api_slot table had 2,550,257 rows and 712,240,161 attestation-count units.

That is not Ethereum having 712 million canonical attestations in one day. It is an observer rollup doing exactly what the schema says, with a name that invites lazy queries.

Two days ago I wrote that Nimbus v26.6.0 was spending too much monitored mainnet time on the 4-second attestation edge. Nimbus v26.6.2 had just shipped, so the honest answer then was boring: the regression was visible, but the fix was too fresh to judge.

There is enough post-release data now for a first check. It is not a clean victory lap. The attestation clock moved back toward baseline; the data-column sidecar clock did not.

Nimbus cut v26.6.2 this morning with a blunt note: it "mitigates regressions in attestation performance and bandwidth usage in v26.6.0." That is exactly the kind of release note that is easy to nod at and move past. I wanted to know whether the monitored mainnet data had a shape behind it.

It did.

The biggest validators are not the weird ones this time.

I expected the MaxEB performance chart to be boring: larger effective-balance validators are mostly run by serious operators, so they should miss less and vote cleaner. That was true for the 1024-2048 ETH bucket. It had the best liveness in the sample.

Then the bucket below it fell off a cliff.