Die Ethereum-Core-Entwickler haben das Glamsterdam-Upgrade für das Hoodi-Testnetz ausgesetzt und die Netzwerkumstellung pausiert, bis Sicherheitsbedenken im Zusammenhang mit acht Smart-Contract-Invarianten gelöst sind. Die Ethereum Foundation gab die Entscheidung in einem am 6. November veröffentlichten Blogbeitrag bekannt.

LATEST: ⚡ Ethereum developers say they are delaying the Glamsterdam hard fork process and won't fork the Hoodi testnet until gas-repricing issues flagged by ChainSecurity are resolved. pic.twitter.com/7HDv6dZDrc

— CoinMarketCap (@CoinMarketCap) November 6, 2026

Eine Invariante ist eine Bedingung, die ein Smart Contract als stets wahr erwartet. Gas ist die Einheit, mit der Ethereum den Rechenaufwand bemisst, und viele bereits deployte Projekte gehen davon aus, dass bestimmte Operationen einen festen Betrag davon kosten. Zwei für Glamsterdam vorgesehene Vorschläge ändern, wie Gas abgerechnet wird, und diese Änderungen könnten solche Annahmen in bestehenden Contracts ungültig machen. Aus diesem Grund wird das Repricing als Sicherheitsfrage und nicht als routinemäßige Gebührenanpassung behandelt: Die betroffenen Beträge können darüber entscheiden, ob bestimmte Codepfade überhaupt ausgeführt werden.

Was ChainSecurity fand

Die Bedenken stammen aus einem Bericht des Smart-Contract-Auditors ChainSecurity vom 13. Oktober, der untersuchte, wie Glamsterdam Contracts beeinflussen könnte, die nach dem Scheitern eines externen Aufrufs weiterlaufen. Der Bericht behandelt EIP-8037, das die Kosten für das Erstellen neuen Blockchain-States ändert, und EIP-8038, das die Gebühren für den Zugriff auf bestehenden State anpasst. Beide verändern die Gasabrechnung für bestimmte Operationen.

Nach den heutigen Regeln verlassen sich einige Contracts darauf, dass eine fehlgeschlagene Operation zu wenig Gas für die nächsten Schritte übrig lässt. Nach den neuen Regeln könnten bestimmte Operationen abgeschlossen werden, obwohl die Entwickler erwartet hatten, dass die gesamte Transaktion zurückgesetzt wird. Das könnte in diese Contracts eingebaute Schutzmechanismen schwächen.

ChainSecurity gab ein Beispiel an. Ein Contract markiert eine Operation als fehlgeschlagen, nachdem ein externer Aufruf das Gas aufgebraucht hat. Nach den neuen Regeln könnte Gas, das zuvor unerreichbar war, wieder verfügbar werden, und der Contract könnte einen dauerhaften Fehler verzeichnen.

Die Ethereum Foundation hat ein GitHub-Repository veröffentlicht, das die acht betroffenen Invarianten dokumentiert. Es enthält Erläuterungen, Beispiele und konkrete Schritte, mit denen Entwickler ihren eigenen Code gegen die neuen Gas-Regeln prüfen können. Feste Gas-Budgets und Gas-Reserven sind die bisher häufigsten gefundenen Probleme, was bedeutet, dass eine Änderung auf Protokollebene latente Annahmen in deploytem Code zutage fördern kann, ohne dass die Contracts selbst modifiziert werden.

Weitere Risiken betreffen Contracts, die davon ausgehen, dass der Gasverbrauch sich nur in eine Richtung bewegt, dass feste Gas-Kontingente ausreichend bleiben oder dass ein zurückgesetzter Aufruf kein Gas zurückgeben kann, das bereits für das Erstellen von State ausgegeben wurde.

Hoodi-Fork auf Eis

Die Hoodi-Aktivierung war ursprünglich für den 26. Oktober um 17:42:48 UTC angesetzt. Hoodi ist das wichtigste öffentliche Testnetz von Ethereum, in dem geplante Protokolländerungen in der Regel vor der Mainnet-Einführung geprobt werden. Die Verschiebung entfernte die Amsterdam-Execution-Layer- und Gloas-Consensus-Layer-Aktivierungen aus dem Zeitplan sowie eine geplante Erhöhung des Gas-Limits des Testnetzes auf 200 Millionen. Ein Ersatztermin wurde nicht bekannt gegeben, und die Foundation erklärte, der Hoodi-Fork werde erst durchgeführt, wenn die Probleme gelöst seien. Da die Mainnet-Aktivierung normalerweise auf die öffentlichen Testnetz-Proben folgt, bleibt auch Glamstamstams Weg zum Mainnet ohne festen Zeitplan.

Die Entwickler prüfen nun, ob betroffene Contracts eigenständig aktualisiert werden können oder ob die Upgrade-Spezifikationen geändert werden müssen. Der Ethereum-Foundation-Entwickler Marius van der Wijden erklärte, das Team arbeite mit ChainSecurity und Dedaub zusammen und führe interne Audits durch, um die Auswirkungen auf bestehende Anwendungen zu bewerten.

Die Foundation erklärte, ihre Überprüfungen könnten nicht jedes Projekt abdecken, insbesondere dort, wo Contracts mit Off-Chain-Systemen interagieren. Sie hat Entwickler und unabhängige Auditors gebeten, sowohl On-Chain-Contracts als auch Off-Chain-Tools zu prüfen, darunter Wallets, Relayer und andere Infrastruktur, die fest kodierte Gas-Limits verwenden kann.

Erkenntnisse sollten vor den nächsten All Core Developers Discussions eingereicht werden, dem ständigen Forum, in dem die Ethereum-Client-Teams und Forscher Protokolländerungen koordinieren. Berichte sollten den betroffenen Contract, die betreffende Invariante, mögliche Lösungen und, falls verfügbar, Tests auflisten. Sie können privat an glamsterdam@ethereum.org gesendet werden. Aufgrund des Feedbacks könnten die Entwickler EIP-8037 und EIP-8038 anpassen, wodurch diese Diskussionen der Maßstab sind, an dem Spezifikationsänderungen zu beobachten sind, die bestimmen, wann der Hoodi-Fork neu angesetzt werden kann.

Hintergrund zu Glamsterdam

Glamsterdam ging am 6. Oktober im Sepolia-Testnetz live, wo die Entwickler begannen, seine Skalierungsänderungen unter einem Gas-Limit von 200 Millionen zu testen. Das Upgrade führt außerdem die verankerte Trennung von Proposer und Builder durch EIP-7732 sowie Access Lists auf Blockebene durch EIP-7928 ein. Testnetz-Aktivierungen wie diese ermöglichen es den Entwicklern, das Verhalten des Upgrades in einer Live-Umgebung vor der Mainnet-Einführung zu beobachten.

In einer Bewertung im August erklärte die Foundation, dass Replays vergangener Transaktionen zeigten, dass die meisten Smart Contracts von den Preisänderungen nicht betroffen waren. Eine kleinere Gruppe benötigte höhere Gas-Limits oder größere Änderungen, um unerwartete Ausfälle zu vermeiden.

Am 26. Oktober mergeden die Entwickler außerdem einen Fix für Validator-Einzahlungen. Er behob einen Fehler, der Staking-Einzahlungen Block-Buildern mit demselben öffentlichen Schlüssel gutgeschrieben hätte. Regressionstests wurden in die Spezifikationen aufgenommen.

Die Foundation erklärte, die Arbeiten am nächsten Upgrade, Hegota, würden parallel fortgesetzt und seien von der Glamsterdam-Verzögerung nicht betroffen.