Ethereum weighs two fixes for Glamsterdam’s contract safety problem

Ethereum developers are weighing two competing designs to protect existing smart contracts from Glamsterdam’s proposed gas changes. The debate follows security findings that led core developers to delay the upgrade’s Hoodi testnet activation.

Glamsterdam is Ethereum’s next planned network upgrade. Two included proposals, EIP-8037 and EIP-8038, change how the network charges for creating and accessing stored data. Gas is the accounting unit that limits execution and determines the work a transaction pays for.

The dispute is about compatibility: contracts already deployed on Ethereum can rely on the old accounting rules to decide whether an operation succeeded safely.

Changing gas rules can change a contract’s failure path

ChainSecurity’s analysis shows how a failed call can leave enough usable gas for a contract to record a permanent failure under the proposed rules. Under earlier accounting, the same failure handler could have run out of gas and reverted the surrounding operation, preserving an opportunity to retry.

EIP-8037 introduces a separate reservoir for state-creation charges. EIP-8038 changes the prices of state access. Together, those changes can alter both what an operation costs and what a caller can do after it fails.

An application may deliberately detect an underfunded call and reject it. If changed accounting lets an underfunded attempt pass those checks, an attacker could interfere with otherwise valid actions. That is the insufficient-gas griefing risk examined by ChainSecurity.

One draft preserves the old schedule for existing code

Leo Glisic’s versioned-opcode proposal, drafted as EIP-8488, would keep existing contracts on the pre-Glamsterdam gas schedule. New contracts would use a parallel set of V2 instructions carrying the revised schedule.

The draft also versions delegated calls, which let one contract execute another’s code, and removes gas-introspection instructions from the new instruction set. Those instructions expose internal gas balances that contracts can build assumptions around.

The intended transition is gradual: old code retains its accounting, while newly deployed code adopts the new regime. This would leave some activity on the legacy schedule as contracts are replaced or upgraded.

The alternative separates running a contract from charging for it

Giulio Rebuffo’s competing draft would maintain separate execution credits and billing credits. Execution credits would preserve the legacy rules that contracts observe while running. Billing credits would apply the revised prices to calculate the transaction fee.

That design aims to keep existing control flow and out-of-gas behaviour compatible while updating the economic price of the work. If the shared billing allowance runs out, the entire transaction would abort, including when execution credits remain. That introduces a failure condition that application teams would need to test. The draft still requires execution-client implementation and consensus testing.

Both approaches remain proposals under review. Their central difference is where compatibility lives: in a separate instruction set for new code, or in separate execution and billing accounting.

Auditors are checking eight assumptions before Hoodi proceeds

The Ethereum Foundation’s 6 November update says Hoodi will wait until the identified issues are resolved. The Foundation is working with ChainSecurity and Dedaub, alongside internal reviewers, to assess affected projects and possible specification changes.

Developers have published a repository covering eight gas-accounting assumptions that the proposed changes can break. It includes explanations and examples to help contract teams check their own projects.

That review will inform the next core-developer decisions. The choice is how to increase Ethereum’s capacity while preserving the safety properties that existing applications rely on.