12 posts tagged with "panda"

EIP-7610 was declined for Glamsterdam last week. It would have made CREATE and CREATE2 revert when the destination already had non-empty storage. The live Mainnet edge case is a small fossil: 28 accounts with storage, nonce zero and no code.

Those accounts do not look dead when you inspect their transaction history. Xatu has 100 direct transactions into 22 of them, and all 100 receipts say success. Ninety carried calldata. Twenty-five used selectors that resolve to withdraw or refund functions, while another 11 looked like attempts to destroy the contract that was not there.

Plataberget's Gloas fork looked like an epoch boundary until the head metrics stopped moving. Lodestar and Nimbus reported a post-fork head in 21 seconds median. Prysm and Teku did not get there for roughly 93 minutes.

The fork was not just a version switch. It walked 16,306 pending deposits to build Gloas's new payload-builder registry, and the way clients handled that queue decided who crossed quickly.

EIP-7709 came back from the dead last week. The proposal would charge BLOCKHASH for the storage reads it now represents, which sent me looking for contracts that call it hard enough to care. One SHIB airdrop did: 374 transactions into a single contract produced 149,600 calls, or 58.4% of every observed BLOCKHASH execution in a 14-day trace window.

The gas story is stranger than the count. Each airdrop read the same two ancestors 200 times, so most of the proposed storage charges would be warm. Even the cheapest all-warm backcast still pushes 327 of the 374 historical transactions past their original gas limits before their refund becomes usable.

The Gloas spec had a nasty edge: one validator could count twice toward a builder payment by sending two slashable attestations. The fix merged on August 16. Mainnet's 552 included attester-slashing proofs contain zero examples of the exact trigger.

EIP-8321 sounds almost suspiciously cheap. Replace the BLS RANDAO reveal with a hash chain, then store only the validator's current 32-byte commitment. The per-validator number is tiny. The validator registry is not.

Backcast against mainnet at finalized epoch 469,034, the proposed list body is 74.75 MB in raw SSZ. Of that, 45.98 MB points at validator indices that have already exited and can never propose again. The fork transition would initialize every one of those entries to zero, and the old indices have no proposal duty that needs a commitment.

Solidity's Panic(0x11) looks terminal. On mainnet it often isn't: across 14 complete UTC days, 5,333 of 5,772 transactions containing an overflow, underflow, or division-by-zero panic still ended green. Every panic happened in an internal child call.

A Hegotá proposal would remove a precompile that contracts called an observed 4.07 million times in twelve days. That sounds reckless until you look at the bill: a first-touch upper-bound backcast of Draft EIP-7666 adds up to 0.44% to the gas used by the affected transactions.

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.

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.

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.