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.
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.
The libp2p control tables had one of those numbers that looks fake enough to be interesting: 3.23 billion PRUNE rows on June 25, from the mainnet Gossipsub sample. If you read that as "three billion peers got pruned", the table is lying to you.
It is not a peer count. It is not a rejected-message count. It is a control-plane row surface, and on that day it expanded much faster than the observed peer set did.
Clarification, 2026-07-18: Even the
validation failedbucket is an observer-time result, not an intrinsic label on the message. A later exact-ID check found three data-column messages that had been delivered near slot time, then appeared asvalidation failed11–15 minutes later. The follow-up has the matched delivery, duplicate and sidecar rows.
libp2p_reject_message sounds accusatory. It looks like the table you would count if you wanted bad gossip, invalid messages, or peers doing something wrong.
That is almost exactly how to overread it. In the seven complete UTC days from Jun 28 through Jul 4, the table had 31,027,943 mainnet rows. Only 247 of them were reason = 'validation failed'.
IDONTWANT sounds like the clean negative image of IWANT: one peer asks for a message, another says please do not send it. The row counts even make that story tempting. On July 1 UTC, Xatu's mainnet libp2p sample had 56.2M IWANT rows and 48.8M IDONTWANT rows.
That neat story breaks as soon as you dedupe the message IDs.
libp2p_rpc_meta_control_ihave is a beautiful foot-gun. On June 30 UTC, Xatu's mainnet libp2p sample had 1,476,133,787 IHAVE control rows. That was not 1.5 billion blocks, attestations, or delivered gossip messages. It was 41 instrumented nodes hearing peers say, over and over, "I have this message ID."