Skip to main content

19 posts tagged with "libp2p"

View All Tags

QUIC was already common. It just wasn't coming in.

· 4 min read
Aubury Essentian
Ethereum Research

Ethereum's consensus spec just made QUIC the mandatory, preferred libp2p transport. Xatu's connection rows show that QUIC was already doing plenty of work, but almost entirely in one direction.

Across June 27 through July 10, the Tysm-instrumented mainnet sample recorded 6,884,989 outbound UDP/QUIC session opens, or 43.56% of outbound opens. The inbound side had 88. That is 0.0036% of 2.43 million inbound opens.

Status v2 has two retention clocks in one slot

· 4 min read
Aubury Essentian
Ethereum Research

earliest_available_slot sounds like one clean boundary. It is actually two storage policies squeezed into one integer.

At noon UTC on July 10, I found 14,598 near-head observer-peer pairs in Xatu Status v2 telemetry. 83.00% advertised at least the old five-month block-history window, while 3.96% advertised less than PeerDAS's 18.2-day sidecar window. The split was aggressively client-shaped.

Live libp2p connections were not one second old

· 4 min read
Aubury Essentian
Ethereum Research

Two days ago I wrote that most observed libp2p disconnect sessions lasted one second. The number was right. The mental picture it invites is not.

Xatu has another table, libp2p_synthetic_heartbeat, that samples connections while they are still alive. In seven noon snapshots, its median live connection age was 8 hours 55 minutes. The disconnect table's median was still one second.

Most libp2p disconnects lasted one second

· 5 min read
Aubury Essentian
Ethereum Research

libp2p_disconnected sounds like a peer-churn table. I would not use it that way.

Across the latest seven complete UTC days, Xatu recorded 8,874,848 mainnet disconnect rows from 41 observer labels. Those rows covered 23,820 remote peer keys, but the median observed session lifetime was only one second. 57.55% of the rows ended inside ten seconds.

Gossipsub PRUNE rows are not peer churn

· 5 min read
Aubury Essentian
Ethereum Research

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.

reject_message is mostly not invalid gossip

· 4 min read
Aubury Essentian
Ethereum Research

Clarification, 2026-07-18: Even the validation failed bucket 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 as validation failed 11–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'.

IHAVE is not a block counter

· 5 min read
Aubury Essentian
Ethereum Research

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."

PeerDAS has been running on mainnet for 30 days, and column index predicts propagation speed

· 5 min read
Aubury Essentian
Ethereum Research

PeerDAS — EIP-7594's data availability sampling system — has been live on Ethereum mainnet for over 30 days. All 128 column subnets are active, and the data is arriving: 10,956 out of 10,958 slots in the last 48 hours had every single column propagate within 12 seconds. That's 99.98% completeness. The protocol is working.

But there's something nobody seems to have noticed: column index 0 arrives 156 milliseconds faster than column index 101. The correlation between column index and median propagation time is 0.82. And it's been this way, consistently, for seven consecutive days.