Skip to main content

The newPayload backfill changes the runners on March 27

· 5 min read
Aubury Essentian
Ethereum Research

engine_newPayload just gained another three and a half months of history. That is useful, but the new line has a seam in it: on March 27, the regular-node sample jumps from six observers and two execution clients to as many as fifteen observers and four clients.

If you plot "fastest client" straight through that seam, Nethermind appears to improve from 47.5% of observed slots to 94.9% in two days. It did not suddenly get twice as fast. Nine more runners walked onto the track.

The "6-hour" MEV reward average forgot five hours

· 5 min read
Aubury Essentian
Ethereum Research

A six-hour moving average that only sees one hour is not smoothing much. At 23:00 UTC on July 10, Xatu's fct_proposer_reward_hourly stored 0.303736 ETH in its moving_avg_reward_eth field. The actual six-hour mean was 0.017821 ETH.

The 17x gap came from one 12.506337 ETH relay-delivered block, included eleven seconds after the hour began. Because it landed first, the stored calculation kept re-counting it through almost every cumulative average in that hour. The previous five hours never entered the window.

Receipt p95 is a p95 of p95s

· 4 min read
Aubury Essentian
Ethereum Research

A percentile does not survive being percentiled again. Xatu's hourly receipt-size table has a column labelled p95_receipt_bytes_per_transaction, but on July 10 it never matched the p95 across transactions. The table value was 1.50x to 3.90x higher, with a median ratio of 2.67x across the 24 hourly buckets.

The data was not stale and the transaction denominator was not drifting. Both paths covered the same 2,823,931 canonical transactions. They were simply calculating different statistics under the same name.

Some live peers were weeks behind Ethereum's head

· 4 min read
Aubury Essentian
Ethereum Research

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.

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.

The data-column availability table is mostly gossip

· 5 min read
Aubury Essentian
Ethereum Research

mainnet.fct_data_column_availability_by_slot looks like the table you would use to ask whether PeerDAS custody probes are succeeding. It has availability_pct, success_count, missing_count, failure_count, and a column called probe_count. I used it that way first, and it told me something too clean: 100.00% availability for seven complete UTC days.

That is not the active custody-probe success rate. It is mostly the gossipsub sidecar observation stream wearing an availability-shaped name.