Developers of Ethereum have called off the Glamsterdam hard fork on the Hoodi testnet, which was set for October 26. Security researchers showed that new gas accounting rules could change how smart contracts already running on the main network behave. There is no new date.
What exactly was postponed
Activation on Hoodi was planned for October 26 at 17:42:48 UTC. The delay was decided at the All Core Devs Execution meeting on Thursday, October 22. According to the Ethereum Foundation, teams first want to work out how some of the proposals interact with contracts already deployed on the network.
A planned increase of the Hoodi gas limit to 200 million was postponed along with the launch. The upgrade went live on the Sepolia testnet on October 6 and ran without cancellations. Hoodi was meant to be the next public rehearsal.
Hoodi serves as a public proving ground before the main network. Developers fix the mainnet activation date only after a successful test there, so cancelling one launch pushes back the whole upgrade schedule.
Glamsterdam bundles several changes:
- a new system for choosing block builders
- improvements that let the network handle larger blocks
- a revised gas accounting model for storage operations
Where the risk hides
The problem involves proposals EIP-8037 and EIP-8038. The first changes the price of creating new records in the Ethereum database, to slow its growth as the network processes more transactions. ChainSecurity's analysis from October 13 showed that together with the second proposal it alters how a contract reacts when another contract it calls runs out of gas.
Some contracts catch a failure and carry on. They note that an attempt failed, block further attempts or move to the next step. Developers sometimes count on there being too little gas left for those actions, so the whole transaction reverts. Glamsterdam changes that. Gas spent on creating records can be returned when the changes are undone, and it is enough to handle the failure.
The attack works only where a contract uses remaining gas as a safety catch. The authors of such contracts had no reason to doubt that assumption, since it held until now. Every call that handles a failure will need a manual check.
The opposite risk exists too. By ChainSecurity's calculation, creating a new storage slot when a separate allowance is exhausted would take 110,020 gas instead of 22,100. A contract with an old gas budget might fail to complete a perfectly valid operation.
What researchers say
ChainSecurity describes an attack called insufficient gas griefing, where a malicious caller deliberately gives a legitimate operation too little gas. If the defense against it relied on remaining gas, a contract could permanently record a failed action. It might delete a user's claim or disable a retry, and the person could not finish an operation that was valid.
The firm stressed that not every gas-based check would become unreliable. Some safeguards would still work, but developers need to review their code against the new rules. They should check their contracts as soon as possible.
A GitHub comment from pcaversaccio on October 21 rates the risks as "serious" and calls for the hard fork to be reassessed. ChainSecurity has not named the projects behind the 13 examples. It is coordinating responsible disclosure with them.
What it means for mainnet
Glamsterdam has no activation date on the Ethereum mainnet. Developers were considering early December and planned to finalize a schedule after a successful Hoodi test. That plan is now in doubt.
No one has shown publicly that a major production protocol can be attacked through these proposals. There are no signs of exploitation either. ChainSecurity has only demonstrated the mechanisms.
For users there are no direct consequences yet. Live contracts run on the old rules until the hard fork is activated on the main network. Teams have time to review before a schedule is approved.
The Ethereum Foundation earlier warned that the Glamsterdam gas model could break some crypto wallets, indexers and gas estimators that rely on fixed assumptions. Contracts themselves have now joined that list.
Comments
Your email address will not be published. Required fields are marked *