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.
Xatu v1.22 added an archive for raw Gossipsub wire bytes. The table uses content-derived message IDs and a replacing merge tree, so it sounds safe to treat count() as a unique-message count.
It is not. In a two-hour mainnet window, 35,806 of 197,889 aggregate-and-proof message IDs survived twice. The second row appeared when the same content ID crossed a 12-second wallclock-slot boundary.
Arrival time has been my stand-in for PeerDAS bandwidth. It sort of worked, but it was still a timing proxy. A process-level counter now exposes bytes by port, so I expected a clean rising curve with blob count.
That curve exists. It is not remotely uniform.
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.
Mostly empty blobs compress beautifully. PeerDAS's recovery half does not.
Xatu started preserving raw Gossipsub message payloads this morning. In the first two complete hours, I found 448 canonical blob blocks with all 128 column sidecars captured. For the 97 blocks below 25% blob fill, columns 64–127 used 4.42 times as many compressed payload bytes as columns 0–63. The same ratio was only 1.02x for blocks above 75% fill.
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.
A libp2p connection can stay up while one of its Gossipsub mesh links is torn down two seconds after it is added. On July 15, the row-weighted median between a Tysm observer logging GRAFT and then PRUNE for the same peer and topic was 1.824 seconds.
One beacon_api_eth_v3_validator_block observer made Ethereum payloads look four times larger than they were.
In a two-hour mainnet sample, 161 prepared blocks from that path matched the canonical execution payload for their slot. The prepared-block rows reported 213,035 transaction entries. The matching canonical blocks contained 51,254 transactions: a 4.156x multiplier.
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.