Glamsterdam Upgrade: Die Antwort auf die L1-Skalierung von Ethereum

Original  Odaily Planet Daily jk

Das bevorstehende Glamsterdam-Upgrade von Ethereum ist die größte Protokollumstrukturierung aus Sicht der Kernentwickler seit The Merge. Der Name setzt sich aus zwei Teilen zusammen: Der Teil des Ausführungsschicht-Upgrades behält den Namen "Amsterdam", benannt nach dem Veranstaltungsort von Devconnect; der Teil des Konsensschicht-Upgrades wird "Gloas" genannt, nach einem Stern. Nach dem vorherigen Fusaka-Upgrade fördert Glamsterdam die L1-Skalierung, indem es die Art und Weise, wie das Netzwerk Transaktionen verarbeitet und seine ständig wachsende Datenbank verwaltet, neu strukturiert, und aktualisiert grundlegend, wie Ethereum Blöcke erstellt und validiert.

Dieses Upgrade konzentriert sich auf drei Hauptziele:

• Beschleunigung der Verarbeitung (Parallelisierung): Umstrukturierung der Art und Weise, wie das Netzwerk Datenabhängigkeiten aufzeichnet, sodass es sicher eine große Anzahl von Transaktionen gleichzeitig verarbeiten kann, anstatt sie langsam nacheinander zu bearbeiten.
• Skalierung: Aufteilung der schweren Aufgaben der Blockerstellung und -validierung, damit das Netzwerk mehr Zeit hat, größere Datenmengen zu verbreiten, ohne langsamer zu werden.
• Nachhaltigkeit: Anpassung der Netzwerkgebühren, um die langfristigen Hardwarekosten für die Speicherung neuer Daten genau widerzuspiegeln, um zukünftige Erhöhungen der Gasobergrenze zu erleichtern und gleichzeitig eine Verschlechterung der Hardwareleistung zu vermeiden.

Die beiden Hauptvorschläge des Upgrades betreffen die Konsens- und die Ausführungsschicht:

Es gibt zwei große Headliner-Vorschläge. Quelle: Ethereum

Headliner-Vorschlag 1: ePBS, "Externe Vermittler" in "Integrierte Regeln" umwandeln

Zuerst der Headliner-Vorschlag der Konsensschicht, der die Trennung von Vorschlagenden und Erbauenden innerhalb des Protokolls vorschlägt, kurz ePBS (EIP-7732).

Bei jeder Blockerstellung in Ethereum gibt es eigentlich zwei Schritte: Eine Person ist dafür verantwortlich, "welchen Block auszuwählen" (Vorschlagender), und eine andere Person ist dafür verantwortlich, "die Transaktionen im Block tatsächlich zusammenzustellen" (Erbauer). Derzeit ist diese Aufgabenteilung nicht im Ethereum-Protokoll selbst festgelegt, sondern hängt von einer Reihe von externen "Vermittlungsunternehmen" (auch als Relays bekannt) ab, die die Koordination übernehmen. Diese externe Beziehung verursacht während der Blockvalidierung einen Engpass, der die Validierer zwingt, innerhalb eines engen Zeitfensters von 2 Sekunden hastig Transaktionen zu übertragen und auszuführen, was die Menge an Daten, die das Netzwerk verarbeiten kann, einschränkt. Man könnte sagen, es ist wie in einem Restaurant, wo die Bestellung und das Kochen von einem externen Koordinator abhängen; wenn dieser Koordinator versagt, können Küche und Service nicht übereinstimmen.

Was ePBS tut, ist, diese "Bestellung-Kochen"-Aufgabenteilung in das Betriebsregelwerk des Restaurants zu schreiben, sodass es nicht mehr auf externe Koordinatoren angewiesen ist. Dadurch wird ein vertrauenswürdiger Mechanismus für die Blockübergabe und Zahlung direkt im Protokoll selbst integriert, sodass keine Drittanbieter-Middleware mehr benötigt wird. Wenn die Parteien jedoch einige komplexe Funktionen nutzen möchten, die im Protokoll noch nicht festgelegt sind, können sie weiterhin externe Koordinatoren verwenden. Um die "Übertragung"-Phase nicht chaotisch zu gestalten, hat ePBS auch eine "Gerichtskontrollgruppe" eingerichtet, die überprüft, "wer die Bestellung aufgegeben hat" und "ob das Gericht rechtzeitig serviert wurde". Das ursprüngliche Zeitfenster von 2 Sekunden für die Übertragung wurde auf etwa 9 Sekunden erweitert, sodass das Restaurant mehr Bestellungen gleichzeitig bearbeiten kann, was bedeutet, dass Ethereum mehr Daten für Layer2 verarbeiten kann.

Headliner-Vorschlag 2: BALs, die "Einkaufsliste" vor der Abreise erstellen

Nun zum Headliner-Vorschlag der Ausführungsschicht, der blockbasierten Zugriffslisten, kurz BALs (EIP-7928).

Derzeit funktioniert die Art und Weise, wie Ethereum Transaktionen verarbeitet, ein wenig wie eine Person, die mit verbundenen Augen in den Supermarkt geht: Sie muss zuerst ein Produkt ertasten und bestätigen, was es ist, bevor sie entscheiden kann, wie es weitergeht, sodass sie nur nacheinander anstehen kann. Da nicht im Voraus bekannt ist, welche Daten eine Transaktion benötigt, z. B. welche Konten betroffen sind, muss das System die Transaktionen strikt in der Reihenfolge verarbeiten, andernfalls könnten zwei Transaktionen versehentlich gleichzeitig versuchen, dieselben Daten (z. B. den Kontostand derselben Adresse) zu ändern, was zu Konflikten führt.

BALs ermöglichen es dieser Person, vor der Abreise eine Einkaufsliste zu erhalten, auf der klar steht, "zu welchen Regalen ich gehen und welche Artikel ich nehmen soll". Mit dieser Liste kann das System im Voraus erkennen, welche Transaktionen sich nicht gegenseitig "behindern", sodass es nicht verwandte Transaktionen in Gruppen aufteilen und parallel verarbeiten kann, anstatt sie nacheinander abarbeiten zu müssen. Diese Liste hat auch einen zusätzlichen Vorteil: Wenn neue Knoten dem Netzwerk beitreten, können sie direkt die endgültigen Ergebnisse, die in dieser Liste aufgezeichnet sind, übernehmen, ohne alle komplexen historischen Transaktionen erneut berechnen zu müssen, was den Synchronisierungsprozess neuer Knoten erheblich beschleunigt. Um sicherzustellen, dass diese Liste tatsächlich im Netzwerk zirkuliert, hat Glamsterdam auch ein begleitendes Upgrade des Übertragungsprotokolls integriert, das es Knoten ermöglicht, diese Zugriffslisten tatsächlich zu teilen; dieses Übertragungsprotokoll ist mittlerweile eine zwingende Anforderung für alle Clients der Ausführungsschicht.

Begleitvorschläge: Neuverrechnung von "Platz beanspruchenden" Operationen

Neben diesen beiden Hauptvorschlägen hat Glamsterdam auch zwei begleitende Vorschläge zur Neupreisgestaltung integriert, die als Anpassung der "Lagergebühren" und "Abfragegebühren" des Netzwerks verstanden werden können.

• Der erste Vorschlag betrifft Operationen wie das Erstellen von Konten und das Bereitstellen von Verträgen, die im Netzwerk "dauerhaft Platz beanspruchen". Die bisherigen Gebühren standen nicht im Verhältnis zu dem tatsächlich beanspruchten Speicherplatz; jetzt wird die Abrechnung nach "jeder beanspruchten Einheit Speicherplatz" neu berechnet, mit dem Ziel, das gesamte Datenwachstum des Netzwerks auf ein sicheres, vorhersehbares Niveau von 120 GiB pro Jahr zu kontrollieren, um sicherzustellen, dass das Netzwerk auch mit gewöhnlicher Hardware weiterhin betrieben werden kann. Diese Lagergebühr wird separat in einem Konto abgerechnet und nicht mehr mit den Berechnungskosten für die Verarbeitung von Transaktionen vermischt. Solange die Entwickler bereit sind, etwas mehr Lagergebühren zu zahlen, können sie weiterhin größere und komplexere Anwendungen bereitstellen, ohne von der Gesamt-Gasobergrenze blockiert zu werden.
• Der zweite Vorschlag betrifft Operationen wie das Abfragen und Lesen bereits vorhandener Daten im Netzwerk, deren Preisgestaltung in der Vergangenheit zu niedrig war, um den tatsächlichen Abfragekosten nach dem Anstieg des Datenvolumens gerecht zu werden; diesmal wird der Preis für diese Operationen erhöht, um näher an den realen Belastungen moderner Hardware zu liegen, und um zu verhindern, dass jemand die zu niedrigen Gebühren ausnutzt, um das Netzwerk mit einer großen Anzahl von Abfragen zu überlasten.

Zeitplan für den Mainnet-Start: Derzeit noch nicht festgelegt

In Bezug auf den Zeitplan befindet sich Glamsterdam derzeit in einer ziemlich heiklen Phase. Offiziell fand die letzte überprüfbare Sitzung aller Kernentwickler der Ausführungsschicht (ACDE) die 241. Sitzung am 16. Juli statt, bei der die Hauptagenda die neuesten Fortschritte im Glamsterdam Devnet-Phase sowie die Auswahl der Headliner-Vorschläge für das nächste Upgrade Hegota umfasste. Eine zuvor in der Branche weit verbreitete Zeitplanung zeigte, dass die Devnet-Phase insgesamt acht Iterationen von 0 bis 7 durchlaufen hat, mit einem Zeitraum vom 28. März 2026 bis zum 8. Juli, gefolgt von einem geplanten Fork des Sepolia-Testnets am 3. August 2026 und einem geplanten Fork des Hoodi-Testnets am 17. August 2026; das Ziel für die Aktivierung des Mainnets ist der 16. September 2026.

Ursprünglich war der Zeitplan für das erste Halbjahr 2026. Quelle: Ethereum

Aber nach den neuesten Entwicklungen wurde dieser Zeitplan höchstwahrscheinlich verschoben. Das EthPandaOps-Team hat kürzlich ein neues Testnetz namens Plataberget eingeführt, das speziell für Glamsterdam entwickelt wurde und das erste kurzfristige öffentliche Testnetz ist. Die offiziellen Bereitstellungen von Sepolia und Hoodi werden voraussichtlich bis September verzögert, und das Ziel für den Mainnet-Start wurde entsprechend auf das vierte Quartal 2026 verschoben. Dies ist das zweite Mal, dass Glamsterdam nach der ursprünglichen Verschiebung von der ersten Jahreshälfte 2026 einen Termin verschiebt. Die Kernentwickler haben mehrfach betont, dass die Richtigkeit des Upgrades Vorrang vor dem Einhalten eines bestimmten Datums hat, sodass wir möglicherweise erst im vierten Quartal oder sogar Ende des Jahres dieses Upgrade sehen werden.

Dieser Inhalt wird nur zu allgemeinen Informationszwecken bereitgestellt und stellt keine finanzielle, Anlage-, Rechts- oder Steuerberatung dar. Alle erwähnten Ereignisse, Prämien, Online-Aktionen oder zugehörige Informationen sollten nicht als Empfehlung, Aufforderung oder Einladung zum Kauf, Verkauf, Handel oder anderweitigem Umgang mit Krypto-Assets betrachtet werden. Krypto-Assets sind sehr volatil und können zu Verlusten führen. Die Verfügbarkeit von WEEX Services, Produkten und zugehörigen Aktionen kann je nach Region unterschiedlich sein. Sie sind dafür verantwortlich sicherzustellen, dass Ihre Teilnahme mit geltenden lokalen Gesetzen und Vorschriften übereinstimmt.