Ethereum vor Glamsterdam: Testnet startet, Hegotá bleibt offen

Diese Glamsterdam-Änderungen könnten Software brechen

Ein neues Gasmodell stellt alte Annahmen infrage

Glamsterdam enthält ein koordiniertes Paket zur Neupreisbildung von Gas, das auf eine Untergrenze von ungefähr 200 Millionen Gas abzielt. Anwendungen mit fest codierten maximalen Gaslimits könnten dadurch ausfallen – darunter Wallets, Indexer und Tools zur Gas-Schätzung.

Es geht nicht nur darum, eine einzelne Konstante auszutauschen. EIP-8037 führt eine eigene State-Gas-Dimension für Vorgänge ein, die neuen Zustand auf der Blockchain erzeugen. Nach dem aufgeteilten Gebührenmodell kann eine Überweisung an ein bereits existierendes Konto weiterhin 21.000 Execution Gas kosten. Bei einer Überweisung an ein noch nicht vorhandenes Konto kommt dagegen zusätzlich Runtime State Gas hinzu.

Entwickler sollten daher zwei verbreitete Annahmen aufgeben:

• Eine gewöhnliche ETH-Überweisung kostet immer exakt 21.000 Gas.
• Jede Ethereum-Transaktion lässt sich mit einer einzigen universellen Gasdimension beschreiben.

Wallets und Infrastruktur-Dienste sollten stattdessen protokollbewusste Schätzverfahren verwenden und auf Platåberget sowohl Überweisungen an bestehende als auch an neue Konten testen. Die Ethereum Foundation warnt ausdrücklich, dass Tools mit fest codierten Gasobergrenzen möglicherweise nicht mehr funktionieren.

ePBS verändert den Blockaufbau

Die im Protokoll verankerte Trennung von Proposer und Builder – kurz ePBS, umgesetzt über EIP-7732 – gehört zu den zentralen Glamsterdam-Änderungen. Sie verändert, wie Zuständigkeiten für die Erstellung und Validierung von Blöcken im Protokoll abgebildet werden.

Validator-, Builder-, Relay- und Node-Infrastruktur sollte deshalb nicht nur das Absenden einfacher Transaktionen prüfen, sondern die vollständigen Workflows rund um Blockproduktion und Validierung.

Blockweite Access Lists liefern zusätzliche Ausführungsdaten

Mit Block-Level Access Lists nach EIP-7928 kommen außerdem neue Informationen über die erwarteten State-Zugriffe innerhalb eines Blocks hinzu. Das kann Anpassungen an Execution-Clients, Blockparsern und Indexern erforderlich machen – insbesondere bei Systemen, die Blockinhalte analysieren oder modellieren.

Verträge und Initcode dürfen deutlich größer werden

Glamsterdam sieht auch höhere Größenlimits vor:

• Maximale Größe eines bereitgestellten Smart Contracts: 24 KiB auf 64 KiB.
• Maximale Initcode-Größe: 48 KiB auf 128 KiB.

Deployment-Tools, Bytecode-Prüfungen, Entwickler-Frameworks und Indexer sollten diese neuen Grenzwerte gezielt testen, statt die heutigen Limits als dauerhaft zu behandeln.

Checkliste für Tests auf Platåberget

Für Ethereum-Teams ist die praktische Vorbereitung wichtiger als der Name des Upgrades. Sie sollten:

• fest codierte Annahmen über maximale Gaslimits entfernen;
• ETH-Überweisungen an bestehende und nicht existente Konten testen;
• Execution Gas und State Gas, wo erforderlich, getrennt verbuchen;
• Gas-Schätzer, Gebührenanzeigen und Transaktionssimulationen überprüfen;
• Node-, Builder- und Validator-Abläufe im Zusammenhang mit ePBS testen;
• Blockparser und Indexer gegen blockweite Access Lists prüfen;
• die Verarbeitung von Contracts und Initcode an den geplanten größeren Limits testen;
• den Testzyklus wiederholen, sobald Glamsterdam in das Devnet ohne Finalität, nach Sepolia und nach Hoodi weiterwandert.

Platåberget ist damit mehr als eine technische Vorschau. Der entscheidende Vorteil des Testnets besteht darin, dass es Fehler in nachgelagerter Software sichtbar macht, solange noch Zeit für Updates vor einem Produktionsstart bleibt.

Hegotá: 66 Vorschläge, aber bislang nur ein fest eingeplantes Feature

Hegotá ist das geplante Ethereum-Upgrade für 2027. Der Umfang steht jedoch noch nicht fest: Insgesamt werden 66 Vorschläge geprüft. Eine Liste der Vorschläge, die zur Aufnahme empfohlen werden könnten, wird voraussichtlich um den 27. August erwartet; die Client-Teams sollen ihre Präferenzen bis zum 10. September einreichen. Diese Termine sind Entscheidungsschritte – sie bedeuten nicht, dass alle 66 Vorschläge umgesetzt werden.

Bei der Einordnung hilft die Unterscheidung zwischen den Statusstufen:

• Scheduled: offiziell zur Aufnahme vorgesehen.
• Considered: wird aktiv geprüft, ist aber noch nicht bestätigt.
• Candidate: Teil der breiteren Debatte und weiterhin im Wettbewerb um Implementierungs- und Testkapazität.

Derzeit ist FOCIL – Fork-Choice Enforced Inclusion Lists nach EIP-7805 – das einzige offiziell eingeplante Feature für Hegotá. Das Verfahren soll die Zensurresistenz stärken: Bestimmte Transaktionslisten könnten über die Fork-Choice-Regeln verbindlich gemacht werden. Dadurch würde es Block-Buildern erschwert, zulässige Transaktionen gezielt aus Blöcken herauszuhalten.

Die wichtigsten Hegotá-Kandidaten

Frame Transactions

Frame Transactions nach EIP-8141 gelten weiterhin als Vorschlag zur Prüfung und sind noch nicht für Hegotá bestätigt. Das Konzept definiert ein Transaktionsformat, bei dem Gültigkeit, Gebührenzahlung und Ausführung über eine Abfolge sogenannter Frames und Contract-Aufrufe abgewickelt werden.

Damit könnte ein protokollnativer Weg zu Account Abstraction und flexibleren Zahlungsmodellen für Transaktionen entstehen.

Ethereum-Forscher haben Frame Transactions außerdem gemeinsam mit verwandten Vorschlägen als möglichen Baustein für stärker integrierte Datenschutzfunktionen diskutiert. Ein solches Gesamtpaket ist jedoch noch kein beschlossenes Hegotá-Feature-Set.

Quick Slots

Ethlabs setzt sich für Quick Slots, EIP-8198, ein. Der Vorschlag soll im Rahmen eines bewusst begrenzten Hegotá-Umfangs schnellere Blockproduktion und eine schnellere Finalität ermöglichen. Kürzere Slot-Zeiten sind aber weiterhin nur vorgeschlagen und kein bestätigter Parameter des Upgrades.

Weitere Skalierung auf Layer 1

Zu den Empfehlungen von Ethlabs gehört außerdem, die Kapazität der Ethereum-Hauptschicht – Layer 1 – weiter auszubauen. Weitere genannte Prioritäten sind Zensurresistenz, schnellere Bestätigungen und native Account Abstraction. Diese Punkte sind Diskussionsprioritäten und nicht mit einer formellen Aufnahmeentscheidung gleichzusetzen.

Erhöhungen des Gaslimits, achtsekündige Slots, Post-Quantum-Kryptografie sowie weitere Vorschläge zu Validatoren, Datenschutz und der Execution Layer werden weiterhin geprüft und gehören noch nicht sicher zum Hegotá-Umfang.

Was Ethereum-Teams jetzt wissen müssen

Für Entwickler ist Glamsterdam die kurzfristige Kompatibilitätsaufgabe. Platåberget bietet die Gelegenheit, Probleme durch neue Gaspreise, State-Gas-Abrechnung, ePBS, Access Lists und größere Größenlimits zu finden, bevor die Änderungen Sepolia, Hoodi und das Mainnet erreichen.

Hegotá ist dagegen noch ein Auswahl- und Priorisierungsprozess. FOCIL ist bislang das einzige fest eingeplante Feature. Frame Transactions, Quick Slots, weitere Skalierungsmaßnahmen und andere Vorschläge müssen die nächsten Auswahl-, Implementierungs- und Testphasen erst noch durchlaufen.

Die pragmatische Schlussfolgerung lautet daher: Glamsterdam jetzt als aktives Kompatibilitätsprojekt behandeln – und Hegotá als sich entwickelnde Roadmap, nicht als fertige Liste von Ethereum-Funktionen für 2027.