Glamsterdam Delay Holds Hoodi Fork Over Eight Broken Gas Invariants

A Glamsterdam delay is now in effect. On November 6, Marius van der Wijden posted to the Ethereum Foundation blog. The All Core Developers group, he wrote, will hold off on forking the Hoodi testnet. It waits until a set of broken assumptions is resolved.

Work on the following upgrade, Hegota, carries on in parallel. The Glamsterdam delay applies only to the fork schedule.

The trigger is a gas rewrite. Glamsterdam is already running on test networks, and ChainSecurity found a few projects that rely on behavior the update changes. The post names two proposals behind it, EIP-8037 and EIP-8038, which rework how gas is charged for state and for certain operations.

Glamsterdam delay: eight assumptions that stop being true

The security firm ChainSecurity flagged the problem on October 13. Its piece is titled "When Spent Gas Comes Back." The piece argues that a failed call can now leave more gas behind than contracts expect. A failure handler that used to run out of gas and revert could finish instead.

Contracts that record a permanent failure after a call are the exposed group. If a caller supplies too little gas on purpose, the contract may mark a retryable job as dead for good. Old gas checks were written for a world where that path usually reverted.

The Foundation then built a public repository of what changes. It lists eight numbered invariants, each with the old assumption, the new behavior, the code patterns to look for and a fix. The authors say they scanned contracts on Sourcify for candidates.

The invariants table in the repository README, listing the old assumption, new behavior, red flags and fix for each entry. Source: ethereum/glamsterdam-gas-invariants on GitHub.

Glamsterdam delay and the price of state gas

The README's measurements show why fixed gas numbers are a problem. Writing a value into a fresh storage slot cost 22,100 gas in the Osaka rules when the slot was cold. Under the Amsterdam spec it is 110,020, with 97,920 of that counted as state gas.

Sending value to an account with no history rises from 25,000 to 183,600 state gas plus execution. Code deposit moves from 200 gas per byte to 1,530 per byte. The authors note these figures were measured on a pinned spec and will shift if the spec does.

Updating a slot that already exists gets pricier as well, about 7,200 more per write by the README's own estimate. Any bot, relayer or signed message with a baked-in gas limit could fall short after the fork.

Glamsterdam delay effects on gasleft()

One invariant concerns the gas left counter. Glamsterdam adds a separate reservoir for state gas, and it exists only when a transaction's gas limit exceeds 16,777,216. Contracts that subtract two gasleft() readings to bill a user may get the wrong answer, because reservoir gas does not show in that reading.

Gas left can also rise during a call, which breaks a habit many developers treat as safe.

What teams should do during the Glamsterdam delay

The Glamsterdam delay comes with a call for action aimed at contract developers and auditors, not at ordinary holders. Teams that find a problem are asked to write to glamsterdam@ethereum.org, ideally with a working exploit.

Until the Glamsterdam delay ends there is no new fork date for Hoodi, and the post does not give one. Developers who keep gas limits adjustable and avoid billing from gasleft() differences stand best placed whichever way the spec lands.