Stand: 26. Oktober 2026.
Glamsterdam wird am 26. Oktober nicht auf Hoodi aktiviert. Die Ethereum Foundation hat den Termin am 22. Oktober ohne Ersatzdatum gestrichen: Betreiber des Testnetzes müssen ihre Software prüfen, während sich aus dieser Mitteilung für Nutzer des Ethereum-Mainnets und ETH-Inhaber kein Handlungsbedarf ergibt.
Entscheidend ist, den überholten Zeitplan nicht weiter als Betriebsanweisung zu verwenden. Die offizielle Mitteilung zur Verschiebung ersetzt die bisherigen Aktivierungshinweise und verlangt einen Blick auf beide Softwareebenen eines Knotens, also Ausführung und Konsens.
Glamsterdam: Welche Hoodi-Termine gestrichen wurden
Vorgesehen war der 26. Oktober 2026 um 17:42:48 UTC in Epoche 132352. Dieser Termin entfällt; daraus lässt sich weder der folgende Tag noch eine andere Epoche als neuer Start ableiten, denn die Foundation nennt bislang keinen Ersatzzeitpunkt.
Entfernt wurden die geplante Amsterdam-Aktivierung auf der Ausführungsebene und die Gloas-Aktivierung auf der Konsensebene. Ebenso entfällt die für dieselbe Epoche vorgesehene Erhöhung des Hoodi-Gaslimits auf 200 Millionen: Der alte Zeitplan belegt damit keine erfolgte Kapazitätserhöhung.
Die Ankündigung vom 16. Oktober ist weiterhin abrufbar, trägt inzwischen aber einen ausdrücklichen Hinweis auf die überholten Aktivierungsanweisungen. Ihre Tabellen dokumentieren den ursprünglichen Plan, nicht die Konfiguration, an der sich Betreiber jetzt orientieren sollten.
| Punkt | Aktueller Stand |
|---|---|
| Bisherige Aktivierung | 26. Oktober, 17:42:48 UTC, Epoche 132352: gestrichen |
| Ersatztermin | Kein neues Datum und keine neue Epoche angekündigt |
| Gaslimit von 200M | Mit der alten Epoche verknüpfte Erhöhung entfernt |
| Hoodi-Betreiber | Ausführungs-, Konsens- und Validator-Komponenten prüfen |
| Mainnet und ETH-Inhaber | Keine Maßnahme wegen dieser Verschiebung erforderlich |
Warum EIP-8037 genauer untersucht wird
Als Grund nennt die Foundation weiteren Untersuchungsbedarf bei Wechselwirkungen zwischen EIP-8037 und Smart Contracts des Mainnets. Daraus folgt weder, dass ein Angriff stattgefunden hat, noch dass sämtliche Verträge inkompatibel wären oder eine bestimmte Anwendung Geld verloren hätte.
EIP-8037 sieht höhere und gesondert erfasste Gaskosten für die Erzeugung neuen Zustands vor. Für Anwendungsteams geht es deshalb nicht nur um den Preis einer Transaktion, sondern auch um Annahmen darüber, welches Gasbudget während der Ausführung zur Verfügung steht.
Fest einprogrammierte Limits und Verfahren zur Gasschätzung können bei solchen Änderungen relevant werden. Unser Beitrag zur Gas-Neubewertung bei Glamsterdam erläutert diesen Zusammenhang; die neue Terminentscheidung ist für sich genommen kein Beleg dafür, dass die geplanten Regeln aufgegeben wurden.
Was Betreiber von Hoodi-Knoten prüfen sollten
Unterstützung für den ursprünglich geplanten Fork ist nicht dasselbe wie Unterstützung für dessen Verschiebung. Die Foundation warnt ausdrücklich davor, eine Version allein deshalb als geeignet anzusehen, weil sie in der früheren Veröffentlichung unter den kompatiblen Clients aufgeführt war.
Ein konkretes Beispiel liefern die Versionshinweise zu Geth v1.17.10: Diese Ausgabe streicht Amsterdam auf Hoodi. Betreiber mit v1.17.9 auf Hoodi sollen vor dem alten Aktivierungszeitpunkt aktualisieren; andere Netzwerke sind laut den Hinweisen davon nicht betroffen.
Auf der Konsensebene deaktiviert Lighthouse v8.3.2 den geplanten Gloas-Fork auf Hoodi. Wer Validatoren betreibt, muss die Hinweise für Beacon Node, Validator-Client und Ausführungsclient berücksichtigen, statt aus einem einzelnen aktualisierten Dienst auf den Zustand des gesamten Systems zu schließen.
Diese Beispiele stammen aus den Veröffentlichungen der Entwicklerteams; CryptoRoad hat die Kombination nicht installiert oder getestet. Für andere Clients gelten die jeweiligen offiziellen Versionshinweise, einschließlich möglicher Sonderkonfigurationen und zusätzlicher Vorgaben verwendeter Builder-Infrastruktur.
Für eine nachvollziehbare Kontrolle sollte erkennbar sein, welche Version auf welchem Netzwerk tatsächlich läuft und aus welcher Quelle die Netzwerkkonfiguration stammt. Eine heruntergeladene Aktualisierung ist noch keine laufende Aktualisierung; ein erfolgreicher Neustart allein dokumentiert ebenso wenig die Entfernung des alten Fork-Termins.
Keine Rücknahme der bisherigen Blockchain-Historie
Die Änderung betrifft eine Konfiguration für ein zukünftiges Upgrade, nicht die bereits bestehende Historie von Hoodi. Sie als Löschung bestätigter Transaktionen oder als Neustart des Testnetzes zu beschreiben, würde der angekündigten Maßnahme eine andere Bedeutung geben.
Anwendungsteams sollten stattdessen ihre für den 26. Oktober geplanten Tests neu einordnen. Ein vor dem Fork gewonnenes Ergebnis bestätigt kein Verhalten unter späteren Regeln, und ein im Kalender reserviertes Testfenster garantiert nach der Verschiebung nicht mehr die ursprünglich erwarteten Bedingungen.
Zu einem aussagekräftigen Testprotokoll gehören deshalb Netzwerk, Softwareversionen und aktive Regeln. Vorbereitung, Aktivierung und anschließende Beobachtung sind getrennte Schritte; allein ein Datum auf einem Ergebnisbericht macht diese unterschiedlichen Zustände nicht miteinander vergleichbar.
Auch die früheren Glamsterdam-Tests auf Devnet 11 gehören zu einer anderen Entwicklungsstufe. Sie liefern Hintergrund zum Protokoll, ersetzen aber weder die Bestätigung einer Hoodi-Aktivierung noch einen gesonderten Termin für das Ethereum-Mainnet.
Müssen ETH-Inhaber Guthaben verschieben?
Nein: Aus dem Aufschub ergibt sich keine Migration von Guthaben, kein Umtausch in einen neuen Token und keine Pflicht, eine Wallet zu verbinden oder eine Transaktion zu unterschreiben. Solche Forderungen wären keine Schritte, die diese Mitteilung für den Erhalt vorhandener ETH vorsieht.
Die Mainnet-Terminplanung darf nicht aus einem Testnetzdatum abgeleitet werden. Selbst ein bestätigter Hoodi-Termin wäre zunächst eine Aussage über Hoodi; hier liegt zusätzlich der ausdrückliche Hinweis vor, dass noch nicht einmal ein neuer Termin für dieses Testnetz feststeht.
Der nächste belastbare Anhaltspunkt ist ein neuer offizieller Aktivierungsplan mit passenden Client-Anweisungen. Bis dahin bleiben Schätzungen und alte Erinnerungen genau das: Sie sind keine bestätigten Fristen, auf deren Grundlage Betreiber oder Nutzer eine vermeintlich notwendige Mainnet-Migration vorbereiten müssten.
