Der Ethereum-Foundation-Entwickler Marius van der Wijden erklärte in einem Update vom 6. November, dass die Core-Entwickler den Hoodi-Testnet-Fork nicht durchführen werden, bis die vom Sicherheitsunternehmen ChainSecurity identifizierten Probleme gelöst sind. Hoodi ist das öffentliche Testnetzwerk, in dem Ethereum Protokolländerungen erprobt, bevor sie das Mainnet erreichen. Er bat Vertragsentwickler und Auditoren, ihre Projekte gegen acht Gas-Invarianten zu prüfen, die das bevorstehende Glamsterdam-Upgrade bricht. Gas ist die Einheit, in der Ethereum jede Operation einer Transaktion bepreist; verschieben sich diese Preise, kann Code, der unter den alten Werten geschrieben wurde, sich anders verhalten, obwohl der Code selbst unverändert bleibt.

Eine Invariante ist in diesem Kontext eine Regel, die Code als immer gültig behandelt – etwa „ein festes Gas-Budget reicht für diesen Aufruf aus“ oder „eine geminte Delegierung ist wirksam“. Das Invariants-Repository der Foundation listet acht Annahmen auf, die sich unter Glamsterdam ändern, und berichtet, dass die meisten bisherigen Funde zwei davon betreffen.

Zwei Vorschläge formen die Gaskosten neu

Zwei Vorschläge treiben die Änderung an. EIP-8037 erhöht den Preis für das Erstellen neuen States – neue Konten, Storage-Slots und deployter Code – und verrechnet ihn separat von der gewöhnlichen Ausführung. EIP-8038 erhöht den Preis für das Lesen und Aktualisieren bereits bestehenden States. Gemäß der Spezifikation, gegen die das Repository testet, steigt das Schreiben in einen frischen Storage-Slot von 22.100 Gas auf 110.020, das Aktualisieren eines warmen bestehenden Slots von 2.900 auf 10.100 und das Deployen von Code von 200 Gas pro Byte auf 1.530. Verschiebt sich die Spezifikation, verschieben sich diese Zahlen.

Die Pause bei den Glamsterdam-Tests folgte auf ChainSecuritys Prüfung vom 13. Oktober, wie bereits berichtet. Das Repository erweitert diese Erkenntnisse um eine eigene Scan-Untersuchung der Foundation zu auf Sourcify, einem öffentlichen Register für Vertragsquellcode, verifizierten Verträgen sowie um Offchain-Fälle wie Software, die Transaktionsbelege ausliest.

Eine geminte Transaktion beweist nicht mehr, dass eine Delegierung angewendet wurde

EIP-7702 ermöglicht einem gewöhnlichen Ethereum-Konto die Ausführung von Smart-Contract-Code durch Signierung einer Autorisierung, die auf einen Delegatenvertrag verweist. Der Mechanismus ging mit dem Pectra-Upgrade 2025 live und bildet die Grundlage der Smart-Account-Funktionen, die Wallets seitdem einführen. Die Autorisierung ist zur einmaligen Nutzung vorgesehen. Vor Glamsterdam wurden ihre vollen Kosten im Voraus berechnet, sodass eine Transaktion, die sie nicht zahlen konnte, ungültig war und nie einen Block erreichte. Wurde eine Transaktion gemint, war die Delegierung angewendet worden.

Der INV-8-Eintrag des Repositorys erklärt, was EIP-8037 ändert. Ein Teil der Kosten hängt nun vom Zustand des Kontos ab und wird erst während der Verarbeitung der Autorisierung berechnet. Die Delegierung von einem leeren Konto kostet 235.606 Gas, zuvor waren es 25.000. Eine Transaktion, die mit dem alten Wert budgetiert wurde, kann akzeptiert werden, während der Anwendung der Autorisierung das Gas ausgehen und mit fehlgeschlagenem Status in einem Block landen. Die Delegierung wird zurückgerollt, ebenso die Erhöhung der Nonce des Kontos, des Zählers, der eine Autorisierung als benutzt markiert. Die signierte Autorisierung ist jedoch nun öffentlich und weiterhin gültig.

Für sich genommen lässt das eine Wallet unkonfiguriert statt kompromittiert zurück. Die Gefahr entsteht, wenn der Delegatenvertrag jedermann den Aufruf seiner Setup-Funktion erlaubt. Ein Angreifer kann dann die offengelegte Autorisierung in einer eigenen Transaktion erneut einreichen, zuerst die Setup-Funktion aufrufen und sich als Eigentümer des Kontos eintragen. Front-Running von Autorisierungen im öffentlichen Mempool war bereits möglich. Der Punkt des Repositorys ist, dass eine fehlgeschlagene Transaktion nun selbst eine gültige Autorisierung veröffentlicht, sodass private Weiterleitung keinen Schutz bietet. Das Muster ist mit Beispielcode dokumentiert; kein betroffenes Wallet wird namentlich genannt.

Die praktische Änderung trifft Wallets, Relayer und Indexer. Das Repository rät, nach einer Delegierungstransaktion den Code und die Nonce des Kontos zu prüfen, statt dem Beleg zu vertrauen. Jede fehlgeschlagene Autorisierung sollte als offengelegt behandelt und annulliert werden – entweder durch Erhöhen der Nonce des Kontos oder durch erneute Delegierung an einen sicheren Vertrag. Eine Spezifikationsänderung, die die Worst-Case-Kosten im Voraus berechnen würde, wurde vorgeschlagen, aber nicht übernommen; Entwicklern wird geraten, so zu bauen, als bliebe das aktuelle Verhalten bestehen.

Gas-Budgets liegen oft außerhalb des Vertrags

Der umfassendste Eintrag, INV-4, betrifft jede vor dem Fork festgelegte Gasmenge. Sie kann nun zu klein sein, wo immer sie steht: in Vertragscode, in einem Einstellungswert, in einer signierten Nachricht oder in Offchain-Software. Die letzte Gruppe umfasst Relayer – Dienste, die Transaktionen im Namen der Nutzer einreichen – sowie Keeper und Auszahlungssysteme von Börsen.

Erstmalige Empfänger sind der häufigste Auslöser. Das Senden eines Tokens an eine Adresse mit Nullsaldo erzeugt einen neuen Saldo-Slot, und das Senden von ETH an eine leere Adresse erzeugt ein neues Konto – beides bereist EIP-8037 deutlich höher. Laut Repository kann eine Überweisung, die heute in 65.000 Gas passt, mehr als 150.000 benötigen.

Wo die feste Zahl steht, entscheidet, wie schlimm ein Fehlbetrag wird. In Offchain-Software revertiert die gesamte Transaktion und kann mit mehr Gas erneut gesendet werden. In einem Vertrag, in seinen Einstellungen oder in einer signierten Nachricht schlägt nur der innere Aufruf fehl. Fängt der äußere Vertrag diesen Fehler ab, ist das Ergebnis oft endgültig: eine als fehlgeschlagen gespeicherte Nachricht, ein übersprungener Callback oder falsch gebuchte Belohnungen. Einige dieser Zahlen lassen sich überhaupt nicht ändern, darunter Multisig-Transaktionen, die vor dem Fork signiert wurden, signierte Meta-Transaktionen und bereits unterwegs befindliche Cross-Chain-Nachrichten.

INV-7 wendet dasselbe Problem auf reserviertes Gas an. Soliditys transfer- und send-Funktionen übergeben feste 2.300 Gas, doch ein empfangender Vertrag, der einen neuen Storage-Slot schreibt, benötigt nun mehr als 110.000. Smart Wallets, Payment-Splitter und Vaults mit Logik in ihren Receive-Funktionen sind die naheliegenden Kandidaten.

Fehlerpfade, die früher revertierten, können nun abschließen

ChainSecuritys Analyse vom 13. Oktober erklärt, warum manche Schutzmechanismen, die frühere Audits bestanden, ihre Funktion einstellen können. Verträge fangen fehlgeschlagene externe Aufrufe oft ab, um den Fehler zu protokollieren, ein Element zu überspringen oder einen Fallback zu versuchen. Das wird gefährlich, wenn jemand absichtlich zu wenig Gas bereitstellt – ein Angriff, der als Insufficient-Gas-Griefing bezeichnet wird –, weil eine eigentlich wiederholbare Operation als dauerhaft fehlgeschlagen markiert wird.

Verträge verteidigen sich typischerweise auf zwei Arten. Manche prüfen, wie viel Gas nach dem Aufruf übrig bleibt. Andere verlassen sich darauf, dass der Fehler-Handler zu teuer ist, um abzuschließen. Glamsterdam schwächt beides. EIP-8037 gibt Transaktionen mit einem Gas-Limit über 16.777.216 einen separaten Speicher für Storage-Kosten, den die übliche gasleft()-Prüfung nicht sieht. Das Revertieren eines Aufrufs oder das Zurücksetzen eines frisch geschriebenen Slots kann zudem verbrauchtes Gas zurückgeben. In ChainSecuritys Worten: „Selbst mit unverändertem Vertragscode kann ein Fehlerpfad, der zuvor revertierte, nun abschließen.“

Das Unternehmen rät nun davon ab, aus dem verbleibenden Gas darauf zu schließen, warum ein Aufruf fehlschlug. Sein bevorzugter Ansatz ist, die gesamte Operation wo möglich revertieren zu lassen oder einen Wiederherstellungspfad vorzuhalten, statt eine irreversible Entscheidung auf Basis des verbleibenden Gases zu treffen.

Ein früheres Audit kann diese Lücke nicht allein schließen, da es den Code gegen die damals geltenden Gasregeln bewertet hat. Die Foundation hat ChainSecurity und Dedaub neben ihren internen Audits hinzugezogen, räumt aber in ihrem Beitrag vom 6. November ein, dass sie nicht jedes Projekt prüfen kann, insbesondere Offchain-Code. Auch Designentscheidungen formen die Lösung: Ein als anpassbare Einstellung gespeichertes Gas-Limit lässt sich einfach erhöhen, während ein fester Konstantwert womöglich nur Redeployment und Migration als Weg übrig lässt.

Warum Ethereum beim Repricing voranschreitet

Die Begründung der Foundation für die Änderung beruht auf Preisgenauigkeit. Ihre August-Leitlinie für Vertragsentwickler erklärte, die Gaspreise für State-Operationen wurden zuletzt im Berlin-Fork 2021 angepasst, dem Fork, der die aktuelle Cold-versus-Warm-Preisgestaltung für das Lesen von State festlegte. Ethereum State – der fortlaufende Datensatz von Konten, Salden und Contract-Storage, den die Nodes verfolgen – ist seitdem erheblich gewachsen, und die jüngsten Erhöhungen des Gas-Limits haben dieses Wachstum beschleunigt. Der Beitrag nannte das Repricing eine Voraussetzung für weitere Gas-Limit-Erhöhungen und sagte, der neue Preissetzungskatalog leite sich von einem Performance-Ziel ab, das eine rund dreifache Erhöhung des Basisdurchsatzes unterstützt.

Derselbe Beitrag berichtete, dass das erneute Abspielen historischer Mainnet-Transaktionen zu den neuen Preisen die große Mehrheit unverändert ließ und dass die meisten gemeldeten Probleme durch Erhöhen eines Gas-Limits behoben werden könnten. Regulären Nutzern wurde mitgeteilt, dass keine Maßnahmen nötig seien, da aktualisierte Wallets und Infrastruktur die Änderung handhaben würden. Die November-Erkenntnisse gewichten diesen letzten Teil schwerer. Die Bewältigung der Änderung umfasst nun die Prüfung des Kontozustands nach einer fehlgeschlagenen Delegierung und die Dimensionierung von Relayer-Budgets für erstmalige Empfänger – Arbeiten, die die alten Gasregeln nie verlangten.

Was die nächsten Core-Entwickler-Calls entscheiden

Laut Repository sammelt die Foundation Feedback vor dem nächsten All Core Developers Call, dem ständigen Forum, in dem Ethereum-Protokolländerungen vereinbart werden. Je nach Reaktion kann sie EIP-8037 und EIP-8038 leicht ändern oder unverändert lassen. Hoodi bleibt ungeforkt, bis die Probleme gelöst sind, und der Beitrag vom 6. November nennt kein neues Datum. Laut demselben Beitrag laufen die Arbeiten an Hegota, dem nach Glamsterdam geplanten Upgrade, parallel weiter.

Vor dem Hoodi-Fork: wer prüft was

• Vertragsteams: Adressen in die Lookup betroffener Verträge der Foundation einfügen und dann sämtlichen Code prüfen, der Gaswerte fest codiert oder auf verbleibendem Gas verzweigt – ob gelistet oder nicht.
• Wallets und RPC-Anbieter: Gas-Schätzung für den neuen Preissetzungskatalog aktualisieren. Die Foundation warnt, dass zwischengespeicherte Gaskonstanten Kosten unterschätzen und fehlgeschlagene Transaktionen verursachen werden.
• Relayer, Keeper und Bundler: Limits anpassbar machen und nach den neuen Regeln mit Puffer neu schätzen, mit Tests auf beiden Seiten der Speicherschwelle.
• Auditoren: Das Repository enthält Anleitungen zur Durchführung seiner Prüfungen mit einem KI-Coding-Agenten, wobei Code und Ergebnisse lokal bleiben.

Die Signale, die es zu beobachten gilt, sind ein Hoodi-Fork-Datum im Blog der Foundation, etwaige Revisionen der Spezifikation beider EIPs und Bestätigungen betroffener Projekte über behobene Fehler. Die Foundation hat die Teams gebeten, Probleme privat an glamsterdam@ethereum.org statt in öffentlichen Issues zu melden, damit Probleme behoben werden können, bevor Details bekannt werden.

Dieser Artikel erschien ursprünglich auf Coindoo.