Warum Glamsterdam eines der bedeutendsten Upgrades nach dem Ethereum Merge sein könnte?
Verfasst von: KarenZ, Foresight News
Das Glamsterdam-Upgrade von Ethereum könnte leicht missverstanden werden als eine weitere bloße technische Iteration zur Erhöhung der Transaktionsgeschwindigkeit. Genau genommen geht es darum, den Blockprozess, den Verifizierungsprozess und die Preisgestaltung von Ressourcen in Ethereum neu zu ordnen, um höhere Gaslimits, größere Blob-Kapazitäten und die Grundlage für zukünftige parallele Ausführungen zu schaffen.
Bis zum 23. Juni 2026 wird ethereum.org Glamsterdam als Upgrade kennzeichnen, das in der zweiten Jahreshälfte 2026 geplant ist. Der Name Glamsterdam stammt aus der Kombination des Layer-Upgrade Amsterdam und des Konsens-Layer-Upgrades Gloas. Der offizielle Fahrplan positioniert es nach Fusaka im Dezember 2025 und vor Hegotá und listet zwei Hauptfunktionen klar auf: Trennung von Vorschlägen und Erstellern im Protokoll, also ePBS, sowie die blockbasierte Zugangsübersicht, also BAL.
Wer vorschlägt, wer baut: ePBS schreibt die Block-Aufgabenteilung ins Protokoll
Heute ist das Blockproduzieren in Ethereum wie ein sehr eng getakteter Schichtübergang: Jemand schlägt den Block vor, jemand bereitet die Inhalte der Transaktionen; dazwischen ist man außerdem auf außerprotokollare Infrastruktur angewiesen, etwa MEV-Boost und Third-Party-Relays (relays).
Dieses System läuft seit Jahren, aber es verlagert einen Teil der Vertrauensbeziehungen außerhalb des Protokolls – und es zwingt Validatoren, in einem sehr kurzen Zeitfenster gleichzeitig Aufgaben wie Konsens, Execution und Data Availability zu erledigen.
Eine der wichtigsten Änderungen bei Glamsterdam ist EIP-7732, also ePBS (Enshrined Proposer-Builder Separation). Dabei wird die Aufgabentrennung zwischen Proposer und Builder direkt ins Protokoll geschrieben.
Einfach gesagt: Der Proposer ist dafür verantwortlich, den Consensus-Block auszuwählen, und der Builder bereitet die Transaktionsinhalte darin vor. Der Builder kann nicht einfach mündlich zusagen: Zuerst muss er im Protokoll „eine Zusicherung“ hinterlegen – also klar festhalten, welchen Execution-Block er liefern wird und wie viel Geld er dem Proposer dafür zahlen möchte. Anschließend prüft das Payload Timeliness Committee (PTC), ob er die Lieferung rechtzeitig abliefert.
Der Kern dieser Änderung besteht nicht nur darin, die Abhängigkeit von Third-Party-Relays zu reduzieren, sondern auch darin, Zeit für Block-Propagation und Verifikation zu gewinnen.
Heute müssen Validatoren in einem sehr kurzen kritischen Zeitfenster sowohl Konsens als auch Execution verarbeiten. ePBS trennt diese beiden Aufgaben, sodass die Execution-Last später offengelegt und verifiziert werden kann. Nach dem Design von EIP-7732 kann sich das Verbreitungsfenster für die Execution-Last – also die verfügbare Zeit, in der Daten im Netzwerk verbreitet und von Knoten empfangen werden – etwa von 2 Sekunden auf ungefähr 9 Sekunden verlängern. Wenn das Fenster länger wird, ist Ethereum bei der Erhöhung der Blockkapazität deutlich weniger anfällig dafür, dass durch zu spätes Herunterladen, Verifizieren und Abstimmen Tickets verloren gehen oder Reorg-Risiken entstehen, weil Nodes nicht rechtzeitig nachkommen.
Für normale Nutzer ist das direkte Gefühl dafür vielleicht nicht groß, aber für das Scaling von Ethereum ist es entscheidend. Längere Propagation- und Verifikationsfenster bedeuten, dass das Netzwerk größere Lasten sicherer verarbeiten kann. In einem Bericht vom 16. Juni 2026 zitiert CoinDesk die Aussage des Ethereum-Foundation-DevOps-Ingenieurs Parithosh Jayanthi: Glamsterdam könnte seit dem Merge einer der größten Forks sein, der viele Annahmen über Ethereum verändern und die Grundlage für noch größere Skalierung in der Zukunft schaffen wird.
BAL und Re-Precing: Scaling darf nicht nur aufs Gas drücken, sondern muss auch die Datenbank im Griff behalten
Eine weitere zentrale Änderung in Glamsterdam ist EIP-7928, Block-Level Access Lists, also Access Lists auf Block-Ebene.
Man kann es sich vorstellen wie eine „Zugriffsaufzeichnung“ für jeden Block: Welche Konten und welche Speicherpositionen beim Ausführen des Blocks berührt werden, was danach für die relevanten States entsteht – all das muss aufgezeichnet werden. So muss ein Knoten beim Verarbeiten von Blöcken nicht mehr so tun, als würde er „blind“ aus der Box ziehen; er kann früher wissen, welche Daten gelesen werden müssen und welche Berechnungen parallel vorangetrieben werden können.
Das frühere EIP-2930 hat bereits transaction-level Access Lists eingeführt, aber es war optional und wurde in der Praxis nur begrenzt genutzt. Die Änderung in EIP-7928 besteht darin, die Access Lists auf Blockebene anzuheben: Im Block-Header bleibt ein „Fingerprint“ (Hash-Eintrag) dieser Liste, und die Execution-Last speichert die vollständige Liste. Wenn der Node den Block ausführt, prüft er, ob die in der Liste verzeichneten Zugriffe wirklich mit dem Ausführungsablauf des Blocks übereinstimmen; wenn nicht, ist der Block ungültig.
Warum ist das wichtig? Bei der Ausführung von Transaktionen auf Ethereum weiß man heute bei vielen Datenzugriffen erst dann, was tatsächlich passiert, wenn man genau bis zu diesem Schritt gekommen ist. Da der Knoten nicht weiß, ob eine Gruppe von Transaktionen gleichzeitig dasselbe Konto oder denselben Storage-Slot liest oder schreibt, ist es schwierig, sich auf eine parallele Verarbeitung verlassen zu können. BAL schreibt die Zugriffsspuren bei der Blockausführung explizit fest: Dadurch können Clients parallele Festplattenlesevorgänge, parallele Transaktionsverifikation und parallele Berechnungen von State Roots durchführen – und in manchen Szenarien auch dann, wenn nicht vollständig neu abgespielt wird, den State aktualisieren. Es ist nicht direkt der „Knopf“, der die Gebühren der Nutzer senkt, sondern es öffnet dem Client-Engineering Spielraum für Parallelisierung.
Aber die Scaling-Logik von Glamsterdam besteht nicht nur darin, „den Weg breiter zu machen“. Sie muss außerdem die langfristige Aufblähung der Ethereum-Datenbank in den Griff bekommen. EIP-8037 erhöht die Kosten für die Status-Erstellung und führt Kosten pro State-Byte CPSB ein. „State“ kann man als den Datenbankinhalt verstehen, den Ethereum dauerhaft speichern muss – etwa neue Konten, neue Contracts und neue Storage-Slots. Nach Abschluss der Transaktionsausführung ist es zwar vorbei, aber der State bleibt in dem Ledger, das alle Knoten pflegen müssen. Wenn State zu schnell wächst, wird das Betreiben von Nodes immer teurer, und die Dezentralisierung wird schrittweise verdrängt.
Die Hintergrundzahlen, die EIP-8037 liefert, sind sehr anschaulich: Stand Januar 2026 hat eine ausschließlich für State zuständige Geth-Node-Datenbank ungefähr 390 GiB; nachdem der Mainnet-Gas-Limit von 30 Millionen auf 60 Millionen erhöht wurde, stieg das täglich neu hinzukommende State-Volumen von etwa 105 MiB auf etwa 326 MiB – das entspricht einer jährlichen Zunahme von rund 116 GiB. Bei einer proportionalen Hochrechnung bei 200 Millionen Gas-Limit könnte das jährliche State-Wachstum etwa 387 GiB erreichen und innerhalb von weniger als einem Jahr die Performance-Verschlechterungs-Schwelle von 650 GiB überschreiten.
EIP-8037 will also genau das: „vorübergehende Berechnungen“ und „dauerhafte Belegung der Datenbank“ getrennt bepreisen. Neue State-Daten werden teurer, weil sie nicht nur einmalige Berechnungskosten verursachen, sondern eine langfristige Speicherbelastung für das Netzwerk bedeuten.
Auch Vitalik Buterin erwähnte bei der Erläuterung der Glamsterdam-Scaling-Route, dass Glamsterdam die Kosten für die Status-Erstellung aus den Kosten für Execution und Calldata herauslöst: Ziel ist, die Execution-Kapazität deutlich stärker ausweiten zu können, während das Status-Volumen nicht im gleichen Tempo weiter ansteigt.
Betrachtet man es gemeinsam, ermöglicht BAL den Knoten, Blöcke leichter parallel zu verarbeiten – damit wird das Problem „schneller laufen“ gelöst. Die Neupreisung der Status-Erstellung sorgt dafür, dass Operationen, die die Datenbank langfristig binden, höhere Kosten haben – damit wird das Problem „nicht das Kassenbuch immer weiter aufblähen“ gelöst. Das Scaling von Glamsterdam ist also keine schlichte Erhöhung des Gas-Limits, sondern eine Frage, die realitätsnäher ist: Kann Ethereum mehr Transaktionen verarbeiten, ohne dass sich der Druck durch Block-Propagation, Transaktionsverifikation und State-Speicherung außer Kontrolle gerät?
Glamsterdam EIP-Liste nimmt Gestalt an: Was ist bereits festgelegt, was wartet noch?
Stand 23. Juni 2026: Laut den auf Forkcast verfolgten Inhalten zu Ethereum-Upgrades testen derzeit Ethereum-Entwickler das Glamsterdam-Upgrade in Devnets. Am 3. August geht es auf Sepolia live, und am 16. September im Mainnet (konkrete Zeitpunkte können sich ändern).
Aktuell sind 10 EIPs für die Aufnahme in die Glamsterdam-Liste vorgesehen:
EIP-7708 (ETH-Überweisungen lösen ebenfalls Logs aus, damit native ETH-Überweisungen leichter indiziert und nachvollzogen werden können)
EIP-7732 (ePBS: Die Aufgabenteilung zwischen Proposer und Builder wird in das Protokoll geschrieben, wodurch die Abhängigkeit von Relays außerhalb des Protokolls sinkt)
EIP-7778 (Gas-Refunds werden abgeschafft; die Block-Gasbuchhaltung wird vereinfacht)
EIP-7843 (neuer SLOTNUM-Opcode, damit Contracts die aktuelle Slot-Nummer auslesen können)
EIP-7928 (Block-Level Access Lists, BAL: zeichnet die Konten und Speicherpositionen auf, die bei der Ausführung in einem Block besucht wurden, um den Weg für parallele Verifikation zu ebnen)
EIP-7954 (Erhöhung der Obergrenze für die maximale Contract-Größe, damit größere Contract-Bytecodes möglich sind)
EIP-7976 (Erhöhung der Calldata-Floor-Kosten; Anpassung der minimalen Kosten für Calldata)
EIP-7981 (Erhöhung der Kosten von Access Lists; Neuausrichtung der Gas-Preisgestaltung für Access Lists)
EIP-8024 (rückwärtskompatible SWAPN-, DUPN- und EXCHANGE-OpCodes, Erweiterung der Fähigkeiten für EVM-Stack-Operationen)
EIP-8037 (Erhöhung der Gas-Kosten für Status-Erstellung; Eindämmung einer zu schnellen Aufblähung der State-Datenbank)
Diese EIPs lassen sich grob in drei Gruppen einteilen: Erstens Änderungen an Block-Production- und Verifikationsprozessen, mit EIP-7732 und EIP-7928 als Kern; zweitens Anpassungen der Ressourcenpreisgestaltung, darunter EIP-7778, EIP-7976, EIP-7981 und EIP-8037; drittens Änderungen an EVM und der Developer Experience, darunter EIP-7708, EIP-7843, EIP-7954 und EIP-8024.
Anders gesagt: Glamsterdam ändert nicht nur einen einzelnen Funktionspunkt, sondern baut gleichzeitig Block-Work-Sharing, parallele Verifikation, Gas-Preisgestaltung und EVM-Verwendbarkeit aus.
Eine weitere Reihe von EIPs ist weiterhin in der Liste „zur Prüfung / in Betracht gezogen“:
EIP-2780 (intrinsic Gas auf Basis von Ressourcen auf Transaktionen aufteilen)
EIP-7610 (Rollback bei der Erstellung von Contracts in nicht leeren Storage-Accounts)
EIP-7688 (zukunftssichere Konsens-Layer-Datenstrukturen)
EIP-7904 (Gas-Kostenanalyse; möglicherweise wird es aus Glamsterdam herausgenommen)
EIP-7975 (eth/70: teilweise Block-Receipt-Listen)
EIP-7997 (deterministische Factory-Contracts)
EIP-8038 (Update der Gas-Kosten für Statuszugriffe)
EIP-8045 (schließt bereits bestrafte, verifikationierte Validatoren davon aus, weiterhin Blöcke vorzuschlagen)
EIP-8061 (Erhöhung von Exit- und Merge-Churn)
EIP-8070 (eth/72: Sparse Blobpool)
EIP-8080 (Exit nutzt eine consolidation queue)
EIP-8136 (cell-level deltas für das Broadcasten von Daten)
EIP-8159 (eth/71: Austausch von Block-Access-Listen)
EIP-8246 (Entfernung von SELFDESTRUCT burn)
EIP-8282 (Builder Execution Requests: stellt ePBS-Buildern eigene Registrierungs- und Exit-Requests bereit)
Außerdem führt Forkcast derzeit EIP-8254 (Beschränkung der Anzahl von deposit requests in einem Execution-Layer-Block auf 8192) als „Empfehlung zur Aufnahme“ in der Liste.
Aus Sicht der Staker ist vor allem EIP-8061 und EIP-8080 in der Liste besonders erwähnenswert. Für Staker bedeutet das, dass sich die Liquidität beim Exit möglicherweise verbessern kann. Figment sagte in einem Artikel vom 5. Mai 2026, dass institutionelle Staker vor allem ePBS, EIP-8061 und EIP-8080 im Blick haben müssen. Außerdem schätzte Figment, dass bei einem geschätzten Staking-Volumen von rund 38,9 Millionen ETH per April 2026 EIP-8061 das Exit-churn limit von 256 ETH/Epoch auf etwa 1187 ETH/Epoch erhöhen kann, während EIP-8080 es normalen Exits ermöglicht, die freie Kapazität der Merge-Queue zu nutzen. Figment erinnert zudem daran, dass alle Zahlen vor dem Go-Live im Mainnet als Spekulation zu betrachten sind.
Quelle: Figment
Das Protokoll wird aktualisiert – und auch in der Foundation gibt es personelle Veränderungen
Die technische Vorbereitung von Glamsterdam und die personellen Veränderungen innerhalb der Protocol-Cluster-Struktur der Ethereum-Foundation geschahen fast zeitgleich. In dem Ethereum-Foundation-Blogbeitrag vom 11. Mai 2026 heißt es, Glamsterdam habe mehrere Meilensteine erreicht: Ein Floor-Ziel von 200 Millionen Gas-Limit wurde als verlässliches Post-Glamsterdam-Ziel etabliert, ePBS läuft stabil in mehreren Clienten im Glamsterdam-Devnet, und EIP-8037 wurde finalisiert.
In demselben Artikel wurde auch der Führungswechsel im Protocol cluster angekündigt: Will Corcoran, Kev Wedderburn und Fredrik werden neue Koordinatoren des Protocol-Clusters. Der bisherige Koordinator Barnabé Monnot und Tim Beiko verlassen die Ethereum-Foundation, und Alex Stokes ist im Urlaub.
Die Aufgabenteilung der drei neuen Koordinatoren beschreibt die Foundation so: Will Corcoran hat Erfahrung in der Koordination über Teams hinweg; Kev Wedderburn leitet das zkEVM-Team; Fredrik leitet Protocol Security und das Projekt Trillion Dollar Security.
Diese Veränderung hat nicht nur im Protokollteam stattgefunden. Am 18. Juni 2026 veröffentlichte Hsiao-Wei Wang einen Beitrag, in dem er nach seinem Urlaub beschloss, die Position als Co-Executive Director der Ethereum-Foundation sowie als Mitglied des Vorstands niederzulegen
Der frühere EF-Researcher Dankrad Feist sagte am 19. Juni 2026, dass diejenigen, die EF verlassen, CROPS-Glaubensrichtungen seien (Anti-Censorship, Anti-Capture, Open Source, Privacy, Security). Das Problem liege nicht in der Strategie, sondern im Management – und diese Personalabwanderung sei eher eine leicht negative Entwicklung für Ethereum. Azeem, Mitgründer von Miden, interpretierte es aus entgegengesetzter Sicht: EF sei schwer dazu in der Lage, sich selbst stark zu verändern; nach dem Abfluss von Talenten könnten sich neue Organisationen bilden, die die Ethereum-Roadmap umsetzen – langfristig sogar ein Netto-Plus für das Ökosystem.
Die interne Darstellung der Ethereum-Foundation wirkt eher wie das Ziehen einer klaren Grenze. Der vorläufige Co-Executive Director der Ethereum-Foundation, Bastian Aue (Aerugo), erklärte: Zu den Gründen für den Austritt von EF-Mitgliedern gehören strategische Differenzen, die Passung der Position, normale organisatorische Veränderungen oder persönliche Entscheidungen. Die EF wird keine persönlichen Personalangelegenheiten in sozialen Medien diskutieren, aber betont, dass für die Ausgetretenen ein würdiger Abschied gewährleistet sein sollte.
Die Ethereum-Foundation liefert anschließend mit einem offiziellen Twitter-Thread eine klarere Organisations-Erzählung: Um das Potenzial von Ethereum zu erreichen, braucht es ein Bündnis mehrerer Organisationen. In dem vergangenen Jahr haben bereits mehrere Organisationen gemeinsam dazu beigetragen, die Robustheit des Ökosystems und dessen Fähigkeiten zu stärken. Beispiele, die die EF nennt, sind ethlabs (ein gemeinnütziges Forschungs-Labor, das sich auf die nächste Phase der Ethereum- und ETH-Adoption konzentriert), das am 23. Juni angekündigt wurde; sowie die Eth Apps Guild, die im April 2026 gestartet wurde (für die echte Nutzung von Ethereum-nativen Anwendungen, mit besonderem Fokus auf aufstrebende Märkte). Außerdem nennt die EF das im Jahr 2026 gestartete Ethereum Economic Zone-Projekt (Ziel ist, Fragmentierung im Ökosystem durch synchronisierbare Komponierbarkeit und Zero-Knowledge-Echtzeitbeweise zu reduzieren) und Argot, das 2025 gegründet wurde (eine autonome Gruppe von Ingenieuren und Forschern, die Solidity sowie Open-Source-Compiler-Tools pflegt).
Dieser offizielle Thread macht die jüngsten Veränderungen der Ethereum-Foundation leichter verständlich: Die Foundation stößt nicht nur einfach Menschen und Projekte nach außen, und sie gibt auch nicht die zentrale Koordination auf. Stattdessen könnte sie dabei sein, die Ethereum-Roadmap in mehrere Organisationen aufzuteilen, die sie gemeinsam übernehmen.
Kurzfazit
Darum sollte Glamsterdam nicht nur als eine Sammlung von EIPs betrachtet werden. Es ist ein Engineering-Umbau in Ethereum vor einer höheren Durchsatzstufe: Wer baut die Blöcke, wer schlägt sie vor, wer verifiziert, welche Daten langfristig gespeichert werden müssen und welche Ressourcen teurer werden sollen – all das wird neu auf den Tisch gelegt.
Die Schlüsselwörter für die technische Route sind ePBS, BAL und der Start für mehrdimensionales Gas; die Schlüsselwörter der organisatorischen Route sind viel realistischer: Kann die Ethereum-Foundation ihre Koordinationskraft aufrechterhalten – und können neue Organisationen außerhalb der Foundation diese Koordinationskraft in eine dauerhaft lieferbare Arbeit übersetzen?
Referenz:
https://forkcast.org/upgrade/glamsterdam/
https://ethereum.org/roadmap/glamsterdam/
https://blog.ethereum.org/2026/05/11/protocol-update-may-26
https://x.com/VitalikButerin/status/2027403360484430122