18 posts tagged with "execution"

A contract address can hold ETH before it has bytecode. That sounds like EVM trivia until a gas proposal has to decide whether deploying the code creates a new account or updates one that is already there.

Across 14 complete August days, 8,980 successful code deployments landed on addresses with a positive prestate balance. That was 1.03% of comparable creation frames, and the addresses held 5,989.950758 ETH in total before their deployment transactions began.

Ethereum created 587,445 contracts with non-empty runtime code in the first 14 complete days of August. 537,256 of them repeated runtime bytecode seen in an earlier block inside the same window.

That is 91.5%. The obvious culprit is the usual flood of 45-byte proxies, but those tiny contracts are only half the story. They own the address count; a few thousand large redeployments own the bytes that EIP-8058 is trying to stop charging twice.

In February I described Ethereum's block timestamps as a tight but noisy clock: 12.05 seconds on average, with 0.38% of blocks supposedly arriving more than 14 seconds after the previous one. That was the wrong clock. Execution payload timestamps are protocol slot time, so consecutive canonical blocks in the fixed seven-day reconstruction are either 12 seconds apart or, when one slot has no canonical block, 24 seconds apart.

The embarrassing bit is that the old 0.38% was close to a real number. It just measured empty-slot cadence, not late block arrival.

I need to correct a noun I used three weeks ago. I called canonical_execution_balance_reads logical instrumentation for ETH balance reads. The count was real; the thing being counted was not.

These rows are transaction-account prestate records. They are not BALANCE opcodes, repeated balance lookups, or a gas counter.

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.

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.

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.

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.