Ethereum-Entwickler haben den Glamsterdam-Hard-Fork – ein netzweites Protokoll-Upgrade, das von jedem Node-Betreiber ein Update der Client-Software erfordert – auf dem Hoodi-Testnet verschoben, nachdem Sicherheitsexperten potenzielle Gas-Accounting-Anpassungen identifiziert hatten, die die Funktionsweise derzeit eingesetzter Smart Contracts bei fehlgeschlagenen Transaktionen beeinträchtigen könnten.

Das neueste Update schiebt die Aktivierung des bevorstehenden Mainnet-Hard-Forks von Ethereum auf unbestimmte Zeit zurück und wirft Zweifel am vorläufigen Rollout-Fenster im Dezember auf.

Glamsterdam-Zeitplan in Frage gestellt

In einem am Donnerstag veröffentlichten Blogbeitrag teilte die Ethereum Foundation mit, dass die Aktivierung aus Sicherheitsgründen verschoben wurde. Laut Foundation entschieden die Entwickler während des ACDE-#248-Calls – dem zweiwöchentlichen All Core Developers Execution Meeting – gemeinsam, das Update zu verschieben, um die Interaktion zwischen dem EIP-8037-Vorschlag und den derzeit im Ethereum-Mainnet eingesetzten Smart Contracts zu evaluieren.

Ursprünglich sollte der Hoodi-Hard-Fork am 26. Oktober um 17:42:48 UTC in Epoche 132.352 – einer Einheit fester Länge auf Ethereums Consensus-Layer – aktiviert werden. Diese Epoche wurde nun aus der Deployment-Konfiguration entfernt, ohne dass eine neue Epoche angesetzt wurde. Ein Ersatztermin wurde nicht bekannt gegeben.

Die Verschiebung betrifft auch die Aktivierung von Gloas auf der Consensus-Schicht sowie eine geplante Erhöhung des aktuellen Gas-Limits von Hoodi auf 200 Millionen – der Obergrenze dafür, wie viel Rechenleistung ein Block enthalten darf –, die beide Teil des Glamsterdam-Update-Pakets sind. Die Foundation betonte jedoch, dass die Terminänderung die bestehende Chain-Historie von Hoodi nicht beeinträchtigt.

Wie die Gas-Änderungen nach hinten losgehen könnten

Das Problem reicht bis zum 13. Oktober zurück, als das Blockchain-Audit-Unternehmen ChainSecurity zwei Ethereum Improvement Proposals aus dem Glamsterdam-Upgrade – EIP-8037 und EIP-8038 – als Bedrohung für bestehende Maßnahmen gegen das sogenannte „Insufficient Gas Griefing“ einstufte. Bei diesem Angriff sendet der Aufrufer absichtlich zu wenig Gas, sodass eine legitime Contract-Funktion fehlschlägt.

Gas ist die Einheit, in der Ethereum Rechenleistung misst, und Contracts werden unter der Annahme geschrieben, dass einem Vorgang zugewiesenes Gas verbraucht und nicht zurückerstattet wird. Mit Einführung dieser Maßnahmen würde es möglich, Gas an einen Contract zurückzugeben, sobald ein Vorgang fehlschlägt, und so weitere Ausführung zu ermöglichen, die sonst gestoppt worden wäre. Viele Contracts nutzen die Restgasmenge während einer Transaktion als eines ihrer Sicherheitsmerkmale. Würde diese Annahme geändert, könnte ein Contract den fehlgeschlagenen Vorgang abschließen, sodass ein Nutzer nichts mehr beanspruchen oder einen anderen Vorgang ausführen könnte.

Der Umfang des Upgrades geht über das Gas-Accounting hinaus. In einem Beitrag auf X vom 26. September hob Ethereum-Mitgründer Vitalik Buterin die erwarteten Sync-Verbesserungen des Upgrades hervor:

Erinnerung: Man kann einen Ethereum-Node inzwischen in einem halben Tag synchronisieren, und mit aggressiven Einstellungen kann der Speicherplatz auf der Festplatte unter einem halben Terabyte liegen. EIP-4444 und die harte Arbeit der Client-Teams zur Optimierung von Snap Sync haben die Dinge deutlich verbessert. Glamsterdam wird die Sync-Situation weiter verbessern (z. B. nutzt Nimbuss neues Sync-Protokoll dies) — vitalik.eth (@VitalikButerin), 26. September 2026, auf X

Einige Gas-Prüfungen werden die Änderungen ohnehin überstehen, müssen aber gegen Glamstamsterdam neues Accounting-System auditiert werden.

13 Real-World-Contracts markiert

ChainSecurity teilte am Freitag mit, 13 Fälle potenziell gefährdeter Real-World-Contracts entdeckt zu haben und mit den betroffenen Projekten Responsible Disclosure zu praktizieren. Während das Unternehmen die betroffenen Projekte oder Details der entdeckten Fälle nicht nannte, empfahl es den Entwicklern dringend, ihre Contracts zu prüfen. Anders als herkömmliche Software lassen sich eingesetzte Ethereum-Contracts nicht einfach patchen – weshalb die Prüfpflicht vor jedem neuen Aktivierungstermin bei jedem einzelnen Projekt liegt.

Die Nachricht sorgte in der Community für starke Reaktionen. Der pseudonyme Entwickler pcaversaccio kommentierte am 21. Oktober auf GitHub, die Lage sei „ernst“, und der Fork müsse neu bewertet werden.

Die Ankündigung folgt zudem auf eine frühere Warnung der Ethereum Foundation, dass Glamstamsterdam neuer Gas-Preis-Mechanismus Wallets, Indexer und Gas-Estimatoren, die mit festen Annahmen arbeiten, beeinträchtigen könnte.

Glamsterdam startete am 6. Oktober auf dem Sepolia-Testnet; Hoodi war der nächste erwartete Checkpoint vor dem Mainnet-Start – im Rollout-Prozess von Ethereum fungieren Testnet-Läufe als Tore, die ein Upgrade vor dem Mainnet passieren muss. Ursprünglich plante das Team ein Mainnet-Deployment im Dezember, abhängig von erfolgreichen Tests auf dem Hoodi-Testnet. Da die Hoodi-Aktivierung nun nicht mehr möglich ist, sollte der vorgeschlagene Dezember-Release nicht länger als Deadline betrachtet werden. Die entscheidenden Indikatoren sind, ob eine neue Epoche in die Deployment-Konfiguration aufgenommen wird, was die Evaluierung der EIP-8037-Interaktion ergibt und was aus ChainSecuritys Responsible-Disclosure-Austausch mit den 13 markierten Projekten hervorgeht.