134 posts tagged with "ethereum"

beacon_api_eth_v1_proposer_duty looks block-ish if you only read the name. It has slot, epoch, proposer_validator_index, and a timestamp from the client that fetched it. That is enough rope to build a very wrong proposed-block counter.

The table is not a block feed. From Jun 27 through Jul 3 UTC, it had 1,491,952 raw rows for 50,400 scheduled slots, and the duty for the last slot in each epoch first appeared about 6m12s before that slot could produce a block.

I owe this one a correction. In February I wrote that Ethereum was carrying 296 GB of state. That was the value of mainnet.fct_execution_state_size_daily.total_bytes, but it was not the component total I described in the post.

On the same Feb 26 row, the exposed account, account-trie, contract-code, storage, and storage-trie byte columns add up to 430.9 GB. Storage trie bytes alone were 220.8 GB, so my old sentence saying "296 GB total" while also talking about trie bytes as part of that total was internally broken.

Type-4 transactions are easy to count and easy to overread. From Jun 20 through Jul 3 UTC, Ethereum had 257,388 deduped type-4 transactions, which was only 0.824% of all transactions in the same blocks. That sounds like a small EIP-7702 adoption number until you look at the gas: one address labelled Poisoner and a pile of plain ERC-20 transfer(address,uint256) calls consumed 86.5% of type-4 gas.

That is the trap. transaction_type = 4 tells you the envelope is EIP-7702's set-code transaction type. It does not, by itself, tell you this is a clean smart-wallet action, a user operation, or even something interesting at the authorization-list layer.

Some table names quietly lie to you. canonical_execution_address_appearances has relationship rows called erc20_transfer_from and erc20_transfer_from_to, which sounds like it should cover both sides of a token transfer. On July 1, it did something simpler and uglier: it pointed at the sender twice.

The June 29 sparse-blob day looked like one weird account making a mess. 0x54dd...bcb8 sent 11,784 one-blob transactions at about half a percent full, then disappeared from the next complete day I checked. The uncomfortable part is that the tiny-blob tail stayed behind.

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.

Teku 26.7.0 landed with a very specific operational note: QUIC p2p is enabled by default, on UDP port 9001 for IPv4. That is the kind of release-note claim that should leave a mark in the peer records if the release is actually visible on mainnet.

It did, but the shape was not "Ethereum just got QUIC." Most of the consensus ENRs I saw already had a quic port. Teku was the laggard.

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.