205 posts tagged with "ethereum"

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.

beacon_api_eth_v1_events_data_column_sidecar has a very clean-looking trap. It has a column_index, and it has kzg_commitments_count. If you sum that field, you are not counting blobs. You are counting the same block-level commitment list once per data column, and then again for every observer row that emitted the event.

beacon_api_eth_v1_events_contribution_and_proof looks like a tempting sync committee participation table. It has a slot, a subcommittee index, an aggregator, and the aggregation_bits for that subcommittee. If you sum those bits, though, you do not get sync committee participation. You get the same vote surface counted again and again.

The previous type-4 post left one obvious loose end. The labelled Poisoner target was the gas-heavy part of EIP-7702's type-4 surface, so I half-expected it to be private orderflow or at least hard to see before inclusion.

It was the opposite. From Jun 30 through Jul 6 UTC, Xatu saw every one of the 31,565 canonical type-4 transactions sent to that target in its mempool table. The barely visible bucket was the much smaller executeBatch tail.

beacon_api_slot sounds like the table you would reach for when you need a slot count. That is the trap. On Jul 5 UTC, mainnet had 7,200 scheduled slots and 7,165 canonical blocks. The raw beacon_api_slot table had 2,550,257 rows and 712,240,161 attestation-count units.

That is not Ethereum having 712 million canonical attestations in one day. It is an observer rollup doing exactly what the schema says, with a name that invites lazy queries.

engine_newPayload has a scary-looking ERROR bucket. I went looking for bad payloads there and found 18,762 raw rows in seven complete UTC days. That sounds like an execution incident until you dedupe the rows by the payload they were trying to validate.

Those rows were only 876 distinct (slot, block_hash) payloads. All 876 joined back to canonical beacon blocks. The important thing hiding in the status name is that ERROR is not the Engine API saying INVALID; in this slice it was transport and RPC failure telemetry around payloads that still landed on chain.

The consolidation queue looked busy if I counted it the lazy way. On Jul 5 UTC, canonical_beacon_state_pending_consolidation had 7,927 deduped queue-position rows. The latest canonical state snapshot had seven pending consolidations.

Same table. Different denominator.

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

Rocket Pool's rpl_staked event looks like it fell off a cliff at exactly the wrong time. The last decoded stake event in mainnet.int_rocketpool_node_event was 2026-02-17 23:20:23 UTC. The first decoded megapools started about 40 minutes later, on Feb 18, and the withdrawal side kept moving for months.

That does not mean "nobody staked RPL after Saturn." It means the old decoded stake-event surface is a bad post-Saturn RPL-staking ledger unless you know what changed.