Glamsterdam-Upgrade, Ethereums L1-Skalierungslösung

Original | Odaily Planet Daily jk

Das bevorstehende Glamsterdam-Upgrade für Ethereum gilt unter den Kernentwicklern als die größte Umstrukturierung des Protokolls seit dem Merge. Der Name setzt sich aus zwei Teilen zusammen: Das Upgrade der Ausführungsschicht behält den Namen „Amsterdam“ bei, benannt nach dem Ort früherer Devconnect-Veranstaltungen; das Upgrade der Konsensschicht trägt den Namen „Gloas“, nach einem Stern. Nach dem vorherigen Fusaka-Upgrade verbessert Glamsterdam die Skalierbarkeit der Schicht 1, indem es die Transaktionsverarbeitung und die Verwaltung der wachsenden Datenbank im Netzwerk neu organisiert und damit die Art und Weise, wie Ethereum Blöcke erstellt und verifiziert, grundlegend aktualisiert.

Dieses Upgrade konzentriert sich auf drei Kernziele:

• Beschleunigte Verarbeitung (Parallelisierung): Die Art und Weise, wie das Netzwerk Datenabhängigkeiten aufzeichnet, wird neu organisiert. Dadurch kann eine große Anzahl von Transaktionen gleichzeitig sicher verarbeitet werden, anstatt sie langsam einzeln zu verarbeiten.
• Skalierbarkeit: Die hohe Arbeitslast der Blockgenerierung und -verifizierung wird aufgeteilt, wodurch das Netzwerk mehr Zeit hat, größere Datenmengen zu verbreiten, ohne sich zu verlangsamen.
• Nachhaltigkeit: Anpassung der Netzwerkgebühren, um die langfristigen Hardwarekosten für die Speicherung neuer Daten genau widerzuspiegeln, wodurch Hindernisse für zukünftige Erhöhungen der Gaslimits beseitigt und gleichzeitig eine Beeinträchtigung der Hardwareleistung vermieden wird.

Die beiden wichtigsten Neuerungen des Upgrades konzentrieren sich auf die Konsensschicht und die Ausführungsschicht:

Es gibt zwei wichtige Headliner-Vorschläge. Quelle: Ethereum

Hauptvorschlag Nr. 1: ePBS, Umwandlung von „ausgelagerten Vermittlern“ in „eingebaute Regeln“

Zunächst wollen wir den wichtigsten Vorschlag für die Konsensschicht besprechen, die innerhalb des Protokolls zwischen Proposern und Buildern unterscheidet und im Englischen als ePBS (EIP-7732) abgekürzt wird.

Jedes Mal, wenn Ethereum einen Block erzeugt, sind zwei Schritte erforderlich: Eine Person wählt den Block aus (der Vorschlagende), während eine andere die Transaktionen im Block zusammenstellt (der Blockbauer). Diese Arbeitsteilung ist im Ethereum-Protokoll selbst nicht festgelegt, sondern basiert auf externen Dienstleistern (sogenannten Relays), die den Prozess unterstützen. Diese externe Komponente führt auch während der Blockverifizierung zu einem Engpass: Validatoren müssen Transaktionen innerhalb eines kurzen Zeitfensters von zwei Sekunden senden und ausführen, was die Datenmenge, die das Netzwerk verarbeiten kann, begrenzt. Dies ist vergleichbar mit einem Restaurant, in dem Bestellung und Zubereitung von Speisen von einem externen Koordinator abhängen. Fällt dieser Koordinator aus, kann es zu Problemen zwischen Küche und Service kommen.

ePBS integriert die Arbeitsteilung zwischen Bestellung und Zubereitung direkt in das Betriebshandbuch des Restaurants und verzichtet somit auf externe Dienstleister. Dadurch wird ein vertrauenswürdiger On-Chain-Block-Liefer- und Zahlungsmechanismus direkt in das Protokoll integriert, wodurch Middleware von Drittanbietern überflüssig wird. Sollten beide Parteien jedoch komplexere, noch nicht im Protokoll spezifizierte Funktionen nutzen wollen, können sie weiterhin auf externe Dienstleister zurückgreifen. Um Chaos während der Lieferung zu vermeiden, hat ePBS ein „Gericht-Verifizierungsteam“ eingerichtet, das überprüft, wer die Bestellung aufgegeben hat und ob das Gericht rechtzeitig zubereitet wurde. Dadurch verlängert sich das ursprüngliche Lieferzeitfenster von 2 Sekunden auf etwa 9 Sekunden. Das Restaurant kann so mehr Bestellungen gleichzeitig bearbeiten, wodurch Ethereum mehr Daten für Layer 2 verarbeiten kann.

Zweiter Vorschlag für die Hauptrolle: BALs, Erstellen einer „Einkaufsliste“ vor der Abreise

Als nächstes wollen wir den wichtigsten Vorschlag für die Ausführungsschicht besprechen, nämlich eine Block-Level-Zugriffsliste, abgekürzt BALs (EIP-7928).

Aktuell ähnelt die Transaktionsverarbeitung bei Ethereum dem Einkaufen im Supermarkt mit geschlossenen Augen: Man muss erst nach einem Artikel tasten, ihn identifizieren und dann entscheiden, wie man vorgeht. Dadurch wird jeder Artikel einzeln verarbeitet. Da das System nicht im Voraus weiß, welche Daten eine Transaktion verwendet, beispielsweise welche Konten beteiligt sind, muss es Transaktionen strikt der Reihe nach abarbeiten. Andernfalls könnten zwei Transaktionen versehentlich versuchen, dieselben Daten (wie den Kontostand derselben Adresse) zu ändern, was zu Konflikten führen würde.

BALs ermöglichen es dieser Person, vor dem Einkaufsbummel eine Einkaufsliste zu erhalten, die klar angibt, welche Regale aufzusuchen und welche Artikel sie mitnehmen soll. Anhand dieser Liste kann das System im Voraus erkennen, welche Transaktionen sich nicht überschneiden. Dadurch können nicht zusammenhängende Transaktionen gruppiert und parallel verarbeitet werden, anstatt sie einzeln in die Warteschlange zu stellen. Diese Liste bietet einen weiteren Vorteil: Wenn neue Knoten dem Netzwerk beitreten, können sie die in dieser Liste gespeicherten Endergebnisse direkt kopieren, ohne alle komplexen historischen Transaktionen neu berechnen zu müssen. Dies beschleunigt den Synchronisierungsprozess für neue Knoten erheblich. Um die Verbreitung dieser Liste im Netzwerk zu erleichtern, hat Glamsterdam außerdem ein entsprechendes Upgrade des Übertragungsprotokolls bereitgestellt, das es Knoten ermöglicht, diese Zugriffslisten gemeinsam zu nutzen. Dies ist nun eine obligatorische Voraussetzung für alle Clients der Ausführungsschicht.

Unterstützende Vorschläge: Neubewertung von „weltraumbelegenden“ Operationen

Zusätzlich zu diesen beiden Hauptvorschlägen hat Glamsterdam auch zwei unterstützende Vorschläge zur Neupreisgestaltung eingereicht, die als Anpassung der Preisliste für die „Speichergebühren“ und „Abfragegebühren“ des Netzwerks verstanden werden können.

• Der erste Vorschlag betrifft Vorgänge wie die Erstellung neuer Konten und die Bereitstellung von Verträgen, die dauerhaft Speicherplatz im Netzwerk belegen. Bisher waren die Gebühren nicht proportional zum tatsächlich belegten Speicherplatz; künftig werden sie pro belegter Speicherplatzeinheit berechnet. Ziel ist es, das Datenwachstum des Netzwerks auf ein sicheres und vorhersehbares Niveau von 120 GiB pro Jahr zu begrenzen und so den Betrieb des Netzwerks auf herkömmlicher Hardware zu gewährleisten. Diese Speichergebühr wird zudem separat ausgewiesen und nicht mehr mit den Rechengebühren für die Transaktionsverarbeitung vermischt. Solange Entwickler bereit sind, etwas höhere Speichergebühren zu zahlen, können sie weiterhin größere und komplexere Anwendungen bereitstellen, ohne unmittelbar durch das Gaslimit eingeschränkt zu werden.
• Der zweite Vorschlag betrifft Operationen wie das Abfragen und Lesen vorhandener Daten im Netzwerk, die bisher zu günstig waren und mit den tatsächlichen Abfragekosten bei steigendem Datenvolumen nicht Schritt hielten. Die Preisstandards für diese Operationscodes werden nun angehoben, um die reale Auslastung moderner Hardware besser widerzuspiegeln und gleichzeitig zu verhindern, dass Einzelpersonen die niedrigen Gebühren ausnutzen, um das Netzwerk absichtlich mit übermäßigen Abfragen zu überlasten.

Starttermin des Hauptnetzes: Noch nicht festgelegt

Glamsterdam befindet sich hinsichtlich des Zeitplans aktuell in einer heiklen Phase. Offiziell fand am 16. Juli das 241. Treffen aller Kernentwickler der Ausführungsschicht (ACDE) statt. Hauptthemen der Tagesordnung waren Updates zur Glamsterdam-Entwicklungsnetzphase und die Auswahl der wichtigsten Vorschläge für das nächste Upgrade, Hegota. Ein in der Branche weit verbreiteter Zeitplan sieht vor, dass die Entwicklungsnetzphase acht Iterationen (0 bis 7) durchläuft, die vom 28. März 2026 bis zum 8. Juli 2026 dauern. Darauf folgen die ursprünglich für den 3. August 2026 geplanten Testnetz-Forks Sepolia und Hoodi (ursprünglich für den 17. August 2026 geplant). Die Aktivierung des Hauptnetzes ist für den 16. September 2026 vorgesehen.

Der ursprüngliche Zeitplan galt für das erste Halbjahr 2026. Quelle: Ethereum

Aufgrund der jüngsten Entwicklungen dürfte sich dieser Zeitplan jedoch verschoben haben. Das EthPandaOps-Team hat kürzlich ein neues Testnetz namens Plataberget gestartet, das erste kurzfristige öffentliche Testnetz speziell für Glamsterdam. Die offiziellen Bereitstellungen von Sepolia und Hoodi werden sich voraussichtlich bis September verzögern, und der geplante Start des Hauptnetzes wurde entsprechend auf das vierte Quartal 2026 verschoben. Dies ist bereits die zweite Verschiebung des Glamsterdam-Zeitplans, nachdem er zuvor vom ursprünglich geplanten ersten Halbjahr 2026 verschoben wurde. Die Kernentwickler haben wiederholt betont, dass die Korrektheit des Upgrades Vorrang vor der Einhaltung eines bestimmten Datums hat. Daher ist es möglich, dass wir das Upgrade erst im vierten Quartal oder sogar erst Ende des Jahres sehen werden, solange die genaue Blockhöhe nicht im Rahmen des formellen ACD-Meetings festgelegt ist.