Zwei Ethereum-Entwickler, Leo Glisic und Giulio Rebuffo, haben am Sonntag konkurrierende Vorschläge eingereicht, die getrennte Strategien zum Schutz bereits im Netzwerk bereitgestellter Anwendungen skizzieren. Beide befassen sich mit den potenziellen Folgen der Ethereum Improvement Proposals EIP-8037 und EIP-8038, die den für bestimmte Smart-Contract-Operationen erforderlichen Gas erhöhen würden. Der Streit ist zu einer wichtigen Frage für Glamsterdam geworden, da die Entwickler prüfen, ob die vorgeschlagenen Preisänderungen eingeführt werden können, ohne Verträge zu beeinträchtigen, die auf Ethereums bestehendem Gas-Schema aufbauen.

Gas-Änderungen bei Glamsterdam rufen Kompatibilitätsbedenken hervor

Im Mittelpunkt der Kontroverse stehen EIP-8037 und EIP-8038, zwei Vorschläge im geplanten Glamsterdam-Upgrade, die die Kosten für die Vertragserstellung und den Zugriff auf gespeicherte Blockchain-Daten ändern würden. Gas ist die Einheit, mit der Ethereum die Rechenressourcen misst, die zur Ausführung von Transaktionen und Smart-Contract-Anweisungen erforderlich sind; Änderungen an der Gaspreisgestaltung können das Verhalten von Anwendungen verändern, insbesondere wenn Entwickler Verträge um spezifische Ausführungsgrenzen herum programmiert haben.

Ethereum-Upgrades wie Glamsterdam bündeln mehrere EIPs in einer einzigen koordinierten Änderung der Netzwerkregeln, und Vorschläge durchlaufen in der Regel eine Überprüfung durch Core-Entwickler, Client-Implementierungen und Testnet-Tests, bevor eine Aktivierungsentscheidung getroffen wird. Der aktuelle Streit spielt sich innerhalb dieses Prozesses ab: Die Einwände kommen auf, während Glamsterdam noch im Testnet evaluiert wird, bevor etwas die Main-Blockchain erreicht.

Unter EIP-8037 würde die Grundgasgebühr für die Erstellung eines Smart Contracts von 32.000 auf 183.600 Gas steigen, wobei zusätzliche Kosten für Codespeicherung und Ausführung separat anfallen würden. Die Erhöhung hat Bedenken ausgelöst, da einige bestehende Ethereum-Anwendungen unter der Erwartung entwickelt wurden, dass bestimmte Operationen weiterhin dieselbe Gasmenge verbrauchen würden.

Einige Verträge weisen bei der Interaktion mit anderen Anwendungen ein festes Gasbudget zu. Steigen die Kosten dieser Interaktionen über den zugewiesenen Betrag hinaus, könnten die Operationen fehlschlagen. Besonders hoch sind die Einsätze für Smart Contracts, die nach dem Deployment nicht mehr geändert werden können, da solche Anwendungen möglicherweise keinen unkomplizierten Mechanismus zur Anpassung an ein überarbeitetes Gas-Schema haben.

Sicherheitsforscher warnen vor weitreichenden Vertragsstörungen

Die Bedenken haben den Testzeitplan von Glamsterdam bereits beeinflusst. Obwohl das Upgrade in einem Ethereum-Testnetz bereitgestellt wurde, wurde ein zweiter, für den 26. Oktober angesetzter Testdurchlauf nach Warnungen von Sicherheitsforschern verschoben. Ethereum-Testnetze ermöglichen es Entwicklern, Protokolländerungen zu evaluieren, bevor sie die Main-Blockchain erreichen, wo Anwendungen und Transaktionen echte Vermögenswerte betreffen. Auch in früheren Ethereum-Upgrades wurden Gas-Schemata überarbeitet, weshalb Neupreisvorschläge regelmäßig gegen Verträge geprüft werden, die auf älteren Kostannahmen basieren.

Der Sicherheitsforscher pcaversaccio kritisierte die vorgeschlagenen Gasanpassungen öffentlich und argumentierte, dass Glamsterdam nicht in seiner bestehenden Form fortgeführt werden sollte.

"imho Glamsterdam should not be shipped in its current form, period", schrieb pcaversaccio auf X.

Der Forscher sagte, die Bedenken seien zwei Wochen zuvor bei den Ethereum-Core-Entwicklern vorgebracht worden.

Der pseudonyme Entwickler banteg stellte ebenfalls den Umfang der bestehenden Kompatibilitätsbewertungen in Frage und verwies auf eine Liste von rund 200.000 potenziell betroffenen Verträgen im Repository ethereum/repricing-impact. Nach Angaben von banteg könnten methodische Grenzen der Bewertung bedeuten, dass erheblich mehr Verträge betroffen sind, als die bestehende Liste angibt. Der Entwickler warnte außerdem, dass die vorgeschlagenen Änderungen das Deployment und den Betrieb mehrerer prominenter Ethereum-Protokolle beeinträchtigen könnten, statt nur weniger verbreitete Anwendungen zu betreffen.

Die Warnungen haben die Prüfung verschärft, wie die Ethereum-Entwickler die Gas-Neupreisgestaltung umsetzen wollen und dabei die Funktionalität der bereits im Netzwerk betriebenen Verträge bewahren wollen.

EIP-8488 schlägt separate Gasregeln für bestehende und neue Verträge vor

Glisics Vorschlag, bekannt als EIP-8488, führt einen Kompatibilitätsmechanismus ein, der zwischen Smart Contracts unterscheidet, die vor dem Upgrade bereitgestellt wurden, und jenen, die danach erstellt wurden. Bestehende Verträge würden weiterhin unter Ethereums aktuellen Gaspreisregeln betrieben, während neu bereitgestellte Verträge einen überarbeiteten Satz von Anweisungen verwenden würden, der die höheren Gaskosten aus EIP-8037 und EIP-8038 widerspiegelt.

Der Vorschlag würde Ethereums Befehlssatz faktisch in zwei Versionen aufteilen, sodass ältere Anwendungen ihre etablierten Ausführungskosten behalten können, während neue Anwendungen der aktualisierten Preisstruktur folgen müssen.

"Existing contracts keep the legacy schedule", heißt es im EIP-8488-Entwurf.

Neue Verträge müssten die V2-Opcodes verwenden, die dem überarbeiteten Gas-Schema zugeordnet sind. Der Ansatz soll die Kompatibilitätsrisiken für Anwendungen verringern, die nicht aktualisiert werden können, während Ethereum seine geplanten Änderungen der Gaspreisgestaltung für künftige Deployments einführen kann.

Alternativvorschlag führt doppelte Gas-Abrechnung ein

Rebuffo hat einen anderen Mechanismus vorgeschlagen, der das neue Gaspreisschema auf die Transaktionsabrechnung anwenden und zugleich das bestehende Ausführungsverhalten älterer Smart Contracts beibehalten würde. Statt separate Befehlssätze für alte und neue Anwendungen zu pflegen, würde der Entwurf zwei Gas-Abrechnungsmechanismen innerhalb jeder Transaktion einführen. Ein Zähler würde die Vertrag Ausführung nach den bestehenden Gasregeln verfolgen, während ein zweiter die Transaktionsgebühren nach dem aktualisierten Preisschema berechnen würde.

Nach dieser Struktur würde das neue Schema die Transaktionsgebühr bestimmen, aber ältere Anwendungen würden weiterhin unter den Annahmen der bisherigen Gasregeln ausgeführt. Der Vorschlag zielt darauf ab, die Berechnung der Transaktionskosten von den Ausführungsbedingungen zu trennen, von denen bestehende Smart Contracts abhängen.

Der Entwurf räumt jedoch ein, dass der Entwurf auf Implementierungsebene noch ungetestet ist.

"no execution-client implementation or consensus tests have been run for this design", heißt es in dem Vorschlag.

Entwickler stehen vor Entscheidungen zu den Gas-Änderungen bei Glamsterdam

Die konkurrierenden Vorschläge veranschaulichen unterschiedliche Ansätze zur Lösung desselben Kompatibilitätsproblems. Glisics EIP-8488 würde die bestehende Gaspreisgestaltung für zuvor bereitgestellte Verträge bewahren und das überarbeitete Schema über neue Anweisungen einführen. Rebuffos Alternative würde eine aktualisierte Transaktionsabrechnung anwenden und zugleich das Legacy-Ausführungsverhalten beibehalten. Beide Ansätze sollen verhindern, dass die geplante Gas-Neupreisgestaltung Anwendungen stört, die auf Ethereums bestehenden Ausführungskosten beruhen.

Das Thema hat Aufmerksamkeit erregt, weil die betroffenen Verträge etablierte Protokolle umfassen können, die ihren bereitgestellten Code nicht leicht ändern können. Nachdem die Tests aufgrund von Sicherheitswarnungen bereits verzögert wurden, stellen die Vorschläge potenzielle technische Lösungen für Entwickler dar, die die Kompatibilitätsrisiken von Glamsterdam bewerten.

Die Meilensteine, die die Debatte voranbringen würden, sind konkret: eine neu angesetzte Testnet-Runde mit einem implementierten Kompatibilitätsmechanismus und – falls einer der Entwürfe vorangehen soll – Implementierungen in Execution-Clients und Konsens-Testergebnisse zu dessen Bewertung. Bis diese Schritte erfolgen, bleibt die Kompatibilitätsfrage offen, während Glamsterdam seinen Entwicklungszyklus durchläuft.

Die verfügbaren Informationen ergeben nicht, ob einer der Vorschläge angenommen wird. Rebuffos Entwurf liegt zudem weiterhin ohne Implementierung in Execution-Clients oder Konsens-Testergebnisse vor, sodass seine technische Machbarkeit einer weiteren Bewertung unterliegt.

Quelle: CoinDesk

Erstveröffentlichung: Hokanews