Ethereum: Glamsterdam kommt am 26.10. aufs Hoodi-Testnet

Glamsterdam ist ein Doppel-Upgrade: Amsterdam auf der Ausführungsebene, Gloas auf der Konsensebene. Es soll Ethereums L1-Skalierung voranbringen, und zwar über zwei große Änderungen.

Was sich bei der Blockproduktion ändert

Die erste Änderung ist ePBS (EIP-7732), die eingebettete Trennung von Block-Proposern und Buildern. Bisher läuft der Austausch zwischen beiden über externe Zwischensoftware, der man vertrauen muss. Künftig gibt der Proposer die Zusage eines Builders für einen Ausführungs-Payload in den Block, der Builder legt den Payload danach offen, und das Protokoll wickelt die Bezahlung des Proposers selbst ab. Außerdem werden Konsens- und Ausführungsvalidierung getrennt, Validatoren haben also mehr Zeit, Payloads zu prüfen. Ein Ausschuss bestätigt, ob der Builder rechtzeitig geliefert hat und die Blob-Daten verfügbar waren.

Die zweite Änderung sind Block-Level Access Lists (EIP-7928). Sie halten fest, auf welche Konten und Speicherplätze ein Block zugreift und welche Zustandsänderungen nach den Transaktionen entstehen. Clients können dadurch Zustand parallel von der Festplatte lesen, Transaktionen parallel validieren und die State Root effizienter berechnen. Zusammen sollen ePBS und BALs mehr Ausführungskapazität ermöglichen, ohne dass das Validieren für Node-Betreiber unpraktikabel wird.

Gas-Preise und Entwickler-Folgen

Dazu kommt eine Neubepreisung von Gas, die besser zu den tatsächlichen Kosten von Ausführung und State-Wachstum passen soll. EIP-8037 erhöht die Kosten für das Anlegen von neuem State und misst sie separat, EIP-8038 passt die Kosten für State-Zugriffe an. Das Problem dabei: Verträge, die auf feste Gas-Stipends, hartkodierte Gaslimits oder Annahmen über das verbleibende Gas bauen, brauchen womöglich Anpassungen. Entwickler sollen ihre Contracts und Gasschätzungen auf Sepolia und Hoodi testen. Die Stiftung stellt dafür einen Leitfaden zur Repricing-Wirkung bereit.

Hinzu kommen kleinere Neuerungen: Logs für ETH-Transfers, ein Opcode für die Slot-Nummer, eine höhere maximale Contract-Größe, ein deterministischer Factory-Contract und neue Stack-Befehle. Auf der Konsensseite werden gesperrte (geslashte) Validatoren vom Vorschlagen ausgeschlossen, und das Exit- und Konsolidierungs-Churn steigt.

Wer muss was tun? Betreiber von Hoodi-Nodes und Hoodi-Staker müssen vor dem 26. Oktober sowohl Execution- als auch Consensus-Client aktualisieren, bei Validatoren auch Beacon Node und Validator Client. Ein Node ohne das Update kann dem Netzwerk nach der Aktivierung nicht mehr folgen. Für Mainnet-Nutzer, ETH-Halter und Mainnet-Betreiber ändert sich durch die Hoodi-Ankündigung nichts. Der Bug-Bounty-Fonds der Ethereum Foundation gilt bereits für die Glamsterdam-Spezifikationen.