Direkt zum Hauptinhalt

Glamsterdam verzögert sich: Ethereums MEV-Reform stößt auf technische Realität, da sich ePBS verspätet

· 12 Min. Lesezeit
Dora Noda
Dora Noda
Software Engineer

Zum ersten Mal in der beschleunigten Fork-Kadenz von Ethereum für 2026 - 2027 hat die Roadmap gezögert . Mitte April 2026 räumten die Kernentwickler öffentlich ein , was Client-Teams bereits seit Wochen flüsterten : Enshrined Proposer-Builder Separation — das ehrgeizigste Teil des Glamsterdam-Hard-Forks — ist " schwieriger als erwartet " , und das ursprüngliche Mainnet-Fenster für Mai - Juni ist fast sicher außer Reichweite . Die Verzögerung verschiebt Glamsterdam in Richtung Q3 oder Q4 2026 , verringert den Abstand zum bereits geplanten Hegota-Fork und wirft eine Frage erneut auf , die Ethereum bereits für geklärt hielt : Kann eine Basisschicht mit fünf Clients immer noch in dem Tempo Upgrades durchführen , das eine L2-Ökonomie nach Pectra erfordert ?

Die Antwort ist weit über Ethereums eigenes Ökosystem hinaus von Bedeutung . Jede Woche , die ePBS im Devnet verbleibt , ist eine Woche , in der das aktuelle Flashbots-Relay-Oligopol weiterhin zig Milliarden an jährlichen MEV-Strömen vermittelt , eine Woche , in der L2s Blobs gegen eine Angebotskurve einpreisen , die der Fork eigentlich lockern sollte , und eine Woche , in der Solana — das im September 2025 eine 98,27 %ige Zustimmung der Validatoren für seine Alpenglow-Konsensüberholung erhielt — seinen Vorsprung bei einer messbar schnelleren monolithischen Upgrade-Kadenz ausbaut . Glamsterdam war nie nur ein weiterer Hard Fork . Es war Ethereums Antwort auf die " Fast L1 " -These . Die Antwort verspätet sich nun .

Die zwei EIPs , die Glamsterdam definieren​

Glamsterdam — ein Kofferwort aus Gloas ( Codename der Consensus Layer ) und Amsterdam ( Codename der Execution Layer , gemäß der Tradition der Devcon-Gaststädte ) — wird von zwei zentralen EIPs getragen , die gemeinsam die Blockproduktion von Ethereum umgestalten sollen .

EIP-7732 ( ePBS ) trennt den Consensus-Block vom Execution-Block auf Protokollebene . Heute delegieren Validatoren , die MEV-Boost ausführen , den Blockaufbau über zentralisierte Relays an einen Marktplatz von Off-Protocol-Buildern . Flashbots' eigene Migration aller Builder und des Orderflows zu BuilderNet im Dezember 2024 war selbst ein Geständnis , dass die Relay-Architektur Konzentrationsrisiken schafft . ePBS verankert die Trennung im Protokoll : Proposer und Builder werden zu erstklassigen Protokollteilnehmern , die direkt interagieren , kein Relay erforderlich .

EIP-7928 ( Block-level Access Lists ) sorgt dafür , dass Blöcke ihren Lese- / Schreib-Footprint — berührte Konten und Speicherplätze — vorab deklarieren . Clients können dann die Ausführung und Verifizierung parallelisieren , wodurch die Zeit verkürzt wird , die ein Block in der Propagation verbringt . In Kombination mit ePBS zielt das Paar auf eine Reduzierung der effektiven Block-Latenz um ca . 50 % ab .

Auf dem Papier ergänzen sich diese sauber . In der Implementierung interagieren sie jedoch mit jedem anderen Teil des Post-Pectra-Stacks — einschließlich der EIP-7251 MaxEB-Validatoren-Konsolidierung , die bereits in Pectra ausgeliefert wurde — auf eine Weise , die in den ursprünglichen Spezifikationen nicht vollständig vorhergesehen wurde .

Was tatsächlich in Verzug geraten ist​

Der All Core Developers Consensus Call am 16 . April 2026 ( ACDC #177 ) machte die technische Realität deutlich . Bis zu diesem Monat war das Testen auf zwei separate Netzwerke aufgeteilt : epbs-devnet für die Proposer-Builder-Trennung und bals-devnet für Access-Listen . Das " generalisierte Devnet " , das sie zusammenführt — die erste Umgebung , in der jede Glamsterdam-Komponente koexistiert — wurde erst grünes Licht gegeben , nachdem Lighthouse und eine Handvoll anderer Consensus-Clients während des Interop-Fensters im April stabile Builds produziert hatten .

" ePBS Devnet Zero dreht sich weniger um Leistung als vielmehr um Interoperabilität " , bemerkte ein Client-Ingenieur in der Zusammenfassung des Calls . Übersetzung : Wir entdecken immer noch , was kaputt geht , wenn fünf Consensus-Clients und fünf Execution-Clients die Spezifikation jeweils unabhängig interpretieren . Frühe Durchläufe erzeugen meist leere Blöcke — kein struktureller Fehler , sondern ein Signal , dass der Idealfall gerade erst geebnet wird , ganz zu schweigen vom feindseligen Pfad .

Die Konsequenzen für den Zeitplan summieren sich :

  • Devnet Zero muss über Lighthouse , Prysm , Teku , Nimbus und Lodestar auf der Consensus-Seite sowie Geth , Nethermind , Besu , Erigon und Reth auf der Execution-Seite stabilisiert werden .
  • Devnet One und Two müssen Interaktionsfehler zwischen ePBS , BALs , Gas-Repricing und den über 25 weiteren EIPs aufdecken , die zur Debatte stehen .
  • Öffentliche Testnets ( Holesky-Nachfolger , Sepolia ) benötigen mindestens 6 - 8 Wochen Shadow-Fork-Aktivität , bevor ein Mainnet-Zieldatum glaubwürdig festgelegt werden kann .
  • Client-Releases müssen erstellt , auditiert und an Staker verteilt werden , und zwar mit genügend Vorlaufzeit , damit ein Fork-Choice-Problem im Mainnet nicht zu einem Liveness-Vorfall wird .

Jeder Schritt wird in Wochen gemessen , nicht in Tagen . Ein Start im Mai - Juni erforderte ein stabiles Devnet Zero im Februar . Das war nicht der Fall . Juni - Juli erforderte Stabilität im März . Das war nicht der Fall . Bis April geht die Rechnung einfach nicht auf — daher das stille Eingeständnis , dass der Haupt-Fork in das zweite Halbjahr 2026 rutscht .

Das Paradoxon der Client-Diversität​

Ethereums Execution-Diversität mit fünf Clients ist wohl seine wertvollste , glaubwürdig neutrale Eigenschaft — ein Fehler in einem einzelnen Client kann das Netzwerk nicht lahmlegen . Aber diese Diversität ist auch der Grund , warum Glamsterdam schwierig ist .

Jedes Implementierungsteam muss ePBS unabhängig bauen , testen und stabilisieren . Dabei treten jeweils unterschiedliche Randfälle auf . Das ACDC-Protokoll vom April beschreibt " ausstehende Pull-Requests " bei mehreren Clients und stellt fest , dass Änderungen an den Consensus-Specs das ePBS Devnet Two blockieren könnten , bis sie gelöst sind . Dies ist genau die Koordinationssteuer , die eine Chain mit nur einer Implementierung nicht zahlt .

Vergleichen Sie dies mit der Kadenz von Solana . Alpenglow , Solanas Konsens-Ersatz , der auf eine deterministische Finalität von 100 - 150 ms abzielt , wurde im September 2025 mit 98,27 % Unterstützung in einer Validatoren-Abstimmung angenommen — eines der stärksten Mandate in der Geschichte des Netzwerks . Der Rollout-Plan ist einfach : Anzas Agave-Client liefert das Upgrade im dritten Quartal 2026 aus ; Firedancer , die zweite Implementierung von Jump Crypto , folgt . Da Solana praktisch nur einen Produktions-Client hatte , bis Firedancer Anfang dieses Jahres einen Anteil von 20 % am Mainnet-Stake überschritt , ist der Koordinationsaufwand nur ein Bruchteil dessen von Ethereum .

Dies ist keine neutrale Beobachtung . Monolithische Ketten liefern schneller . Multi-Client-Ketten liefern sicherer . Die Verzögerung von Glamsterdam ist der Preis für Ethereums architektonische Entscheidung — und zum ersten Mal seit dem Merge wägt der Markt ab , ob dieser Preis es noch wert ist , gezahlt zu werden .

Was die Verzögerung für L2s und MEV bedeutet​

Der Pectra-Fork wurde 2025 termingerecht veröffentlicht. Fusaka fügte kurz darauf PeerDAS hinzu und erweiterte die Blob-Kapazität. L2-Teams entwickelten ihre Kapazitätspläne für 2026 basierend auf der Einführung von Glamsterdam im zweiten Quartal, wobei weitere Blob-Expansionen und MEV-Umverteilungen erwartet wurden, um die steigende Rollup-Nachfrage zu bedienen.

Diese Pläne müssen nun neu entworfen werden.

Blob-Pricing. Es wurde erwartet, dass Glamsterdam die Anzahl der Blobs pro Block weiter erhöht – potenziell auf 72 oder mehr – was optimistischen und ZK-Rollups deutlich mehr günstigeren Datenverfügbarkeitsraum verschafft hätte. Eine Verschiebung auf Q3 – Q4 bedeutet 2 – 4 weitere Monate mit einem knappen Blob-Angebot, was vor allem für Rollups relevant ist, die ihre Gebührenkorridore bereits gesättigt haben.

MEV-Umverteilung. Die heutige MEV-Boost-Architektur belohnt die größten Builder überproportional. Superlineare Erträge bei der Aggregation von Orderflows bedeuten, dass die Ökonomie in Richtung Monopol drängt, sobald ein Builder einen Vorsprung erlangt. ePBS eliminiert MEV nicht, entfernt aber den Relay als Koordinationsengpass – was theoretisch einen Bruchteil der heutigen Extraktion an Proposer und im weiteren Verlauf an Staker umverteilen sollte. Jeder Monat Verzögerung ist ein Monat, in dem die bestehenden MEV-Dynamiken fortbestehen.

L2-Wettbewerb. Base hat bereits Blockzeiten von 2 Sekunden erreicht. Arbitrum und Optimism liefern ihre eigenen Sequencer- und DA-Verbesserungen in unabhängigen Zyklen aus. Je länger der L1-Engpass fortbesteht, desto mehr weichen die L2-Roadmaps von einem einheitlichen L1-Upgrade ab – und desto mehr wird die „Rollup-zentrierte Roadmap“ zu N separaten Rollup-Roadmaps, die zufällig auf demselben Base-Layer abwickeln.

Die FOCIL-Frage und der Hegota-Squeeze​

Eine der folgenreichsten Entscheidungen des ACDC im April war die Verschiebung der Fork-Choice Inclusion Lists (FOCIL) aus Glamsterdam nach Hegota, wo sie offiziell als Headliner der Konsensschicht für Ende 2026 ausgewählt wurden.

FOCIL ist Ethereums Antwort auf Zensurresistenz – ein Mechanismus, der es einem Komitee von Proposern ermöglicht, die Aufnahme von Transaktionen kollektiv durchzusetzen, sodass kein einzelner Builder systematisch Payloads ausschließen kann (beispielsweise OFAC-sanktionierte Adressen). Das Engineering-Team von Base hatte öffentlich gewarnt, dass die Bündelung von FOCIL mit ePBS den Glamsterdam-Fork über das Jahr 2026 hinaus verzögern würde. Die Auslagerung verschafft dem Glamsterdam-Zeitplan Erleichterung – auf Kosten einer Komprimierung des Zeitfensters zwischen der eventuellen Mainnet-Aktivierung von Glamsterdam und der von Hegota.

Wenn Glamsterdam im Q4 2026 erscheint und Hegota das späte Q4 anvisiert, könnte die Lücke nur 6 – 8 Wochen betragen. Das ist eine kurze Zeitspanne für Validatoren, Block-Builder, Staking-Anbieter und L2-Teams, um eine Protokolländerung zu absorbieren, bevor die nächste eintrifft. Die Hegota-Roadmap beinhaltet auch bedeutende Arbeiten am State-Bloat – frühe Diskussionen konzentrierten sich auf Verkle Trees, die die Hardwareanforderungen für Nodes reduzieren würden, aber umfangreiche eigene Tests erfordern.

Das Szenario, auf das sich Ethereum nun im Stillen vorbereitet: zwei große Forks, die innerhalb eines Quartals landen, basierend auf einer Testmatrix, die Solana in einem einzigen koordinierten Release ausliefert.

Warum dies noch keine Krise ist – bis jetzt​

Es wäre ein Fehler, die Verzögerung von Glamsterdam als existenziell zu betrachten. Ethereums Fork-Prozess funktioniert genau wie geplant. ePBS wird nicht verzögert, weil die Koordination versagt hat, sondern weil die Koordination ein Problem erkannt hat – Unklarheiten in der Spezifikation und Edge-Cases bei der Implementierung –, bevor sie das Mainnet erreichten. Die Alternative, termingerecht zu liefern und Bugs in der Fork-Choice im Live-Betrieb bei einem abgesicherten Wert von über 400 Mrd. USD zu bekämpfen, wäre unermesslich schlimmer.

Die tiefergehende Frage ist, ob Ethereums aktueller Rhythmus nachhaltig ist, da die Komplexität pro Fork wächst. Glamsterdam besteht nicht nur aus zwei EIPs; es sind zwei Hauptfunktionen plus über 25 kleinere Änderungen, die jeweils mit einem Post-Pectra-Validatorenset interagieren, das bereits über MaxEB-Konsolidierung, PeerDAS-fähige Blobs und ein reifes L2-Ökosystem verfügt. Jeder neue Fork vergrößert die Testmatrix.

Vorschläge, Glamsterdam selbst aufzuteilen – BALs im Q3 und ePBS im Q1 2027 zu liefern – wurden in den Raum gestellt und bisher abgelehnt. Das Gegenargument ist überzeugend: BALs ohne ePBS liefern nur marginalen Wert, da die Gewinne aus der parallelen Ausführung durch die aktuelle Builder-Architektur gebremst werden. Die Funktionen ergänzen sich gegenseitig, und ihre Trennung würde zwar Zeit sparen, aber die Kohärenz des Upgrades gefährden.

Was in den nächsten 90 Tagen zu beachten ist​

Für Entwickler, Staker und alle, die L2-Blockplatz für die zweite Jahreshälfte 2026 kalkulieren, sind drei Signale entscheidend:

  1. Stabilität von Devnet Zero. Wenn das generalisierte Devnet bis Anfang Juni über 30 Tage ohne kritischen Vorfall läuft, wird ein Ziel für Q3 2026 glaubwürdig. Wenn nicht, ist Q4 die Untergrenze.
  2. Aktivierung öffentlicher Testnetze. Der Nachfolger von Holesky sowie Sepolia müssen mindestens 8 Wochen vor dem Mainnet forken. Kein Testnetz-Fork-Datum = kein Mainnet-Fork-Datum.
  3. Hegota EIP-Auswahl. Der Hegota-Headliner im Februar 2026 war FOCIL; der Headliner der Ausführungsschicht wird noch debattiert. Was auch immer gewählt wird, wird weiter einschränken, wie eng die beiden Forks aufeinanderfolgen können.

Ethereums Roadmap für 2026 – 2027 war schon immer ehrgeizig. Die Verzögerung von Glamsterdam ist die erste konkrete Erinnerung daran, dass ehrgeizig nicht gleichbedeutend mit pünktlich ist. Für ein Netzwerk, dessen Glaubwürdigkeit darauf beruht, schwierige Dinge sorgfältig zu erledigen, ist eine maßvolle Verzögerung kein Misserfolg. Sie ist das entscheidende Merkmal.

BlockEden.xyz betreibt Ethereum-Infrastruktur der Enterprise-Klasse über Pectra, Fusaka und jedes Testnetz, das die Fork-Regeln von Glamsterdam vorbereitet. Wenn Sie gegen ein sich bewegendes Upgrade-Ziel entwickeln und Nodes benötigen, die Mainnet, Testnetze und Devnets parallel verfolgen, erkunden Sie unsere Ethereum API-Dienste – Infrastruktur für Teams, die sich keinen Fork-Zustand auf der falschen Seite einer Spezifikationsänderung leisten können.

Quellen​

Share on Twitter