Wurde das Ethereum-Glamsterdam-Upgrade abgesagt? Nein. Die Ethereum-Entwickler haben die geplante Aktivierung am 26. Oktober 2026 im Hoodi-Testnet verschoben, um zu untersuchen, wie vorgeschlagene Gas-Abrechnungsänderungen bestehende Smart Contracts beeinflussen könnten. Ein Ersatztermin für Hoodi wurde nicht festgelegt, und Glamsterdam hatte kein bestätigtes Mainnet-Aktivierungsdatum, das hätte abgesagt werden können.
Diese Unterscheidung ist zentral für die Ethereum-Roadmap im Jahr 2026. Glamsterdam wurde am 6. Oktober bereits im Sepolia-Testnet aktiviert. Der pausierte Schritt ist ein weiterer Test im öffentlichen Netzwerk – kein Rückroll des Ethereum-Mainnets und keine Aufgabe der Skalierungsziele des Upgrades. Die Ethereum Foundation gibt an, dass die Pause Interaktionen zwischen EIP-8037 und eingesetzten Contracts betrifft; die Agenda der Core-Entwickler vom 22. Oktober erörtert zudem Sicherheitsbedenken im Zusammenhang mit EIP-8038.
Was hat sich am 22. Oktober geändert?
Die frühere Ankündigung der Ethereum Foundation hatte die Hoodi-Aktivierung für den 26. Oktober um 17:42:48 UTC vorgesehen. Am 22. Oktober wurde dieser Zeitplan ersetzt: Die Amsterdam-Aktivierung der Ausführungsschicht, die Gloas-Aktivierung der Konsensschicht und eine geplante Erhöhung des Gas-Limits von Hoodi auf 200 Millionen wurden aus der konfigurierten Planung entfernt. Kein Ersatz-Epoch oder Zeitstempel wurde bekanntgegeben.
Dies ist eine Terminänderung, keine Umkehrung der Chain-Historie von Hoodi. Sie erzeugt auch eine operative Aufgabe: Hoodi-Nodes und Validatoren-Betreiber müssen den überarbeiteten Anweisungen ihrer Client-Teams folgen. Software, die noch die alte Aktivierungseinstellung vom 26. Oktober enthält, benötigt ein passendes Update, damit Betreiber keinen widersprüchlichen Zeitplänen folgen. Die Foundation stellt fest, dass Mainnuter und ETH-Inhaber aufgrund dieser Hoodi-Ankündigung keine Maßnahmen ergreifen müssen.
| Netzwerk | Status zum 23. Oktober 2026 | Bedeutung des Status |
|---|---|---|
| Sepolia | Glamsterdam am 6. Oktober aktiviert | Eine öffentliche Testnet-Aktivierung hat stattgefunden |
| Hoodi | Aktivierung am 26. Oktober verschoben; neuer Termin offen | Weitere Tests und überarbeitete Client-Releases erforderlich |
| Ethereum-Mainnet | Aktivierungsdatum nicht festgelegt | Kein geplanter Mainnet-Fork wurde abgesagt |
Die oben genannten Daten und Status stammen aus den Testnet-Ankündigungen der Ethereum Foundation und der Verschiebungsbekanntmachung vom 22. Oktober.
Warum kann eine Gas-Änderung ein Sicherheitsproblem sein?
„Gas-Neubepreisung“ klingt nach einer Änderung der Transaktionskosten. Für manche Contracts ist Gas jedoch auch Teil des Programmverhaltens. Ein Contract kann einen anderen Contract aufrufen, beobachten, ob der Aufruf erfolgreich war, und entscheiden, ob er es erneut versucht, zurücksetzt (revert) oder einen Fehler dauerhaft protokolliert. Diese Entscheidung kann von Annahmen darüber abhängen, wie viel Gas der Aufruf verbraucht und wie viel danach verbleibt.
EIP-8037 schlägt eine separate Abrechnung für bestimmte State-Erstellungskosten vor; EIP-8038 ändert die Kosten für den Zugriff auf State. Die Analyse von ChainSecurity erklärt den Kompatibilitätsaspekt: Unter den vorgeschlagenen Regeln könnte ein fehlgeschlagener Subcall genügend nutzbares Gas hinterlassen – oder wiederherstellen –, damit der Fehlerhandler eines äußeren Contracts abschließt, obwohl derselbe Pfad zuvor zurückgesetzt hätte. Ein Contract, dessen Sicherheit vom alten Verhalten abhängt, könnte dann ein Ergebnis protokollieren, das seine Entwickler nicht beabsichtigt hatten.
Das bedeutet nicht, dass jeder Ethereum-Smart-Contract eine Schwachstelle hat, dass ETH kompromittiert wurde oder dass ein Mainnet-Exploit stattgefunden hat. Die Vorschläge werden vor der Glamsterdam-Aktivierung im Mainnet geprüft. Die frühere Entwicklerleitlinie der Ethereum Foundation besagte, dass die große Mehrheit der Contracts von den identifizierten Neubepreisungsfällen nicht betroffen sei, und forderte betroffene Teams auf, ihre Annahmen zu testen und bei Bedarf anzupassen. Die anschließende Sicherheitsüberprüfung ist genau der Grund, warum diese Annahmen genauer untersucht werden sollten.
Die öffentlich beschriebenen Risikopfade
Die folgenden Punkte sind in der Analyse von ChainSecurity beschriebene Risikomuster, keine erfundene Liste von 13 separaten Befunden:
- Ein altes Gas-Budget ist möglicherweise nicht mehr ausreichend. Ein Contract kann die von seinem Entwickler angeforderte Gas-Menge erfolgreich weitergeben, doch die aufgerufene Operation könnte unter den vorgeschlagenen Bepreisungsregeln mehr Gas benötigen. Eine Prüfung, die einst sicher erschien, kann daher zu einem unerwarteten Out-of-Gas-Fehler führen.
- Eine niedrige Restgas-Ablese erzählt möglicherweise nicht die ganze Geschichte. Der von EIP-8037 vorgeschlagene State-Gas-Reservoir ändert, was nach einem Call bezahlt werden kann. Code, der
gasleft()allein als Beleg dafür interpretiert, dass ein Fehlerhandler nicht abschließen kann, könnte zu einem falschen Schluss kommen. - Das Löschen neu erstellten States kann Gas während eines Fehlerpfads auffüllen. Unter den von ChainSecurity beschriebenen Umständen kann diese Auffüllung dazu führen, dass Code nach einem fehlgeschlagenen Call abschließt, statt zurückzusetzen. Ob dies eine bestimmte Anwendung betrifft, hängt von ihrem Call-Pfad und ihren Abrechnungsannahmen ab.
- Ein revertierender Vermittler kann mehr Gas zurückgeben als erwartet. Bei mehreren Contracts in einer Call-Kette kann der Revert eines mittleren Contracts das dem ursprünglichen Aufrufer verfügbare Gas verändern. Eine Post-Call-Schwelle, die einen Out-of-Gas-Fehler zu erkennen schien, kann dies möglicherweise nicht mehr zuverlässig tun.
- Fehlerbehandlung kann ein Problem auf Anwendungsebene werden. Die Folge ist nicht bloß eine andere Gebührenschätzung. In einem anfälligen Design kann die Behandlung eines unterfinanzierten Versuchs als dauerhafter Anwendungsfehler einen Retry entfernen oder ein falsches Ergebnis protokollieren. Dies ist das Ergebnis, das Entwickler testen müssen, statt davon auszugehen, dass jeder geänderte Gaswert selbst ein Exploit ist.
Was zählt die berichtete „13“ tatsächlich?
Manche Berichterstattung beschreibt 13 große DeFi-Projekte mit potenziell betroffenen Contracts. Das ist wesentlich anders als die Aussage, Forscher hätten 13 unabhängige Sicherheitslücken offengelegt. Der öffentliche technische Artikel von ChainSecurity erklärt mehrere Mechanismen, veröffentlicht aber keine 13 einzeln benannten Befunde oder eine verifizierte Liste von 13 betroffenen Projekten. Offenlegung und Untersuchung bleiben Teil der Geschichte.
Für einen veröffentlichbaren Artikel zu ETH-Sicherheitsrisiken ist die sicherste Formulierung daher: „Berichten zufolge haben Forscher potenziell betroffene Projekte identifiziert; die öffentlich verfügbare technische Dokumentation beschreibt Gas-Abrechnungs- und Fehlerbehandlungs-Risikomuster, nicht ein vollständiges Verzeichnis von 13 Schwachstellen.“ Leser sollten nicht dazu verleitet werden zu schließen, dass 13 aktive Ethereum-Protokolle ausgenutzt wurden.
Welche Glamsterdam-Verbesserungen sind weiterhin geplant?
Die Pause löscht nicht die beabsichtigten Vorteile des Upgrades. Die beiden Kernfunktionen von Glamsterdam sind verankerte Proposer-Builder-Separation und Block-Level-Access-Lists. Erstere bringt Aspekte der Koordination zwischen Block-Proposern und -Buildern in Ethereums Konsensprotokoll. Zweitere erfasst die Accounts und Speicherorte, auf die ein Block zugreift, und schafft Möglichkeiten für Clients, Teile der Validierungsarbeit effizienter zu verarbeiten. Dies sind vorgeschlagene Funktionen, kein Versprechen einer bestimmten Gebührensenkung oder Transaktionen-pro-Sekunde-Zahl für Nutzer.
Gas-Bepreisungsänderungen bilden einen weiteren Teil des Pakets. Ihr Zweck ist, dass Entgelte die Ressourcen, die Ethereum beim Skalieren nutzt, besser widerspiegeln. Die Hoodi-Pause veranschaulicht den Zielkonflikt: Die Verbesserung, wie das Netzwerk Ressourcenkosten abrechnet, muss mit dem Verhalten von Contracts in Einklang gebracht werden, die bereits unter früheren Annahmen eingesetzt wurden. Die Frage für Entwickler lautet nicht nur „Können Clients die neuen Regeln ausführen?“, sondern auch „Was machen bestehende Anwendungen unter diesen Regeln?“
Was sollten Entwickler und ETH-Inhaber als Nächstes beobachten?
Anwendungsentwickler sollten Calls prüfen, die Fehler abfangen und die Ausführung fortsetzen, insbesondere dort, wo Code feste Gas-Budgets, Restgas-Schwellen oder Annahmen verwendet, dass ein Fehlerhandler selbst das Gas ausgeht. ChainSecurity empfiehlt, die Ergebnisse dieser Pfade sowohl unter dem bisherigen als auch dem vorgeschlagenen Gas-Plan zu testen – nicht einfach einen numerischen Grenzwert zu erhöhen und anzunehmen, die Anwendung sei sicher.
Hoodi-Betreiber sollten nach Client-Releases Ausschau halten, deren Hinweise die zuvor geplante Aktivierung am 26. Oktober ausdrücklich entfernen. Die Ethereum Foundation warnt davor anzunehmen, dass eine in einer älteren Ankündigung genannte Version die Verschiebung bereits enthält.
ETH-Inhaber müssen ihr ETH nicht konvertieren, keine Software installieren und keinerlei Mainnet-Maßnahme als Reaktion auf diese Testnet-Verzögerung ergreifen. Für alle, die die Auswirkung auf die Anlage beobachten, sind die bedeutsamen Meilensteine eine veröffentlichte Gegenmaßnahme oder Spezifikationsentscheidung, ein neuer Hoodi-Zeitplan, erfolgreiche Tests und – erst danach – ein bestätigtes Mainnet-Datum. Die Verzögerung allein begründet keine messbare Wirkung auf den künftigen ETH-Preis.
Häufig gestellte Fragen
Wurde das Ethereum-Glamsterdam-Upgrade abgesagt?
Nein. Die Ethereum Foundation hat die Hoodi-Testnet-Aktivierung am 26. Oktober verschoben und keinen Ersatztermin festgelegt. Sie hat keine Absage von Glamsterdam insgesamt angekündigt.
Wurde Glamsterdam im Ethereum-Mainnet verzögert?
Im Zeitplan der Foundation gab es kein bestätigtes Mainnet-Aktivierungsdatum. Der Verlust des geplanten Hoodi-Testdatums kann den Weg zum Mainnet beeinflussen, doch wäre es ungenau zu sagen, ein spezifisches, offiziell geplantes Mainnet-Datum sei verpasst worden.
Haben Forscher 13 separate Glamsterdam-Schwachstellen gefunden?
Die öffentliche technische Analyse zählt keine 13 separaten Schwachstellen auf. Die „13“ in mancher Berichterstattung bezieht sich auf Projekte mit potenziell betroffenen Contracts. Die verifizierte technische Besorgnis dreht sich darum, wie vorgeschlagene Gas-Änderungen das Fehlerbehandlungsverhalten bestehender Contracts verändern könnten.
Sind die Gelder der Ethereum-Nutzer gefährdet, weil Hoodi verschoben wurde?
Die Verschiebungsbekanntmachung meldet keine Mainnet-Kompromittierung und besagt, dass Mainnet-Nutzer und ETH-Inhaber keine Maßnahmen ergreifen müssen. Entwickler untersuchen Kompatibilitäts- und Sicherheitsauswirkungen vor der Planung des Upgrades im Mainnet; das ist keine Garantie, dass jede Anwendung bereits bewertet wurde.
Fazit: Die Hoodi-Generalprobe von Glamsterdam wurde aus einem konkreten Grund gestoppt: Entwickler müssen verstehen, wie neue Gas-Regeln mit bestehender Smart-Contract-Logik interagieren. Das hilfreichste nächste Update wird kein spekulatives Launch-Datum sein. Es wird der Nachweis sein, dass die identifizierten Fehlerpfade bewertet wurden und ein überarbeiteter Testzeitplan bereitsteht.
