EIP-8037: Glamsterdam bricht acht Gas-Annahmen

Das nächste Ethereum-Upgrade Glamsterdam steckt fest – und der Grund heißt vor allem EIP-8037. Die Ethereum Foundation hat am 6. November 2026 in einem Blogbeitrag von Marius van der Wijden erklärt, dass die neue Gas-Berechnung aus EIP-8037 und EIP-8038 acht Annahmen bricht, auf die sich bestehende Smart Contracts verlassen. Das Prüfunternehmen ChainSecurity hat bei Tests bereits Projekte gefunden, die nach Glamsterdam verwundbar wären. Die Core-Entwickler haben deshalb entschieden, das Testnetz Hoodi nicht zu forken, bis die Probleme gelöst sind. Gleichzeitig ruft die Foundation Entwickler und Auditoren auf, ihren Code selbst zu prüfen.

Für ETH-Halter besteht kein Handlungsbedarf, ein Mainnet-Termin für Glamsterdam steht ohnehin nicht fest. Für Teams, die Contracts, Bots, Relayer oder Wallets betreiben, ist der Aufruf aber sehr konkret.

Was EIP-8037 und EIP-8038 ändern

Beide Vorschläge sollen ein Skalierungsproblem lösen: das Wachstum des Ethereum-Zustands („State“), also aller Kontostände, Contract-Codes und Speicherplätze, die jeder Knoten vorhalten muss. EIP-8037 nennt dazu Zahlen: Im Januar 2026 belegte der State in einem Geth-Knoten rund 390 GiB. Nach der Anhebung des Gas-Limits von 30 auf 60 Millionen habe sich der täglich neu erzeugte State von etwa 105 MiB auf etwa 326 MiB mehr als verdreifacht – rund 116 GiB pro Jahr. Bei einem Gas-Limit von 200 Millionen rechnet das EIP mit rund 387 GiB pro Jahr.

EIP-8037 führt deshalb einen einheitlichen Preis pro neu angelegtem State-Byte ein und zielt auf ein durchschnittliches Wachstum von 120 GiB pro Jahr bei einem Referenz-Gas-Limit von 150 Millionen. Neu ist außerdem eine getrennte Abrechnung: Kosten für die Erzeugung von State („state gas“) werden separat erfasst und können aus einem eigenen Topf, dem „Reservoir“, bezahlt werden. EIP-8038 hebt ergänzend die Kosten für den Zugriff auf bestehenden State an, etwa für kalte Kontozugriffe und Schreibvorgänge.

Wie stark sich das auswirkt, zeigt die Tabelle im neuen Invarianten-Repository der Foundation, gemessen auf der festgeschriebenen Amsterdam-Spezifikation:

• SSTORE in einen neuen Speicherplatz (kalt): bisher 22.100 Gas, künftig 110.020 Gas, davon 97.920 State-Gas.
• SSTORE in einen bestehenden Speicherplatz: warm/kalt bisher 2.900/5.000, künftig 10.100/12.100 Gas.
• ETH-Überweisung an eine leere Adresse (neues Konto): bisher 25.000, künftig 183.600 State-Gas plus Ausführung.
• CREATE/CREATE2 an eine leere Adresse: bisher 32.000, künftig 195.600 Gas.
• Code-Deployment: bisher 200, künftig 1.530 Gas pro Byte.
• EIP-7702-Autorisierung für ein leeres Konto: bisher 25.000, künftig 235.606 Gas.

Das Reservoir gibt es nur, wenn das Gas-Limit einer Transaktion über 2²⁴ (16.777.216) liegt. Darunter wird alles State-Gas wie gewohnt aus gasleft() bezahlt.

Die acht gebrochenen Annahmen

Das Repository teilt die Probleme in zwei Typen: „Preis“-Invarianten, die jede Preisänderung bricht, und „Accounting“-Invarianten, die aus der neuen Abrechnungslogik von EIP-8037 folgen. Kurz zusammengefasst:

1. INV-1: Bisher scheiterte bei Out-of-Gas in einem Call die ganze Transaktion. Mit Reservoir kann Code nach einem gescheiterten Call noch Storage schreiben und den Fehlschlag dauerhaft festhalten.
2. INV-2: Wer einen Speicherplatz in derselben Transaktion von null setzt und wieder löscht, bekommt die 97.920 State-Gas sofort zurück – relevant für Locks und Flags um externe Calls.
3. INV-3: Ein revertierender Call gibt verbrauchtes State-Gas zurück, eine gescheiterte Contract-Erzeugung 183.600 Gas. Wer aus dem Restgas auf die Fehlerursache schließt, liegt womöglich falsch.
4. INV-4: Fest einprogrammierte Gas-Mengen reichen nicht mehr. State-Erzeugung kostet fünf- bis achtmal so viel, Updates bestehender Slots rund 7.200 Gas mehr pro Schreibvorgang.
5. INV-5: gasleft() kann während eines Calls steigen. Abrechnungen über die Differenz zweier gasleft()-Werte werden unzuverlässig.
6. INV-6: Das nach einem Out-of-Gas verbleibende 1/64 Gas kann zu den neuen Preisen reichen, um einen Fehlschlag zu protokollieren.
7. INV-7: Heute bemessene Gas-Reserven und Stipends reichen nicht mehr; die 2.300 Gas von transfer/send können keinen Speicherplatz anlegen.
8. INV-8: Eine EIP-7702-Delegation, der das Gas ausgeht, wird zurückgerollt, die Transaktion aber trotzdem gemined – die signierte Delegation lässt sich dann wiederverwenden.

Laut Repository betrafen die meisten bisherigen Funde INV-4 und INV-7. Diese beiden sollten Teams deshalb zuerst prüfen.

Warum EIP-8037 auch ein Sicherheitsthema ist

ChainSecurity hat das Problem bereits am 13. Oktober unter dem Titel „When Spent Gas Comes Back“ beschrieben. Der Kern: Viele Contracts fangen gescheiterte externe Calls ab, um einen Fehler zu vermerken oder mit dem nächsten Element weiterzumachen. Gibt ein Angreifer absichtlich zu wenig Gas mit, kann aus einer wiederholbaren Operation ein dauerhafter Fehlschlag werden („insufficient gas griefing“). Bisherige Schutzmechanismen beruhen auf Annahmen darüber, wie viel Gas nach einem Fehlschlag übrig bleibt. Glamsterdam verschiebt genau diese Rechnung – auch bei unverändertem Contract-Code.

Betroffen sind nicht nur On-Chain-Contracts. Das Repository weist ausdrücklich darauf hin, dass auch Off-Chain-Komponenten brechen können, etwa durch Änderungen an Transaktionsbelegen (Receipts), und nennt Bots, Relayer und signierte Nachrichten mit fest eingetragenen Gas-Werten. Bei INV-8 geht es um Wallets: Wer einen geminten Block als Beweis nimmt, dass eine 7702-Delegation funktioniert hat, sollte stattdessen den Code des Kontos nach der Transaktion prüfen.

Zeitplan: Hoodi auf Eis, Hegota läuft weiter

Glamsterdam auf Hoodi war ursprünglich für den 26. Oktober 2026 um 17:42:48 UTC (Epoch 132.352) geplant. Bereits am 22. Oktober hatte die Foundation die Aktivierung nach der Core-Dev-Runde ACDE #248 abgesagt, um die Wechselwirkungen von EIP-8037 mit Mainnet-Contracts zu untersuchen. Damit entfiel auch der Plan, das Gas-Limit auf Hoodi zum selben Zeitpunkt auf 200 Millionen anzuheben. Ein neuer Termin steht nicht fest.

Der Beitrag vom 6. November konkretisiert das: Die Foundation hat die Prüfer ChainSecurity und Dedaub beauftragt und führt eigene Audits durch, kann aber nicht alle Projekte abdecken. Die Arbeit am darauf folgenden Upgrade Hegota laufe parallel „in full force“ weiter. Je nach Rückmeldung könnten EIP-8037 und EIP-8038 noch leicht angepasst werden – oder auch nicht. Die Entscheidung soll in einer der nächsten All-Core-Devs-Runden fallen.

Was Entwickler jetzt tun sollten

• Code gegen die acht Invarianten prüfen, beginnend mit INV-4 und INV-7. Das Repository liefert Erklärungen, Beispiele und eine Anleitung für KI-Coding-Agenten, die den eigenen Code lokal durchsuchen sollen.
• Fest eingetragene Gas-Werte in Contracts, Konfigurationen, signierten Nachrichten und Bots einstellbar machen und unter den neuen Regeln neu schätzen.
• Funde vertraulich melden: per E-Mail an glamsterdam@ethereum.org, nicht als öffentliches Issue, damit Probleme behoben werden können, bevor sie breit bekannt sind.

Wer Glamsterdam schon länger verfolgt, kennt die Vorgeschichte aus unserem Bericht über den Glamsterdam-Fork auf Sepolia. Wie Ethereum andere langfristige Sicherheitsfragen angeht, zeigt EIP-8450 mit quantensicheren Ersatzschlüsseln. Und dass Angreifer jede Lücke im Umfeld von Contracts und Wallets nutzen, belegt der Fall der gekaperten DeFi-Websites mit Wallet-Drainer.

Die Verzögerung ist ärgerlich für alle, die auf höhere Gas-Limits warten. Sie ist aber auch ein Zeichen, dass der Testnet-Prozess funktioniert: Die Probleme fallen in Testnetz-Tests und Audits auf – nicht im Mainnet.