Glamsterdam-Upgrade verschoben: Ethereum prüft Vertragsrisiken im Hoodi-Testnetz

Der für den 26. Oktober geplante Hoodi-Test wurde abgesagt, einschließlich des geplanten Gaslimits von 200 Millionen. Die Entwickler prüfen einen Vorschlag zur Neubepreisung im Hinblick auf bereits auf dem Mainnet befindliche Verträge.

Ethereum hat einen Test abgesagt, der am kommenden Montag hätte laufen sollen. Die Mitteilung der Ethereum Foundation vom 22. Oktober besagt, dass Glamsterdam am 26. Oktober um 17:42:48 UTC nicht auf Hoodi aktiviert wird und keine neue Epoche festgelegt wurde. Die damit einhergehende Erhöhung des Gaslimits auf 200 Millionen wurde ebenfalls aus dem Zeitplan des Testnets gestrichen. Dies ist ein Aufschub einer zukünftigen Konfiguration, keine Rücknahme bereits von Hoodi aufgezeichneter Blöcke.

Die Entwickler trafen die Entscheidung, zu untersuchen, wie EIP-8037, eine Änderung des Preises für die Erstellung neuen Ethereum-States, mit Verträgen auf dem Mainnet interagiert. Die Foundation hat nicht gesagt, dass das Upgrade das Mainnet beschädigt hat. Sie hat auch kein Datum für einen Produktions-Fork genannt. Das unmittelbare operationelle Risiko liegt bei Hoodi: Clients oder benutzerdefinierte Konfigurationen, die noch die alte Aktivierungszeit tragen, könnten mit dem überarbeiteten Zeitplan nicht übereinstimmen. Die tiefergehende Frage ist, wie die Kosten für Arbeit innerhalb einer Transaktion geändert werden können, ohne Anwendungen zu stören, die die alten Zahlen in den Code eingebettet haben.

Hoodis Fork vom 26. Oktober ist vom Kalender gestrichen

Die Hoodi-Ankündigung vom 16. Oktober legte Epoche 132.352 und Slot 4.235.264 fest. Sie verband die Amsterdam-Änderungen der Ausführungsschicht mit den Gloas-Änderungen der Konsensschicht und einem Gaslimit von 200 Millionen. Die neue Mitteilung ersetzt diese Anweisungen vollständig. Betreiber sollten die neuesten Versionshinweise für beide Client-Typen lesen; eine frühere Version, die als Glamsterdam-kompatibel beschrieben wurde, kann noch die nun abgesagte Hoodi-Aktivierung enthalten.

Das ist mehr als eine terminliche Fußnote. Ein Validator muss denselben Netzwerkregeln folgen wie seine Peers. Wenn ein Teil seiner Software neue Ausführungsregeln oder Konsenspflichten zur alten Epoche erwartet, während das Netzwerk dies nicht tut, kann er die Fähigkeit verlieren, der kanonischen Chain zu folgen. Builder- und Validator-Infrastruktur kann eigene Konfigurationen haben. Die Foundation weist Betreiber daher an, überarbeitete Client-Versionen zu überprüfen und veraltete benutzerdefinierte Einstellungen vor dem 26. Oktober zu entfernen, statt anzunehmen, dass Nichtstun sicher sei, weil ein Fork verschoben wurde.

Sepolia aktivierte Glamsterdam am 6. Oktober und testete ein Gaslimit von 200 Millionen, wie die Berichterstattung über diese Aktivierung festhielt. Die erfolgreiche Aktivierung eines Testnets ist nützlich, aber nicht ausschlaggebend für ein anderes. Hoodis verbleibende Generalprobe wurde gerade deshalb verschoben, weil die Vertragsuntersuchung Zeit braucht. Es gibt keinen veröffentlichten Ersatz-Zeitstempel, aus dem sich ein Mainnet-Datum ableiten ließe.

Glamsterdam wurde am 6. Oktober auf Sepolia aktiviert, wo Entwickler ein Gaslimit von 200 Millionen testeten. Der erfolgreiche Test klärt nicht, wie sich EIP-8037 auf bereits auf dem Mainnet laufende Verträge auswirken wird. Hoodis Generalprobe ist verschoben, während Entwickler diese Interaktionen untersuchen, und es wurde kein Ersatztermin angekündigt.

Die Sequenz hat sich in diesem Jahr mehr als einmal geändert. Der September-Bericht über den Sepolia-Plan beschrieb Devnet-Probleme und ein Implementierungsproblem mit EIP-8037, bevor der öffentliche Test fortgesetzt wurde. Diese früheren Probleme sind kein Beweis für dieselbe Ursache wie die Vertragsanfrage vom 22. Oktober. Sie zeigen, warum die Termine bedingt waren, während die Client-Teams von privaten Tests zu öffentlichen Netzwerken übergehen. Separate Bedenken hinsichtlich des Verhaltens von Buildern in Testnets betreffen einen anderen Teil von Glamsterdam und sollten nicht mit der Neubepreisung vermischt werden. Die neueste Mitteilung nennt einen konkreten Grund für die Hoodi-Pause: die weitere Untersuchung der Interaktion von EIP-8037 mit Mainnet-Verträgen.

Warum die Erstellung von State im Vorschlag mehr kostet

Eine Transaktion kann Berechnungen ausführen und Daten hinterlassen, die das Netzwerk aufbewahren und später abrufen muss. Das Erstellen eines neuen Kontos, das Öffnen eines neuen Speicher-Slots oder das Bereitstellen von Vertrags-Bytecode vergrößert diesen persistenten State. EIP-8037 schlägt vor, diese Operationen teurer zu machen und den Teil der State-Erstellung separat zu messen. Ziel ist es, den Preis näher an die längerfristige Belastung der Nodes zu bringen, insbesondere wenn Blöcke mehr Arbeit tragen dürfen.

Die illustrative Tabelle des Vorschlags setzt die State-Erstellungskomponente eines neuen Kontos auf 183.600 Gas, verglichen mit derzeit 25.000; einen neuen Speicher-Slot auf 97.920, verglichen mit 20.000; und eine Bereitstellung von 24 Kilobyte auf 37.784.880, verglichen mit 4.947.200. Die Tabelle ist keine allgemeine Vorhersage der ETH-Gebühr, die ein Nutzer zahlen wird. Sie isoliert eine Komponente unter einer vorgeschlagenen Konstante, mit weiteren Ausführungsgebühren obendrauf, und die endgültigen Währungskosten hängen vom Gaspreis zum jeweiligen Zeitpunkt ab. Die Größe der Änderung erklärt, warum Verträge mit engen Limits einer genaueren Prüfung bedürfen.

Ein verwandter State-Access-Vorschlag, EIP-8038, bepreist einige Lese- und Schreibvorgänge neu. Der Leitfaden zu den Entwicklerauswirkungen der Foundation besagt, dass diese Gaskosten zuletzt im Berlin-Fork im Jahr 2021 wesentlich angepasst wurden, während der State gewachsen ist. Die geplante Neubepreisung wurde zusammen mit Arbeiten zur Erhöhung des Durchsatzes konzipiert; größere Blöcke ohne Berücksichtigung teurer State-Operationen könnten die Validierung für Node-Betreiber erschweren. Die Pause betrifft daher sowohl die Anwendungskompatibilität als auch den Skalierungsplan, obwohl ihr angekündigter Auslöser die Interaktion mit EIP-8037 ist.

Ein externer Aufruf zeigt, warum dies im Voraus schwer zu bemerken sein kann. Ein Aufrufer kann bewusst nur so viel Gas übergeben, dass ein Empfänger eine begrenzte Aktion ausführen kann, in der Annahme, dass jede weitere Arbeit sicher fehlschlägt. Wenn ein neu bepreistes Konto oder ein Speicherzugriff nun dieses Budget verbraucht, kann der Empfänger während einer routinemäßigen Zahlung fehlschlagen, obwohl der Nutzer der äußeren Transaktion reichlich Gas bereitgestellt hat. Die Änderung der Wallet-Schätzung schreibt das interne Budget nicht neu. Entwickler müssen den Codepfad und die Fehlerbehandlung darum herum prüfen, denn manche Anwendungen betrachten einen fehlgeschlagenen externen Aufruf als Grund zum Revert, während andere fortfahren und ein anderes Ergebnis aufzeichnen.

Die Solidity-Muster transfer und send überweisen historisch ein Stipendium von 2.300 Gas. Viele Teams haben sich bereits davon abgewandt, sich auf dieses Stipendium zu verlassen, aber bereitgestellte Verträge können jahrelang in Gebrauch bleiben. Die Foundation identifiziert feste Stipendien als eine Risikokategorie; sie sagt nicht, dass jeder Aufruf, der sie verwendet, fehlschlagen wird. Ein Empfänger, der wenig Arbeit verrichtet, kann innerhalb des Budgets bleiben, während ein Vertrag, der neu bepreisten State berührt, es überschreiten kann. Das Testen tatsächlicher Gegenparteien ist wichtiger, als das bloße Vorhandensein eines Funktionsnamens als Beweis für eine Störung zu behandeln.

Eine zweite Problemklasse liegt in der Automatisierung. Wallets, Relayer und Verwahrer können Standard-Gaslimits für regelmäßige Aufgaben speichern. Eine Operation, die jahrelang erfolgreich lief, könnte anfangen, kein Gas mehr zu haben, obwohl der Anwendungsvertrag selbst solide ist. Eine Erhöhung der Schätzung im Frontend kann diesen Weg beheben, aber ein geplanter Agent oder ein Kunde, der eine ältere Wallet verwendet, könnte weiterhin das vorherige Limit übermitteln. Entwickler müssen daher nicht nur den betroffenen Code identifizieren, sondern auch die Dienste, die Transaktionen dafür erstellen.

Welche Verträge können in Schwierigkeiten geraten?

Die Foundation hat historische Mainnet-Transaktionen unter dem vorgeschlagenen Zeitplan erneut abgespielt. Die meisten hatten kein nennenswertes Problem. Von den markierten Fällen wurden viele abgeschlossen, nachdem ihr Gaslimit erhöht wurde; eine kleinere Gruppe könnte selbst mit deutlich mehr Gas fehlschlagen. Ein festes Stipendium, ein fest codierter Gasbetrag, der an einen anderen Vertrag gesendet wird, oder eine Verzweigung basierend auf dem Ergebnis von gasleft() kann den Pfad ändern, den eine Transaktion nimmt. Die frühere Vertragswarnung beschrieb diese Kategorien, bevor Hoodi sein Oktober-Datum erhielt. Die aktuelle Verschiebung macht die unbeantworteten Fälle dringend, zeigt aber nicht, dass alle Ethereum-Verträge anfällig sind.

Betrachten Sie eine Anwendung, die Gelder an einen anderen Vertrag sendet und dabei ein festes Gasbudget bereitstellt. Der empfangende Vertrag könnte unter dem neuen Zeitplan mehr Gas benötigen, um auf den Speicher zuzugreifen. Wenn das Budget des Aufrufers im bereitgestellten Code eingebettet ist, reicht eine bloße Erhöhung des Transaktionslimits auf oberster Ebene möglicherweise nicht aus, um dem empfangenden Aufruf mehr Spielraum zu geben. Ein Fehlschlag könnte dann eine Korrektur auf Vertragsebene oder einen anderen Weg für Benutzer erfordern. Wenn das einzige Problem hingegen darin besteht, dass eine Wallet eine Transaktion mit alten Preisen geschätzt hat, können eine aktualisierte Schätzung und ein höher angesetztes Limit ausreichen. Die beiden Fälle sind operativ verschieden.

Ein besonders ungewöhnliches EIP-8037-Problem betrifft Code, der Arbeit durch Subtrahieren zweier Messwerte des verbleibenden Gases misst. Der Vorschlag erklärt, dass das State-Gas-Reservoir gasleft() unter bestimmten Umständen ansteigen lassen kann. Eine Berechnung, die eine nichtnegative Abnahme erwartet, könnte sich anders verhalten, und unveränderliche bereitgestellte Verträge können nicht an Ort und Stelle gepatcht werden. Die genaue Auswirkung hängt vom Code und dem Transaktionspfad ab, weshalb ein erneutes Abspielen tatsächlicher historischer Transaktionen wichtiger ist als eine allgemeine Warnung vor höheren Gebühren.

Das Suchwerkzeug der Foundation ermöglicht es Entwicklern, betroffene Vertragsadressen und den Grund für eine markierte Abweichung zu untersuchen. Es wird empfohlen, auf einem Devnet mit dem neuen Zeitplan zu testen und Code zu prüfen, der feste Limits annimmt, selbst wenn ein Vertrag nicht in der Liste erscheint. Ein historisches Replay ist ein Screening, keine vollständige Bestandsaufnahme des zukünftigen Verhaltens: Ein Pfad, den während der Stichprobe kein Benutzer aufgerufen hat, könnte dennoch eine anfällige Annahme enthalten. Teams benötigen eigene Tests für die Zweige, die sie betreiben.

Das Ergebnis eines Replays hängt auch von der Transaktionsstichprobe ab. Ein Vertrag kann ein festes Gasbudget in einer Funktion enthalten, die selten aufgerufen wurde; wenn dieser Pfad in der abgespielten Historie fehlt, kann das Werkzeug sein Versagen nicht nachweisen. Die Foundation rät Betreuern, den Code zu prüfen, selbst wenn seine Adresse nicht in der betroffenen Liste erscheint. Eine große Anwendung kann mehrere Verträge, aktualisierbare Frontends und automatisierte Agenten haben, die jeweils ein unterschiedliches Gaslimit bereitstellen. Das Team muss den Betrieb so testen, wie seine Benutzer ihn tatsächlich aufrufen, einschließlich einer Wallet oder eines Bots, der möglicherweise eine alte Schätzung im Cache hält.

Bei einem Vertrag, dessen Verhalten sich ändert, reicht es nicht immer aus, die Schnittstelle zu korrigieren, die Transaktionen übermittelt. Wenn das Gasbudget eines internen Aufrufs in unveränderlichen Code kompiliert wurde, benötigt sein Eigentümer möglicherweise eine Migration zu einem neuen Vertrag. Eine solche Migration kann das Verschieben von Guthaben, Genehmigungen oder Benutzerberechtigungen und die Kommunikation der neuen Adresse umfassen. Die Schwierigkeit hängt vom Design des Produkts ab; es gibt keine Hinweise darauf, dass jeder markierte Vertrag diese Arbeit erfordert. Genau deshalb ist die Unterscheidung zwischen einem durch Limit behebbaren Fehlschlag und einem potenziell defekten Vertrag sowohl für das Team als auch für seine Kunden wichtig.

Die Testanleitung ist besonders relevant für Anwendungen, die Account-Abstraktion oder mehrere Vertragsaufrufe verwenden, um eine Benutzeraktion abzuschließen. Ein Checkout kann ein Asset genehmigen, einen Swap weiterleiten und einen Händler in einer Sequenz abrechnen. Wenn ein interner Schritt ein fest codiertes Budget verwendet, kann der Kunde eine fehlgeschlagene Zahlung sehen, ohne zu wissen, welcher Vertrag das Limit erreicht hat. Das erneute Abspielen der gesamten Sequenz unter den vorgeschlagenen Regeln ist aussagekräftiger als die isolierte Prüfung der öffentlichen Methode jedes Vertrags. Betreuer sollten den ersten fehlschlagenden Schritt und ob ein größeres äußeres Gaslimit das Ergebnis tatsächlich ändert, aufzeichnen.

Verträge können sich nach einem fehlgeschlagenen Aufruf auch anders verhalten, anstatt einfach anzuhalten. Ein Fallback, der ein Ereignis protokolliert, ein internes Guthaben gutschreibt oder eine zweite Route versucht, kann unter Bedingungen weiterlaufen, die seine ursprünglichen Autoren nie erwartet haben. Diese Abweichung ist der Grund, warum ein Testergebnis, das nur als „Transaktion erfolgreich“ beschrieben wird, unzureichend sein kann. Der Ausgabezustand und die Ereignisse müssen mit der alten Ausführung verglichen werden. Die Kategorie der erfolgreichen Ausführung mit Änderungen der Foundation erfasst diese Möglichkeit, ohne sie automatisch als schädlich zu erklären.

Wallets, RPCs und Fabriken stehen vor unterschiedlichen Aufgaben

Wallets und Anbieter von Remote-Procedure-Calls schätzen das Gas, das eine Transaktion benötigt, bevor ein Benutzer signiert. EIP-8037 besagt, dass eth_estimateGas und die Node-Software sowohl das Ausführungsgas als auch die neue Zustandsgas-Dimension berücksichtigen müssen. Eine alte zwischengespeicherte Konstante kann eine zustandsintensive Transaktion unterschätzen. Benutzer sehen dann möglicherweise fehlgeschlagene Transaktionen, selbst wenn der Vertrag mit einem ordnungsgemäß geschätzten Limit funktionieren würde. Infrastruktur-Updates sind daher Teil der Kompatibilität und nicht lediglich eine Annehmlichkeit, die über das Protokoll gelegt wird.

Deterministische Deployment-Fabriken stellen einen weiteren engen Fall dar. EIP-8037 erörtert Fabriken, die ursprünglich an Standardadressen platziert wurden, unter Verwendung vorab signierter Transaktionen mit fest codierten Gaslimits. In einem frischen Netzwerk, das den neuen Zeitplan übernimmt, bevor die Fabrik existiert, könnte das alte vorab signierte Deployment kein Gas mehr haben. Der Vorschlag sagt ausdrücklich, dass bereits bereitgestellte Instanzen auf dem bestehenden Mainnet und den Layer-2-Netzwerken von diesem speziellen Genesis-Szenario nicht betroffen sind. Die Angabe des Vorbehalts ist wichtig: Es wäre irreführend, den Eindruck zu erwecken, dass jede bereits auf Ethereum verwendete Fabrik kurz vor dem Verschwinden steht.

Entwickler müssen auch einen unveränderten Vertrag von unveränderten Kosten unterscheiden. Eine Transaktion kann erfolgreich sein, aber eine andere Menge an Gas verbrauchen. Ein Unternehmen, das Deployments bündelt oder viele Speicherplätze erstellt, könnte selbst dann mit einer wesentlich anderen Kostenstruktur konfrontiert sein, wenn keine Funktion fehlschlägt. Sein Produkt benötigt möglicherweise andere Gebührenangebote, eine überarbeitete Subventionspolitik oder eine Änderung der Art und Weise, wie es Informationen speichert. Die Replay-Kategorien der Foundation trennen identische Ausführung, geänderte aber erfolgreiche Ausführung, durch Limit behebbare Fehler und potenziell defekte Verträge genau aus diesem Grund.

Die Zahlen in EIP-8037 verdienen eine weitere Einschränkung. Sein Beispiel rechnet vorgeschlagenes Gas unter Verwendung einer angenommenen Base Fee von 0,08 gwei in ETH um. Wenn sich die Base Fee ändert, ändert sich auch die für dasselbe Gas gezahlte ETH. Ein Entwickler, der die Tabelle mit einer bestehenden Rechnung vergleicht, muss Ausführungsgebühren und die tatsächlichen Transaktionsbedingungen hinzufügen, anstatt eine siebenfache Änderung der Zustandskosten als siebenfache Erhöhung der vollständigen Zahlung eines Benutzers darzustellen. Der Zweck des Vorschlags besteht darin, Ressourcen Kosten zuzuweisen; die endgültige Gebühr einer Person hängt von der Mischung dieser Ressourcen in der Transaktion ab.

Der Umfang der vorgeschlagenen Neupreisgestaltung sollte zusammen mit dem Kapazitätsziel gelesen werden. Mehr Platz für Transaktionen in einem Block kann das Netzwerk teuer zu validieren machen, wenn diese Transaktionen überproportional persistenten Zustand erzeugen. EIP-8037 weist diesem Wachstum einen separaten Zähler zu, damit die Kosten nicht innerhalb eines größeren nominalen Gaslimits verschwinden. EIP-8038 befasst sich mit Zugriffen auf bestehenden Zustand. Sie lösen unterschiedliche Teile der Ressourcenfrage, und ein funktionierender Block-Builder allein kann nicht feststellen, dass Anwendungen die Neupreisgestaltung korrekt handhaben.

Ethereums Block Access Lists haben eine separate Aufgabe. Sie teilen Clients mit, welche Konten und Speicherorte ein Block berührt, und helfen, einige Validierungsarbeiten parallel zu organisieren. Das kann unter günstigen Bedingungen einen höheren Durchsatz ermöglichen, aber es beseitigt nicht den persistenten Speicher, der durch neue Konten und Slots hinzugefügt wird. Ein Testnetz muss das kombinierte Upgrade unter realistischer Aktivität ausführen, weil eine Verbesserung in einer Dimension eine Einschränkung in einer anderen aufdecken kann. Die Verschiebung lässt diese kombinierte Hoodi-Übung vorerst unerledigt.

Viele Benutzer werden diese Änderungen zuerst indirekt erleben, über das von ihrer Wallet angegebene Gaslimit oder die Gebührenschätzung einer Anwendung. Eine Transaktion, die keinen neuen Zustand erzeugt, kann eine andere Wirkung zeigen als eine, die einen beträchtlichen Vertrag bereitstellt. Eine Handelschnittstelle, die feste Transaktionskosten verspricht, müsste prüfen, ob ihr Versprechen noch die von ihr ausgeführten Operationen abdeckt. Verallgemeinerungen, dass sich alle Ethereum-Gebühren in eine Richtung bewegen, wären ohne einen endgültigen Mainnet-Zeitplan, beobachtete Nachfrage und die endgültigen Parameter verfrüht.

Die Zahl von 200 Millionen war eine Testnet-Einstellung

Glamsterdam kombiniert mehr als nur die Neupreisgestaltung. Die verankerte Proposer-Builder-Trennung ändert die Übergabe einer Block-Payload, während Block-Level Access Lists Clients helfen, die Konten und den Speicher zu identifizieren, die ein Block berühren wird. Entwickler planten, diese Änderungen mit einem Hoodi-Gaslimit von 200 Millionen zu testen, passend zu Sepolia. Die Zahl war ein Testnet-Parameter. Sie war nie ein Versprechen, dass das Ethereum-Mainnet sofort dasselbe Limit übernehmen oder dass die Benutzergebühren um einen bestimmten Prozentsatz sinken würden.

Das Entfernen des Hoodi-Gaslimit-Zeitplans hält die Komponenten des verschobenen Forks zusammen. Betreiber werden die beabsichtigte höhere Kapazität unter Glamsterdam an diesem Montag nicht in diesem Netzwerk testen. Entwickler können weiterhin Sepolia und zweckgebundene Devnets nutzen, um die Auswirkungen der Neubepreisung zu untersuchen. Die fehlende Hoodi-Generalprobe beeinflusst die Reihenfolge, in der Client-Teams Vertrauen gewinnen können, bevor sie einen Mainnet-Zeitpunkt wählen, aber die Foundation hat keinen überarbeiteten Produktionszeitplan veröffentlicht.

Die Ökonomie ist weniger geradlinig als ein Slogan über günstigeres Gas. Höhere Gebühren für die Schaffung dauerhaften Zustands können eine bestimmte Transaktion bei gleichem Gaspreis teurer machen. Eine größere sichere Kapazität könnte, falls später übernommen und genutzt, die Überlastung unter anderen Bedingungen lindern. Die Nachfrage bestimmt, wie viel Blockspace Nutzer ersteigern, und die endgültigen Protokolleinstellungen bestimmen, welche Operationen teurer oder günstiger werden. Weder die Pause noch ein erfolgreicher Test würden diese Marktvariablen für sich genommen klären.

Öffentliche Koordination hat Kosten, aber mit einer bekannten Unsicherheit fortzufahren kann größere haben. Betreiber bereiteten Software für die alte Epoche vor und müssen nun diesen Zeitplan entfernen; Anwendungsentwickler müssen weiterhin gegen einen Vorschlag testen, dessen endgültige Form sich ändern kann. Die Kosten dieses Resets sind sichtbar. Eine Mainnet-Regel, die einen weit verbreiteten Vertrag zum Scheitern brächte, wäre schwerer rückgängig zu machen, und die Folgen könnten Gelder oder abhängige Anwendungen betreffen. Die Mitteilung vom 22. Oktober quantifiziert ein solches Risiko nicht, macht aber deutlich, dass Entwickler die Interaktion als wichtig genug erachteten, um die Hoodi-Generalprobe zu stoppen.

Ein überarbeiteter Vorschlag könnte das Ziel der Bepreisung von Zustand beibehalten, aber die Funktionsweise des Gasreservoirs oder die Übergangsregeln für bestehende Verträge ändern. Er könnte stattdessen die Spezifikation beibehalten und gezielte Anwendungskorrekturen verlangen. Keine öffentliche Entscheidung zwischen diesen Wegen erscheint in der Verschiebungsmitteilung. Leser sollten es vermeiden, eine Untersuchung als endgültige Designentscheidung zu behandeln. Die genauen Änderungen, falls es welche gibt, werden wichtiger sein als die Anzahl der Tage, die Hoodi wartet.

Warum Entwickler sich entschieden zu warten

Ethereums Prozess erlaubt es Client-Teams, einen Plan vor einer öffentlichen Testnet-Aktivierung anzupassen. Die Entscheidung vom 22. Oktober im All Core Devs Execution Call 248 folgt auf frühere Warnungen und Kontaktaufnahmen mit betroffenen Buildern. Die öffentliche Mitteilung benennt den untersuchten Bereich, veröffentlicht aber keine endgültige Zahl gefährdeter Verträge, keine neue Version von EIP-8037 und kein Datum, an dem die Untersuchung enden wird. Die Verzögerung als bestätigten Fehler in allen bereitgestellten Verträgen zu bezeichnen, würde über die Veröffentlichung hinausgehen; sie als routinemäßige Kalenderverschiebung zu bezeichnen, würde ihre angegebene Ursache verfehlen.

Die alte Konfiguration muss über beide Schichten hinweg zurückgezogen werden. Execution-Clients verarbeiten Transaktionen und Zustand, während Consensus-Clients Validatoren und den Fork-Zeitplan koordinieren. Ein Netzwerk kann das Upgrade nur testen, wenn diese Clients sich auf die Regeln und den Zeitpunkt einigen. Hoodi-Betreiber, die Releases speziell für den 26. Oktober installiert haben, müssen nach den überarbeiteten Versionshinweisen suchen. Die Foundation sagt, sie werde Links zu neuen Client-Versionen hinzufügen, sobald diese bestätigt sind, statt ihre ursprüngliche Kompatibilitätstabelle als aktuell zu behandeln.

Es gibt auch eine Lektion in der Reihenfolge der Beweise. Das Nachspielen der Historie offenbarte eine kleine betroffene Gruppe; öffentliche Testnets offenbaren Client- und Anwendungsverhalten in einer Live-Umgebung; Mainnet setzt die endgültigen Regeln wirtschaftlicher Nutzung im großen Maßstab aus. Jede Stufe beantwortet etwas, das die vorherige nicht kann. Eine kurze Verzögerung bei Hoodi kann Zeit für die Vertragsarbeit kaufen, beweist aber nicht selbst, dass die eventuellen Regeln sicher sind. Die Entscheidung fortzufahren sollte auf Testergebnissen und klaren Betreiberanweisungen folgen.

Der Umfang der Betreibermitteilung ist es wert, ausdrücklich genannt zu werden. Ein gewöhnlicher Mainnet-Halter muss keine Wallet ändern, weil Hoodis Zeitplan zurückgezogen wurde. Ein Hoodi-Node-Betreiber, der sich auf den Fork vorbereitet hat, muss die Versionshinweise erneut prüfen. Ein Protokollingenieur, der die EIP untersucht, muss feststellen, ob das in Wiederholungen gefundene Vertragsverhalten akzeptabel, durch Tooling behebbar oder ein Grund ist, den Vorschlag zu ändern. Ein Anwendungsteam muss seine eigenen Ausführungspfade testen. Das sind unterschiedliche Zielgruppen mit unterschiedlichen Fristen, und eine einzelne Warnung „Upgrade verzögert“ gibt jeder von ihnen nicht die richtige Anweisung.

Der nächste Foundation-Beitrag kann auch klären, wie Entwickler mit betroffenen Teams kommunizieren werden. Ihr August-Leitfaden sagte, direkte Kontaktaufnahme habe begonnen, aber eine Kontaktzahl allein würde nicht belegen, dass ein Vertrag repariert wurde. Der testbare Beweis ist ein aktualisierter Vertrag, eine überarbeitete Gas-Konfiguration oder ein dokumentierter Fallback für ein bestimmtes Produkt. Einige unveränderliche Verträge könnten eine Benutzermigration erfordern, was ein separates Kommunikations- und Sicherheitsproblem aufwirft: Kunden müssen wissen, wo eine legitime Ersatzversion liegt, und betrügerische Adressen vermeiden. Es wurde keine Massenmigration angekündigt, daher bleibt dies ein Eventualfall für Teams, deren Code nicht an Ort und Stelle geändert werden kann.

Was vor einem anderen Datum kommt

Ein überarbeiteter Zeitplan sollte angeben, welche EIP-8037-Regeln getestet werden, was sich geändert hat, falls der Vorschlag geändert wird, und welche Client-Versionen sich auf die neue Hoodi-Epoche einigen. Anwendungsbetreuer benötigen Zeit, um Suchen nach betroffenen Verträgen durchzuführen, Schätzer zu aktualisieren, Limits anzuheben, wo dies ausreicht, und fest codierte interne Aufrufberechtigungen zu prüfen, wo dies nicht der Fall ist. Wenn ein potenziell fehlerhafter bereitgestellter Vertrag keinen direkten Upgrade-Pfad hat, muss sein Team möglicherweise erklären, wie Benutzer vor einem Mainnet-Fork zu einem Ersatz gelangen können.

Öffentliche Nachweise würden die Replay-Methodik und aktualisierte Ergebnisse zu betroffenen Verträgen, Ergebnisse von Devnets mit dem endgültigen Gas-Zeitplan, eine Hoodi-Aktivierung mit übereinstimmenden verschiedenen Clients und eine separate Mainnet-Ankündigung umfassen. Selbst eine saubere Hoodi-Aktivierung wäre eine Generalprobe, keine Garantie für einen bestimmten ETH-Preis oder eine endgültige Transaktionsgebühr. Die praktische Geschichte für Benutzer ist, dass keine Mainnet-Aktion am 26. Oktober angekündigt wurde. Die unmittelbare Maßnahme liegt bei Hoodi-Betreibern und Teams, deren Anwendungen Annahmen über Gas treffen.

Worauf zu achten ist

• Client-Releases: Ausführungs- und Konsens-Updates, die die alte Hoodi-Aktivierung vom 26. Oktober ausdrücklich entfernen.
• EIP-8037-Erkenntnisse: Neue Replay-Ergebnisse, Änderungen an den vorgeschlagenen Gas-Regeln und der Umgang mit Verträgen mit fest codierten Limits oder gasleft()-Logik.
• Eine Ersatz-Epoche: Ein datierter Hoodi-Plan, der nach der Untersuchung eine testbare Konfiguration wiederherstellt.
• Anwendungs-Fixes: Berichte betroffener Builder, die erklären, ob höhere Limits ausreichen oder bereitgestellter Code einen anderen Weg benötigt.
• Mainnet-Hinweis: Ein gesonderter Produktionszeitplan der Foundation nach der Testnet-Sequenz und der Client-Koordination.

FAQ