Glamsterdam auf Sepolia: Execution-Clients sind vollständig, drei Consensus-Clients fehlen noch

Die Client-Releases für Glamsterdam auf dem Sepolia-Testnetz sind da — einen Tag vor dem angesetzten Termin. Alle fünf Execution-Clients planen den Amsterdam-Fork auf Unix-Zeit 1791294816 ein, also Dienstag, 6. Oktober 2026, 13:53:36 UTC. Auf der Consensus-Seite haben Teku, Prysm, Lodestar und Erigons Caplin nachgezogen. Für Lighthouse, Nimbus und Grandine lag am 28. September, 19:00 UTC, kein stabiler Release vor, der den Sepolia-Fork einplant. Wer einen Sepolia-Node mit einem dieser drei betreibt, hat noch keine Version, mit der er über den 6. Oktober hinwegkommt.

Der Release-Stand am 28. September

Geprüft an den Release-Seiten der Clients. Das Datum ist jeweils die Veröffentlichung des Release auf GitHub.

Execution Layer — vollständig:

• Geth v1.17.6 (23.09.) — „The Amsterdam hardfork is scheduled on the Sepolia testnet at timestamp 1791294816“
• Nethermind 2.0.0 (22.09.) — eigener Abschnitt „Ready to the Glamsterdam fork on Sepolia“, inklusive Fork-Block 11296768
• Besu 26.9.0 (25.09.) — Fork eingeplant, dazu ein Tuning des Layered-Txpool auf das kommende 200M-Gaslimit
• Erigon v3.7.0 (25.09.) — Amsterdam im Execution Layer und Gloas in Caplin, Epoch 353024
• Reth v2.7.0 (28.09.) — „Sepolia operators must upgrade before 6 October 2026 at 13:53:36 UTC“, dazu persistente RocksDB-Tabellen für Block-Level Access Lists

Consensus Layer — vier von sieben:

• Teku 26.9.1 (28.09.) — als „required update for the Sepolia network“ deklariert
• Prysm v7.2.0 (28.09.) — Fork eingeplant, mit einer Einschränkung beim Gaslimit (siehe unten)
• Lodestar v1.49.0 (28.09.) — Fork plus das 200M-Gaslimit eingeplant
• Caplin, der Consensus-Client in Erigon v3.7.0
• Lighthouse — letzter stabiler Release v8.2.2 vom 18. August, ohne Glamsterdam-Bezug
• Nimbus — letzter stabiler Release v26.8.0 vom 28. August; Nightlies erscheinen weiterhin täglich
• Grandine — letzter Release 2.0.6 vom 3. August

Was in der Konfiguration steht

Die Werte liegen im Repository eth-clients/sepolia — der Konfiguration, die die Clients tatsächlich einlesen:

Amsterdam Time:     1791294816   # Di, 6. Oktober 2026, 13:53:36 UTC
Gloas Epoch:        353024
Gloas Fork Version: 0x90000076

GAS_LIMIT_SCHEDULE:
  - EPOCH: 353024
    GAS_LIMIT: 200000000

Die zwei Namen im Config sind kein Tippfehler. Glamsterdam ist wie seine Vorgänger ein Kofferwort aus den beiden Layer-Forknamen: Gloas auf dem Consensus Layer, Amsterdam auf dem Execution Layer. Der EL-Fork wird über einen Unix-Zeitstempel aktiviert, der CL-Fork über eine Epoch — deshalb stehen beide Angaben nebeneinander.

Das Gaslimit: eine Stolperstelle für Prysm-Validatoren

Am 24. September ist im Sepolia-Config ein GAS_LIMIT_SCHEDULE nach EIP-8261 gelandet (eth-clients/sepolia#130): ab Epoch 353024 steigt das Netz-Gaslimit auf 200 Millionen. Auf Sepolia ist die Zahl damit nicht mehr nur eine Obergrenze, die das Protokoll erlaubt, sondern ein eingeplanter Wert.

Dieser Eintrag kam nach dem Release-Cut von Prysm. Die Prysm-Release-Notes sind in dem Punkt ungewöhnlich ausführlich, und zwar aus gutem Grund: v7.2.0 enthält das Schedule nicht, weshalb Validatoren auf dieser Version in ihren Gloas-Proposer-Preferences auf 60 Millionen zurückfallen. Wer mit 200 Millionen proposen will, muss den Wert explizit setzen — "gas_limit": "200000000" in einer Proposer-Settings-Datei der Version 2, oder über POST /eth/v1/validator/{pubkey}/gas_limit im Keymanager-API. Der Hinweis dazu: --suggested-gas-limit greift nur für Pre-Gloas-mev-boost-Registrierungen und hat nach dem Fork keine Wirkung mehr. Ein Folge-Release soll das Schedule nachliefern.

Lodestar hat das Schedule in v1.49.0 bereits mit an Bord.

Die zwei Headliner

Das Meta-EIP EIP-7773 listet 18 Core-EIPs als scheduled for inclusion. Zwei davon sind die eigentlichen strukturellen Eingriffe.

EIP-7732: Enshrined Proposer-Builder Separation

EIP-7732 zieht die Trennung von Proposer und Builder ins Protokoll. Statt eines vollständigen ExecutionPayload enthält der Beacon-Block künftig ein signiertes SignedExecutionPayloadBid — eine Zusage des Builders. Die Validierung des Payloads wird auf den Folgeslot verschoben, wodurch ein Slot die Zustände „full“, „skipped“ oder „empty“ annehmen kann.

Neu dazu kommen ein Builder-Registry mit Staking-Anforderung (mindestens 1 ETH, im Beacon State geführt) und ein Payload Timeliness Committee (PTC): eine Validator-Gruppe, die bezeugt, ob der Builder rechtzeitig geliefert hat — ohne den Payload selbst vollständig zu validieren. Damit wird Attestieren zu einer Aufgabe, die nicht mehr hinter der Execution-Validierung warten muss.

Wie viel Maschinerie daran hängt, zeigt sich an den Release-Notes: Prysm liefert für Gloas ein neues Builder-Registry-Endpoint (POST /eth/v1/beacon/states/{state_id}/builders), Proposer-Settings in einer Version 2, Per-Key-Builder-Konfiguration über das Keymanager-API, Remote Signing für Gloas-Blöcke und einen Builder Circuit Breaker, der Builder sperrt, die eine Auktion gewinnen und den Payload dann nicht offenlegen.

EIP-7928: Block-Level Access Lists

EIP-7928 macht das, was EIP-2930 optional angeboten hat, verpflichtend und blockweit: Ein Block deklariert vorab, welche Accounts und Storage-Slots er anfasst — inklusive der Werte nach der Ausführung.

Konkret:

• ein neues Header-Feld block_access_list_hash mit dem Keccak-256-Hash der RLP-kodierten Liste
• erfasst werden auch reine Lesezugriffe, dazu Balance-, Nonce- und Code-Änderungen mit ihren Post-Transaction-Werten
• eine Obergrenze von block_gas_limit // 2000 Einträgen
• deterministische Sortierung: Adressen lexikografisch, Änderungen nach Block-Index und Zugriffsreihenfolge
• eine Erweiterung der Engine API um ExecutionPayloadV4

Der Zweck ist parallele Ausführung: parallele Disk-Reads, parallele Transaktionsvalidierung, parallele State-Root-Berechnung — und State-Rekonstruktion beim Sync, ohne Transaktionen nachzurechnen. Dass das kein Papier-EIP mehr ist, sieht man an Reth: v2.7.0 aktiviert persistenten RocksDB-Speicher für Block-Level Access Lists und bringt Flags, um berechnete BALs für wiederholte Traces im Cache zu halten (--rpc-cache.cache-computed-bals, --rpc-cache.prewarm-bals).

Für wen sich was ändert

Node-Betreiber auf Sepolia. Der konkreteste Punkt: aktualisieren, und zwar vor dem 6. Oktober, 13:53:36 UTC. Wer nicht aktualisiert, folgt der Kette ab dem Fork-Zeitstempel nicht mehr. Für Execution-Clients gibt es die Versionen bereits alle. Auf der Consensus-Seite ist Teku, Prysm, Lodestar oder Caplin die Wahl, die heute funktioniert — bei Lighthouse, Nimbus und Grandine heißt es abwarten oder wechseln.

Sepolia-Validatoren. Zusätzlich zum Update die Gaslimit-Einstellung prüfen, siehe oben. Prysm-Nutzer, die den Wert nicht explizit setzen, proposen nach dem Fork mit 60 Millionen statt 200.

Infrastruktur- und Tooling-Teams. ExecutionPayloadV4 und das neue Header-Feld sind Breaking Changes für alles, was Engine-API-Payloads oder Block-Header selbst parst — Indexer, Explorer, Custom-Sync-Logik. Sepolia ist die erste öffentliche Gelegenheit, das gegen eine echte Kette zu testen.

Staking- und Validator-Software. ePBS führt mit dem PTC eine zusätzliche Validator-Pflicht ein und ändert die Verarbeitung von Withdrawals hin zu einem asynchronen Ablauf zwischen Consensus und Execution Layer. Das ist mehr als ein Parameter-Update.

Smart-Contract-Entwickler. Neben den Headlinern enthält Glamsterdam mehrere Repricing-EIPs, darunter EIP-8037 (State Creation Gas Cost Increase) und EIP-8038 (State-access gas cost update). Die Ethereum Foundation hat dazu im August einen eigenen Beitrag zum Testen der Repricing-Auswirkungen veröffentlicht.

Der Fahrplan danach

Aus dem Testing-Call ACDT #97 vom 21. September:

• 29. September 2026 — Termin für die Client-Releases; die meisten sind vorab erschienen
• 6. Oktober 2026, 13:53:36 UTC — Fork auf Sepolia, Epoch 353024
• 8. Oktober 2026 — Go/No-Go für Hoodi; an diesem Tag ist auch ACDE #247 angesetzt
• 27. Oktober 2026 — Hoodi, vorläufig

Für das Mainnet gibt es weiterhin kein Datum. Die Roadmap-Seite auf ethereum.org führt Glamsterdam als „Q4 2026 · Date not yet confirmed“.

Was offen bleibt

Drei Dinge gehören zur ehrlichen Einordnung.

Erstens: Der Sepolia-Termin ist bereits mehrfach verschoben worden. Ein eingetragener Zeitstempel ist eine Absicht, kein Vollzug — bis zum 6. Oktober kann er erneut fallen. Dass die Releases jetzt liegen, macht es wahrscheinlicher, aber nicht sicher.

Zweitens: Die drei fehlenden Consensus-Clients sind der eigentliche offene Posten. Solange Lighthouse, Nimbus und Grandine keinen Release mit dem Sepolia-Fork haben, fehlt einem Teil des Netzes die Grundlage — und Sepolia ist ein Proof-of-Authority-Netz mit einem begrenzten Validator-Set, das genau solche Lücken sichtbar machen soll. Was das für das Go/No-Go am 8. Oktober bedeutet, entscheidet sich im Call, nicht hier.

Drittens: Beide Headliner-EIPs sind formal nicht final. EIP-7732, EIP-7928 und das Meta-EIP 7773 stehen alle auf Review. Das ist für diese Phase normal, heißt aber, dass Detailänderungen weiterhin möglich sind.

Quellen

• eth-clients/sepolia — Fork-Konfiguration des Sepolia-Testnetzes, und PR #130 — Schedule 200m gas limit at the Glamsterdam upgrade
• Release-Notes: Geth v1.17.6 · Nethermind 2.0.0 · Besu 26.9.0 · Erigon v3.7.0 · Reth v2.7.0 · Teku 26.9.1 · Prysm v7.2.0 · Lodestar v1.49.0
• ethereum/pm #2225 — All Core Devs Testing #97, 21. September 2026
• ethereum/pm #2234 — ACDE #247, 8. Oktober 2026
• EIP-7773 — Hardfork Meta: Glamsterdam · EIP-7732 — Enshrined Proposer-Builder Separation · EIP-7928 — Block-Level Access Lists · EIP-8261 — Gas Limit Schedule
• ethereum.org — Roadmap: Glamsterdam
• Ethereum Foundation Blog — Glamsterdam Repricing Impact for Smart Contract Developers

Stand: 28. September 2026, 19:00 UTC. Release-Stände an den Release-Seiten der Clients geprüft. Dieser Beitrag berichtet über eine Protokolländerung und ist keine Anlageberatung.