Ethereum-Entwickler haben die Aktivierung des Glamsterdam-Upgrades auf dem Hoodi-Testnet ausgesetzt, da Bedenken bestehen, wie bereits eingesetzte Smart Contracts sich unter den neuen Gas-Preisregeln des Upgrades verhalten. Die Entscheidung fiel im All Core Devs Execution Call #248, wie die Ethereum Foundation in ihrer Ankündigung vom 22. Oktober mitteilte.

Kernpunkte der Entscheidung:

• Die State-Kosten eines neuen Storage-Slots steigen von 20.000 auf 97.920 Gas.
• Die geplante Anhebung des Hoodi-Gas-Limits auf 200M wurde ebenfalls gestrichen.
• Es wurde kein Mainnet-Aktivierungsdatum für Glamsterdam festgelegt.
• Die Last-Call-Prüfung von EIP-8037 endet am 1. November.

Der letzte Testnet-Schritt vor dem Mainnet steht auf der Stelle

Glamsterdam sollte am 26. Oktober um 17:42:48 UTC auf Hoodi aktiviert werden. Die Verschiebung entfernt sowohl die Amsterdam-Aktivierung der Execution Layer als auch die Gloas-Aktivierung der Consensus Layer – die beiden Hälften des Upgrades – sowie den Zeitplan, der Hoodis Gas-Limit gleichzeitig auf 200 Millionen angehoben hätte. Dadurch ändert sich die künftige Konfiguration des Testnets, ohne dessen Geschichte zurückzusetzen; ein Ersatztermin steht nicht fest.

Während des vorherigen Upgrades Fusaka war Hoodi das dritte und letzte Testnet, das vor dem Mainnet forkte, und die Foundation erklärte, das Mainnet würde mindestens 30 Tage später folgen, wie The Block berichtete. Bei diesem Rollout war der letzte Testnet-Fork der letzte öffentliche Checkpunkt vor dem Mainnet. Glamsterdam hat bereits eine Generalprobe mit 200 Millionen Gas auf Sepolia bestanden, bei der die Lösung ein Prysm-Update der Validator-Standardwerte war – ein Client-Konfigurationsproblem. Diesmal geht es darum, wie sich bereits eingesetzte Verträge verhalten. Die Foundation hat kein Glamsterdam-Mainnet-Datum festgelegt und erklärt, dass Mainnet-Nutzer und ETH-Inhaber nichts unternehmen müssen.

Eine Erhöhung der Storage-Preise, die das Execution-Gas bei manchen Schreibvorgängen senkt

EIP-8037 soll das Wachstum des Ethereum-States – der Daten, die jeder Node speichern muss – verlangsamen. Die Autoren beziffern diesen State mit rund 390 GiB im Januar 2026. Nach heutiger Preisgestaltung, so ihre Schätzung, könnte ein Gas-Limit von 200 Millionen den State in weniger als einem Jahr über 650 GiB treiben – die Schwelle, ab der Nodes langsamer werden. Ihre Antwort: 1.530 Gas pro Byte neuem State zu berechnen, wodurch die State-Kosten eines neuen Storage-Slots von 20.000 Gas auf 97.920 und die eines neuen Kontos von 25.000 auf 183.600 steigen.

Um große Contract-Deployments weiterhin möglich zu halten, teilt der Vorschlag das Gas in zwei Pools. Execution-Gas deckt die Berechnung ab, State-Gas den neuen Speicher. Alles Gas, das eine Transaktion über 16.777.216 hinaus bereitstellt, fließt in einen separaten State-Gas-Reservoir, aus dem State-Gebühren zuerst gezogen werden. Dieser Reservoir wird vollständig an jeden Sub-Call weitergegeben, und Contracts können ihn über die übliche gasleft()-Abfrage nicht sehen.

Benötigtes Execution-Gas für einen Cold Write auf einen neuen Storage-Slot, laut ChainSecurity auf Basis der EIP-8037- und EIP-8038-Zahlen:

• Heute: 22.100
• Glamsterdam, Reservoir zahlt die State-Gebühr von 97.920: 12.100
• Glamsterdam, Reservoir leer: 110.020

Mit anderen Worten: Derselbe Cold Write kann rund neunmal mehr Execution-Gas kosten, wenn der Reservoir leer ist, als wenn der Reservoir die State-Gebühr übernimmt.

Gas kann während der Ausführung auch zurückfließen. Das Freiräumen eines Slots, der earlier in derselben Transaktion angelegt wurde, füllt sofort bis zu 97.920 Gas auf, und ein Sub-Call, der revertiert, kann die gezahlten State-Gebühren zurückgeben. Der sichtbare Gas-Saldo eines Vertrags kann sich daher mitten in der Ausführung erhöhen. Die EIP warnt selbst, dass Contracts, die Arbeit als Differenz zweier Gas-Abfragen messen, ein negatives Ergebnis erhalten können und dass bereits eingesetzte Contracts mit diesem Design nicht repariert werden können.

Wie ein Angreifer die neuen Regeln ausnutzen könnte

Das Sicherheitsunternehmen ChainSecurity zeigte das Risiko in einer Analyse vom 13. Oktober auf. Contracts fangen fehlgeschlagene Calls oft ab und speichern das Ergebnis, was es einem bösartigen Caller erlaubt, gezielt zu wenig Gas bereitzustellen, sodass ein gültiger Vorgang fehlschlägt, während der Contract noch genug Gas hat, um diesen Fehlschlag zu speichern. Die Technik ist als Insufficient Gas Griefing bekannt und kann einen Wiederholungsversuch dauerhaft blockieren oder den Anspruch eines Nutzers entfernen.

Für Contracts, die darauf setzen, dass der Failure-Handler selbst ausgeht:

• Schritt 1: Der Angreifer sendet einen Call mit zu wenig Gas.
• Schritt 2: Dem Zielvorgang geht das Gas aus.
• Heute: Dem Handler geht ebenfalls das Gas aus, alles revertiert, und der Nutzer kann es erneut versuchen.
• Glamsterdam: Reservoir oder aufgetanktes Gas lässt den Handler abschließen und den Fehlschlag dauerhaft speichern.

Contracts, die nach einem fehlgeschlagenen Call das verbleibende Gas prüfen, können getäuscht werden, wenn Nachfüllungen oder ein revertierender Zwischenvertrag den Saldo wieder über ihre Schwelle heben. Feste Gas-Budgets können ebenfalls zu knapp ausfallen, weil EIP-8038 die Kosten für den Zugriff auf bestehenden State erhöht: Die erste Änderung eines bestehenden warmen Slots steigt von 2.900 Gas auf 10.100.

Nicht jede Verteidigung bricht. ChainSecurity zufolge garantiert eine Prüfung vor dem Call weiterhin die Bereitstellung des angeforderten Gases, sofern das Budget alle Ausführungspfade zu den neuen Preisen abdeckt, ohne auf den Reservoir zu bauen. Es rät davon ab, sich überhaupt auf Gas-Prüfungen nach dem Call zu verlassen. Die Mitteilung der Foundation nennt nur EIP-8037 und erwähnt die Arbeit des Unternehmens nicht, die auch EIP-8038 abdeckt.

Was Betreiber und Entwickler tun müssen

Hoodi-Betreiber müssen Execution- und Consensus-Clients vor dem 26. Oktober aktualisieren, und zwar mit Releases, deren Release Notes ausdrücklich bestätigen, dass die alte Aktivierung entfernt wurde. Versionstabellen aus der ursprünglichen Ankündigung gelten nicht als Bestätigung. Stand 23. Oktober hatte die Foundation aktualisierte Releases für zwei Clients gelistet und erklärt, weitere würden aufgenommen, sobald sie bestätigt sind.

Validatoren müssen sowohl den Beacon-Node als auch den Validator-Client aktualisieren, und alle, die externe Block-Building-Infrastruktur betreiben, sollten den Anweisungen ihres Anbieters folgen. Anwendungsteams sollten ihre Hoodi-Tests nicht mehr auf den ursprünglichen Termin ausrichten.

Für Contract-Entwickler beginnt ChainSecuritys Checkliste mit jedem Call, der nach einem Fehlschlag die weitere Ausführung erlaubt. Dazu gehören: das Nachverfolgen des gesamten Pfads einschließlich Proxys; das Auffinden von Slots, die in derselben Transaktion gesetzt und gelöscht werden, sowie von Zwischenverträgen, die revertieren; die erneute Prüfung fester Budgets; und das absichtliche Scheiternlassen von Sub-Calls sowie der Vergleich der Ergebnisse unter beiden Regelsätzen. Wo möglich, sollte ein fehlgeschlagener Call den gesamten Vorgang revertieren. Wallets und Node-Software müssen laut EIP zudem ihre Gas-Schätzung für das Zwei-Pool-Modell anpassen.

Die nächsten Entscheidungen liegen bei den Core-Entwicklern. Die Last-Call-Prüfung von EIP-8037 – das letzte Prüffenster, bevor ein Vorschlag im Ethereum-Prozess finalisiert wird – endet am 1. November, die Untersuchung kann zu Spezifikationsänderungen führen, und ein neuer Hoodi-Termin wird in einem künftigen Call festgelegtn
Dieser Artikel dient ausschließlich Informationszwecken und stellt keine Finanz- oder Anlageberatung dar. Ethereum-Upgrade-Zeitpläne und technische Spezifikationen können sich während des Testens ändern.

Quelle: Coindoo