Ethereum Glamsterdam Testnetzvorbereitung und Folgen

Ethereum‑Entwickler und Netzbetreiber bereiten die Aktivierung des Glamsterdam‑Protokollbündels auf dem Hoodi‑Testnetz für den 26. Oktober 2026 um 17:42:48 UTC vor. Die Foundation legte die Hoodi‑Epoch auf 132.352 und den Slot auf 4.235.264 fest und veröffentlichte, dass das Block‑Gasziel des Testnetzes in jenem Epoch auf 200 Millionen steigen wird. Die Hoodi‑Aktivierung folgt auf die Sepolia‑Einführung von Glamsterdam am 6. Oktober. Wichtig ist, dass für das Mainnet noch kein Aktivierungsdatum festgelegt wurde; ein separates Statement wird einen Produktionstermin bekanntgeben.

Glamsterdam bündelt mehrere technische Änderungen. EIP 7732 führt die enshrined proposer‑builder separation ein und verlagert Commit‑, Reveal‑ und Proposer‑Payment‑Logik in die Konsensusregeln sowie neue Timeliness‑Pflichten für Payload‑Offenlegungen. EIP 7928 definiert block‑level access lists, die Konten und Storage‑Orte erfassen, auf die ein Block zugreift, sowie Post‑Transaction‑Zustandsänderungen, sodass Clients Lese‑ und Validierungsarbeit teilweise parallel planen können. Das Paket re‑preist zudem State‑Creation und State‑Access (unter anderem EIP 8037 und EIP 8038 sowie verwandte Anpassungen), wodurch Gas‑Kosten verschiedener Operationen verschoben werden und Verträge mit festen Stipends oder hardcodierten Limits betroffen sein können.

Der Testnetz‑Charakter wird betont: ein 200 Millionen Gas‑Ziel ist ein Budget für Rechenaufwand pro Block, aber kein Versprechen für identische Mainnet‑Einstellungen oder eine vorhersehbare Gebührenentwicklung. Entscheidende Messgrößen sind, ob unabhängige Execution‑ und Consensus‑Clients Einigkeit erzielen, wie schnell Clients schwere Payloads verarbeiten, ob Builder ihre Payloads rechtzeitig offenlegen oder zurückhalten, und ob Access‑Lists echte Parallelität bringen, ohne Propagations‑ oder Validierungskosten übermäßig zu erhöhen. Die Foundation veröffentlichte kompatible Client‑Releases für einige Teams (zum Beispiel Besu 26.10.0, Nethermind 2.2.0, Prysm v7.3.0), während andere Implementierungen noch nicht gelistet sind; Betreiber sollten auf ausdrücklich kompatible Releases warten.

Betrieblich müssen Validatoren, Node‑Betreiber und Builder‑Dienste Execution‑ und Consensus‑Clients, Beacon‑Nodes und Validator‑Clients aktualisieren und Builder‑Tooling, Gas‑Limits sowie Duty‑Änderungen prüfen. Entwickler und Wallet‑Teams sollten Gas‑Schätzungen, neue Logs und Opcodes unter dem neuen Gas‑Schema testen; Replay‑Analysen haben eine kleine Menge von Verträgen identifiziert, die Probleme oder Verschlechterungen erleiden könnten, und betroffene Teams wurden kontaktiert. Testnet‑Beschränkungen werden ebenfalls hervorgehoben: Test‑ETH hat keinen realen Marktpreis, sodass böswilliges Verhalten günstiger sein kann, und synthetische Stresstransaktionen bilden nicht unbedingt Mainnet‑Traffic ab.

Marktkommentare in einer Quelle sprechen von moderaten Preiseffekten, weil die Änderungen vorerst auf das Testnetz beschränkt sind. Der Weg zum Mainnet erfordert erfolgreiche Hoodi‑Beobachtungen — Client‑Konsens unter Last, berechenbare Payload‑Timeliness, messbare Blockauslastung und Verarbeitungszeiten — und anschließend einen koordinierten Mainnet‑Plan mit kompatiblen Client‑Releases. Kurzfristig sind nach dem 26. Oktober die Erreichung des geplanten Slots, Client‑Fehlerberichte, verspätete oder fehlende Builder‑Reveals, die Verteilung der Blockgrößen und Validierungszeiten sowie weitere Foundation‑Anweisungen über ein Produktionstermin zu beobachten.