A fresh Gloas spec change sent me looking for an ugly sanity check: do observed peer subscriptions line up with custody metadata? The obvious raw table answered before I had joined anything. One stored peer_id_unique_key owned almost exactly half the rows across every observer. Gloas is not live on mainnet; it just gave me a reason to inspect current mainnet capture.
That peer does not exist.
Ethereum has a five-month block-history rule. It does not have one five-month history clock.
A new draft EIP-8383 proposes cutting the minimum block-serving range from 33,024 epochs to 8,192, or from 146.8 days to 36.4 days at today's 12-second slots. I expected the current five-month boundary to roll forward with the chain. For most Lighthouse and Prysm peers in Xatu, it did not move at all.
PUBLISH_MESSAGE sounds like proof that a message went onto the wire. It is not. Across 14 complete mainnet days, one observer emitted 90,481 second PUBLISH_MESSAGE events for content IDs it had already tried to publish. Every repeated ID appeared exactly twice.
Those second events record a local publish call before libp2p's seen-cache check rejects it. They are not network retransmissions.
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.
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.
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.
At 09:15 UTC on July 11, one Tysm observer-peer pair logged 80,749 outbound Gossipsub DropRPC events in 60 seconds. PRUNE controls appeared in 80,164 of those parent RPCs, producing 146,218 child rows across five (fork digest, topic name, encoding) tuples and no peer-exchange entries. Those child rows were not 146,218 peers leaving Ethereum.
Yesterday's heartbeat post left an uncomfortable question. The live connections were old, but were the peers on the other end actually keeping up? Mostly, yes.
At 12:00 UTC on July 10, 93.76% of matched observer-peer pairs reported the same head slot. Another 205 live pairs, covering 145 remote peer keys, answered from more than 7,200 slots behind. The median lag inside that tail was 116,439 slots, or 16.2 days.