Ethereum-ontwikkelaars hebben de activering van de Glamsterdam-upgrade op het Hoodi-testnet gepauzeerd vanwege zorgen over het gedrag van reeds gedeployde smart contracts onder de nieuwe gasprijsregels van de upgrade. De beslissing werd genomen tijdens de All Core Devs Execution call #248, aldus de Ethereum Foundation in de aankondiging van 22 oktober.

Belangrijkste punten van de beslissing:

• De state-kost van een nieuwe storage slot stijgt van 20.000 naar 97.920 gas.
• De geplande verhoging van de gaslimiet van Hoodi naar 200 miljoen is ook geschrapt.
• Er is geen activeringsdatum voor Glamsterdam op mainnet vastgesteld.
• De Last Call-review van EIP-8037 eindigt op 1 november.

De laatste testnetstap vóór mainnet ligt stil

Glamsterdam zou op 26 oktober om 17:42:48 UTC activeren op Hoodi. De uitstel schrapt zowel de Amsterdam-activering op de execution layer als de Gloas-activering op de consensus layer — de twee helften van de upgrade — samen met het schema waarmee de gaslimiet van Hoodi tegelijk naar 200 miljoen was verhoogd. Het wijzigt de toekomstige configuratie van het testnet zonder de geschiedenis terug te draaien, en er is geen vervangende datum vastgesteld.

Tijdens Fusaka, de vorige upgrade, was Hoodi het derde en laatste testnet dat vóór mainnet forkte, en de Foundation zei dat mainnet ten minste 30 dagen later zou volgen, aldus The Block. In die uitrol was de laatste testnetfork het laatste openbare controlepunt vóór mainnet. Glamsterdam heeft al een repetitie met 200 miljoen gas op Sepolia doorstaan, waarbij de oplossing een Prysm-update van validator-standaardwaarden was — een clientconfiguratieprobleem. Deze keer gaat het om de vraag hoe reeds gedeployde contracten zich gedragen. De Foundation heeft geen mainnetdatum voor Glamsterdam vastgesteld en zegt dat mainnetgebruikers en ETH-houders niets hoeven te doen.

Een storègprijsverhoging die de execution-gas bij sommige writes verhoogt

EIP-8037 bestaat om de groei van Ethereum's state — de data die elk node moet opslaan — te vertragen. De auteurs schatten die state op ongeveer 390 GiB in januari 2026. Zij berekenden dat bij de huidige prijzen een gaslimiet van 200 miljoen de state in minder dan een jaar voorbij 650 GiB zou kunnen duwen — het niveau waarop nodes beginnen te vertragen. Hun antwoord is 1.530 gas per byte nieuwe state in rekening te brengen, waarmee de state-kost van een nieuwe storage slot stijgt van 20.000 gas naar 97.920 en van een nieuwe account van 25.000 naar 183.600.

Om grote contractdeployments mogelijk te houden, splitst het voorstel gas in twee pools. Execution-gas dekt berekeningen, en state-gas dekt nieuwe opslag. Alle gas dat een transactie boven 16.777.216 aanlevert, gaat naar een aparte state-gas reservoir, waarop state-kosten als eerste worden verhaald. Die reservoir wordt volledig doorgegeven aan elke sub-call, en contracten kunnen hem niet zien via de standaard gasleft()-uitlezing.

Execution-gas nodig voor een cold write naar een nieuwe storage slot, volgens ChainSecurity, op basis van cijfers uit EIP-8037 en EIP-8038:

• Vandaag: 22.100
• Glamsterdam, reservoir betaalt de state-kost van 97.920: 12.100
• Glamsterdam, reservoir leeg: 110.020

Met andere woorden, dezelfde cold write kan bij een lege reservoir ruim negen keer meer execution-gas kosten dan wanneer de reservoir de state-kost dekt.

Gas kan tijdens de execut ook terugvloeien. Het wissen van een slot dat eerder in dezelfde transactie is aangemaakt, vult onmiddellijk tot 97.920 gas bij, en een sub-call die revert, kan de betaalde state-kosten teruggeven. De zichtbare gasbalans van een contract kan daardoor tijdens de executie stijgen. De EIP waarschuwt dat contracten die werk meten als het verschil tussen twee gasuitlezingen een negatieve uitkomst kunnen krijgen, en dat contracten die al met dat ontwerp zijn gedeployed niet te repareren zijn.

Hoe een aanvaller de nieuwe regels kan misbruiken

Beveiligingsbedrijf ChainSecurity schetste het risico in een analyse van 13 oktober. Contracten vangen vaak een mislukte call op en registreren het resultaat, waardoor een kwaadwillende beller bewust te weinig gas kan aanleveren zodat een geldige operatie mislukt terwijl het contract nog genoeg gas heeft om die mislukking op te slaan. De techniek staat bekend als insufficient gas griefing en kan een retry permanent blokkeren of de claim van een gebruiker verwijderen.

Voor contracten die erop vertrouwen dat de failure handler zelf zonder gas raakt:

• Stap 1: De aanvaller stuurt een call met te weinig gas.
• Stap 2: De beoogde operatie komt zonder gas te zitten.
• Vandaag: De handler raakt ook zonder gas, alles reverteert en de gebruiker kan het opnieuw proberen.
• Glamsterdam: De reservoir of bijgevuld gas laat de handler afronden en de mislukking permanent opslaan.

Contracten die na een mislukte call het resterende gas controleren, kunnen worden misleid wanneer bijvullingen of een revertende intermediair de balans weer boven hun drempel duwen. Vaste gasbudgetten kunnen ook tekortschieten, omdat EIP-8038 de kost van het aanraken van bestaande state verhoogt: de eerste wijziging aan een bestaande warme slot stijgt van 2.900 gas naar 10.100.

Niet elke verdediging breekt. ChainSecurity zegt dat een controle vóór de call nog steeds de levering van het gevraagde gas garandeert, zolang het budget elk executiepad onder de nieuwe prijzen dekt zonder op de reservoir te rekenen. Het adviseert om überhaupt niet te vertrouwen op gascontroles na de call. De mededeling van de Foundation noemt alleen EIP-8037 en verwijst niet naar het werk van het bedrijf, dat ook EIP-808 bestrijkt.

Wat operators en ontwikkelaars moeten doen

Hoodi-operators moeten de execution- en consensusclients vóór 26 oktober bijwerken, met releases waarvan de release notes expliciet bevestigen dat de oude activering is verwijderd. Versietabellen uit de oorspronkelijke aankondiging gelden niet als bevestiging. Op 23 oktober had de Foundation bijgewerkte releases voor twee clients opgevoerd en gezegd dat andere zouden worden toegevoegd zodra ze zijn bevestigd.

Validators moeten zowel de beacon node als de validatorclient bijwerken, en iedereen die externe block-building-infrastructuur runt, moet de instructies van zijn provider volgen. Applicatieteams moeten stoppen met het plannen van Hoodi-tests rond de oorspronkelijke datum.

Voor contractontwikkelaars begint de checklist van ChainSecurity bij elke call die na een mislukking de executie laat doorgaan. Die omvat het traceren van het volledige pad, inclusief proxies; het vinden van slots die in dezelfde transactie worden gezet en gewist, en intermediairen die reverten; het hercontroleren van vaste budgetten; en het geforceerd laten mislukken van sub-calls en het vergelijken van de uitkomst onder beide regelsets. Waar mogelijk moet een mislukte call de hele operatie reverten. Wallets en node-software moeten volgens de EIP ook de gasestimatie voor het twee-poolmodel bijwerken.

De volgende beslissingen liggen bij de kernontwikkelaars. De Last Call-review van EIP-8037 — het laatste reviewvenster voordat een voorstel in Ethereum's proces wordt afgerond — sluit op 1 november, het onderzoek kan leiden tot specificatiewijzigingen, en een nieuwe Hoodi-datum zal op een toekomstige call worden vastgesteld.

Dit artikel is uitsluitend bedoeld voor informatieve doeleinden en vormt geen financieel of beleggingsadvies. Ethereum-upgradeschema's en technische specificaties kunnen tijdens het testen wijzigen.

Bron: Coindoo