canonical_beacon_validators looks like the obvious table to count validators. It is, but only after you pick one epoch. If you skip that step, you can manufacture half a billion validator rows in a day.
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."
Two days ago I wrote that Nimbus v26.6.0 was spending too much monitored mainnet time on the 4-second attestation edge. Nimbus v26.6.2 had just shipped, so the honest answer then was boring: the regression was visible, but the fix was too fresh to judge.
There is enough post-release data now for a first check. It is not a clean victory lap. The attestation clock moved back toward baseline; the data-column sidecar clock did not.
I almost talked myself into a fake MaxEB panic: sync committee selection is stake-weighted, attestation rewards scale with effective balance, so maybe sync committee rewards accidentally scale like stake squared.
They don't. In the first usable canonical_beacon_sync_committee_reward window I checked, validators with 1024+ ETH effective balance were 0.67% of active validator indices, 26.45% of active effective stake, 26.20% of observed sync committee member-slots, and 26.36% of sync committee rewards. The scary stake-squared model would put them at 91.56%.
canonical_execution_four_byte_counts sounds like the table you reach for when you want to count function calls. That is exactly how to get lied to.
I expected a selector leaderboard. What I found was one row per transaction, with the noisiest selector inside that transaction winning the row. Useful, but only if you do not read the name too literally.
canonical_execution_nonce_reads sounds like it should tell you who is using nonces. It mostly tells you which accounts execution had to touch. In the seven complete UTC days from June 23 through June 29, the table had 71.7M nonce-read rows. 31.0M of them, 43.2%, read nonce = 1.
Nimbus cut v26.6.2 this morning with a blunt note: it "mitigates regressions in attestation performance and bandwidth usage in v26.6.0." That is exactly the kind of release note that is easy to nod at and move past. I wanted to know whether the monitored mainnet data had a shape behind it.
It did.
Base had a public bad day on June 25. The status page said mainnet block production was unhealthy at 16:03 UTC, sequencing had resumed by 17:51, and the incident was resolved at 19:22. The Beryl maintenance window still went ahead from 18:00 to 20:00.
A 65,534-block Ethereum reorg did not happen last week. Caplin still said it did, at least through the Beacon API chain_reorg event stream.
Erigon 3.5.0 landed with a very good headline: parallel block execution is on by default. That should make Ethereum block validation feel less serial, at least where the workload and configuration let it pay off.
The builder-class telemetry I checked had the opposite shape. Two observed Erigon 3.5.0-dev-8b4c6990 nodes processed the same 7,174 mainnet payloads as the other eip7870 builder nodes. Giving every implementation its fastest observed node in each slot, Erigon's median was 283 ms. The fastest non-Erigon observation in each slot had a 24 ms median; Reth's own per-implementation median was 25 ms. Erigon won one fastest slot.