11 posts tagged with "glamsterdam"

Eleven successful Glamsterdam contract-creation transactions did something Mainnet still treats as an ETH burn. During initcode, each new address called SELFDESTRUCT with itself as beneficiary. The address finished with no code, nonce zero and empty storage, but its 45,959–61,659 wei balance survived.

That is EIP-8246 working as designed. The stranger part is what EIP-7928 kept: 16 storage keys from accounts whose storage ended empty, including eight SSTORE writes that were erased at transaction finalization.

At first pass, Platåberget's new Gloas settlement table looks brutal. From August 21 through 30, 2,281 of 2,603 rows say DROPPED, an apparent failure rate of 87.6%.

That number is garbage as a payment rate. 2,250 of the dropped rows are the same empty shape: builder index zero, zero fee recipient, zero amount and zero weight. The observer emitted exactly one in every epoch. Filter those defaults out and the count flips: 31 of 353 nonzero pending-payment rows were dropped, or 8.8%.

The raw block access list was boring. Besu, Erigon, Ethrex, Nethermind and Reth all returned the same 92,543 RLP bytes for one canonical Glamsterdam block, and those bytes hashed back to the header. Then I asked for decoded JSON: Reth shortened 424 fields that the API defines as exactly 32 bytes.

An Ethereum transaction announcement is an invitation: send the hash now, then let the other peer ask for the transaction. One Geth sampler on Glamsterdam devnet-8 spent 60 hours issuing invitations that its legacy peers could not cash. Its logs contain 163,752 failed full-blob encodes across 42,537 truncated transaction labels.

Twenty-one thousand gas used to be the boring answer for a plain Ethereum transaction. EIP-2780 turns it into three answers, and the current Glamsterdam devnet showed an awkward split: every execution client enforced the same new minima, while their eth_estimateGas endpoints returned three different rows.

An event named execution_payload_available should be safe to act on. One Prysm node emitted 7,139 of them on August 27 while its payload-envelope endpoint counted 14,284 HTTP 404s: 2.0008 misses for every event.

Grandine and Lodestar did not validate a Gloas payload in zero milliseconds. The telemetry just made it look that way.

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.

I got one sentence wrong in the post I published earlier today. I wrote that a CoinTool XEN refund did not make its block cheaper because EIP-7778 already kept block gas accounting before refunds. EIP-7778 is scheduled for Glamsterdam, but it is not active on mainnet. Under today's rules, a refund lowers both the user's receipt gas and the gas counted in the block.

Adding the refund back changes the block story quite a lot. In the same 14 complete UTC days, at least 2,405 of 100,388 canonical blocks carried more gas before refunds than their historical gas limit. The worst reached a lower-bound 72.94 million gas against a 60 million limit.

Plataberget spent five hours producing block access lists around 24 KiB. A few hours later they had settled near 86 KiB, yet the lists still held roughly the same number of unique addresses and storage keys.

That is the part I did not expect. The devnet pushed almost ten times more gas through each block without adding more transactions or more BAL items. The extra 61 KiB went into the payload hanging off those items.