Ethereum legt Glamsterdams Hoodi-Fork auf Eis – was haben die Prüfer gefunden?

Die Ethereum-Entwickler haben den Hoodi-Testnet-Fork von Glamsterdam auf Eis gelegt, während sie die Erkenntnisse darüber aufarbeiten, wie sich Anwendungen verhalten, wenn einer Transaktion das Gas ausgeht. Das Upgrade ändert die Art und Weise, wie das Netzwerk einige Operationen berechnet, die seinen Zustand berühren oder erweitern, und die Prüfer stellten fest, dass selbst Verträge, die vor dem Upgrade geschrieben wurden, unter den vorgeschlagenen Regeln ein anderes Verhalten zeigen können.

Die Ethereum-Entwickler sollten Hoodi am 26. Oktober forken. Sie verschoben diesen Test, und am 6. November sagte der Ethereum-Foundation-Entwickler Marius van der Wijden, dass er weiterhin auf Eis liegt, während die Entwickler die in der Gas-Überprüfung identifizierten Probleme aufarbeiteten.

Die Sorge dreht sich um ein Detail, auf das die meisten Menschen erst stoßen, wenn eine Transaktion fehlschlägt. Verträge können andere Verträge aufrufen und entscheiden, was zu tun ist, wenn diese Aufrufe erfolglos zurückkommen. Der Code, der diese Entscheidung trifft, kann nach einem Upgrade genau gleich aussehen und dennoch einen anderen Pfad nehmen, weil das Netzwerk nun für Teile der Operation anders berechnet.

Deshalb ist ein Upgrade, das auf die Art und Weise abzielt, wie Ethereum den Zustand abrechnet, zu einer Frage für Anwendungsentwickler ebenso wie für die Teams geworden, die Ethereums Clients schreiben. Beide müssen wissen, welche alten Annahmen die Änderung überstehen.

Was Glamsterdam am Gas ändert

EIP-8037 ändert, wie das Protokoll Operationen abrechnet, die Zustand erstellen. Ethereums Zustand umfasst Aufzeichnungen wie Vertragsspeicher. Eine Änderung kann über Transaktionen hinweg bestehen bleiben, daher hat ihre Kosten Auswirkungen auf die Knoten, die die Chain nach Abschluss der ursprünglichen Transaktion aufrechterhalten. Der Vorschlag trennt die Abrechnung für einige Zustandserstellungen vom gewöhnlichen Ausführungsgas, mit einem Reservoir, aus dem für berechtigte Operationen geschöpft werden kann.

EIP-8038 bepreist Operationen neu, die auf Zustand zugreifen. Die beiden Vorschläge betreffen verschiedene Teile eines Ausführungspfads. Ein Vertrag könnte einen Wert lesen, einen externen Aufruf tätigen und ein Ergebnis schreiben. Die alleinige Überprüfung des vorgeschlagenen Preises für das abschließende Schreiben verfehlt die Auswirkung der früheren Lesevorgänge und Aufrufe auf das Budget, das bei Erreichen der Ausführung verfügbar ist.

Eine vertraute Anwendung kann daher ein anderes Ergebnis liefern, selbst wenn ein Nutzer dieselben Transaktionseingaben bereitstellt. Die wichtige Frage ist, welche Unterschiede die beabsichtigte Neubepreisung widerspiegeln und welche eine Annahme offenlegen, auf die sich ein Client oder ein Vertrag verlässt.

Wie ein fehlgeschlagener Aufruf das Endergebnis verändern kann

Betrachten Sie einen Vertrag, der einen zweiten Vertrag aufruft, um einen Schritt in einer größeren Operation auszuführen. Wenn der zweite Vertrag fehlschlägt, kann der Aufrufer alles stoppen oder den Fehler behandeln und fortfahren. Ein Stapelverarbeiter könnte ein erfolgloses Element aufzeichnen und weitermachen. Eine andere Anwendung könnte erwarten, dass die gesamte Operation zurückgesetzt wird, wenn der fehlgeschlagene Aufruf genügend Gas verbraucht.

ChainSecuritys Analyse beschreibt, wie die neue Abrechnung diese Unterscheidung beeinflussen kann. Ethereum begrenzt bereits, wie viel Gas ein Aufrufer gemäß der EIP-150-Regel weitergeben kann. Im relevanten Fall können etwa ein Vierundsechzigstel beim Aufrufer verbleiben. Das Problem ist, wie viel der Aufrufer tatsächlich zur Verfügung hat, sobald die Ausführung zurückkehrt, und was es kostet, die Anweisungen auf diesem Pfad abzuschließen.

Angenommen, eine Anwendung behandelt einen Aufruffehler als gewöhnliches Geschäftsergebnis. Wenn sie genügend Gas hat, um den Fehlerhandler abzuschließen, könnte sie ein Ergebnis aufzeichnen oder den Rest der Transaktion fortsetzen. Wenn ihr dabei das Gas ausgeht, wird die äußere Transaktion zurückgesetzt. Diese Ergebnisse hinterlassen unterschiedliche Aufzeichnungen, obwohl der innere Aufruf in beiden Fällen fehlgeschlagen ist.

Der Auditor untersuchte auch Prüfungen basierend auf gasleft(). Ein Vertrag kann die Anweisung verwenden, um sein verbleibendes Ausführungsbudget mit einem fest codierten Minimum zu vergleichen. Ein Schwellenwert, der unter einem Zeitplan kalibriert wurde, kann unter einem anderen zu einem schlechten Prädiktor werden, insbesondere wenn der Vertrag auf Zustandsoperationen stößt oder Gas an eine andere Adresse weiterleitet. Der Vertrag hat keine automatische Möglichkeit, eine Zahl zu revidieren, die sein Entwickler bei der Bereitstellung eingebettet hat.

Was die Auditoren feststellen müssen

Das November-Update der Foundation beschreibt acht Annahmen, die überprüft werden. Es gibt mindestens zwei unterschiedliche Fragen, die getestet werden müssen. Clients, die die neuen Regeln implementieren, müssen für eine gegebene Transaktion zum selben Ergebnis gelangen. Anwendungsprüfer müssen auch Fälle identifizieren, in denen dieses gemeinsame Ergebnis von dem abweicht, was bestehende Verträge erwarten.

Ein Test für die erste Frage kann dieselbe Transaktion gegen mehrere Clients ausführen und Zustands- und Gasergebnisse vergleichen. Ein Test für die zweite muss der eigenen Logik der Anwendung folgen. Es ist wichtig, ob der Vertrag einen fehlgeschlagenen Callback als Signal zum Fortfahren behandelt, ob er eine Zustandsänderung vor dem Aufruf aufzeichnet und ob er eine geschäftliche Ablehnung von einem Aufruf unterscheiden kann, der nie genügend Gas hatte.

Diese Pfade können in einem konventionellen Bereitstellungstest leicht übersehen werden. Ein typisches Transaktionsbudget kann den Aufruf und seinen Handler durch beide Zeitpläne tragen. Ein bewusst knappes Budget kann den Unterschied aufdecken. Grenzwerttests müssen daher fehlgeschlagene Aufrufe und Fälle nahe der Gasmenge einschließen, die erforderlich ist, um den Fehlerhandler zu betreten oder abzuschließen.

Was Hoodi zeigen kann

Glamsterdam hatte bereits Ethereums Sepolia-Testnetz erreicht, wo Entwickler ein Gaslimit von 200 Millionen getestet haben. Hoodi würde Entwicklern eine weitere gemeinsame Bereitstellung geben, in der sie das überarbeitete Upgrade ausüben können.

Ein öffentlicher Testnetz-Fork gibt Client-Teams und Anwendungsbetreibern eine gemeinsame Umgebung, in der sie diese Prüfungen durchführen können. Betreiber können Clients nach einem gemeinsamen Zeitplan aktualisieren, ihre Ergebnisse vergleichen und Tools gegen die Fork-Regeln testen. Anwendungsteams können prüfen, ob Transaktionssimulation und Gasschätzung dieselben Änderungen berücksichtigen, die sie während der Ausführung sehen.

Ein erfolgreicher Hoodi-Fork würde Entwicklern Belege über die Versionen und Transaktionen liefern, die sie getestet haben. Die längerfristige Frage ist, was repräsentative Anwendungen an den Grenzen ihrer Gasbudgets tun. Ein neues Fork-Datum wird leichter zu bewerten sein, wenn zugleich ein Protokoll darüber vorliegt, welche Fälle reproduziert wurden, was sich als Reaktion geändert hat und wie die Teams es getestet haben.

Die Gas-Arbeit läuft neben anderen Korrekturen. Ethereum-Entwickler haben separat die Validator-Einzahlungsspezifikation überarbeitet, während die Hoodi-Gasüberprüfung lief. Diese Korrekturen benötigen eigene Tests, da sie einen anderen Teil des Forks betreffen.

Vorerst gibt das neueste Entwickler-Update zu den Gasrisiken einen Grund für die Verzögerung an und erklärt, dass die Arbeit an Hegota weitergeht. Es überlässt den Zeitpunkt des nächsten Glamsterdam-Tests einer späteren Entscheidung.

Wie Gaslimits und State-Kosten zusammenpassen

Ein höheres Block-Gaslimit gibt Ethereum mehr Raum für Arbeit unter seinem Abrechnungssystem. Der einer einzelnen Operation zugewiesene Preis bestimmt, wie viel von diesem Raum die Operation einnimmt. Eine Änderung des Limits und eine Änderung der Preise können daher unterschiedliche Teile derselben Transaktion betreffen.

Manche Arbeit endet, wenn die Transaktion endet. Das Erzeugen von State ist anders, weil die Daten bestehen bleiben können und Node-Betreibern etwas hinterlassen, das sie später speichern und verarbeiten müssen. Ein neuer Speicher-Slot, ein Konto oder ein Contract kann zu dieser Last beitragen, selbst wenn die Anwendung, die ihn erzeugt hat, danach nur wenig Traffic erhält.

EIP-8037 ändert, wie die Kosten bestimmter State-Erzeugung abgerechnet werden. EIP-8038 bepreist den Zugriff auf State neu, was Operationen mit bereits existierenden Datensätzen einschließen kann. Eine Transaktion, die einen Wert liest, einen anderen Contract aufruft und einen Speichereintrag erzeugt, kann während eines einzigen Laufs auf beide Änderungen treffen.

Ein höheres Blocklimit allein sagt nicht, ob diese Sequenz mehr oder weniger kosten wird. Es beschreibt den für den Block als Ganzes verfügbaren Raum. Der Pfad der Transaktion und der Preis jeder Operation bestimmen, ob sie in das vom Sender bereitgestellte Gas passt.

Diese Unterscheidung war bereits relevant, als Sepolia Glamsterdam mit einem Gaslimit von 200 Millionen testete. Der Test zeigte, was Entwickler auf diesem Netzwerk ausführten. Die Zurückhaltung bei Hoodi betrifft die Frage, ob die Regeln für das nächste Testnet bereit sind, einschließlich des Verhaltens von Anwendungen, die auf früheren Gasannahmen beruhen.

Die acht Annahmen unter Prüfung

Das Auditor-Repository der Ethereum Foundation gruppiert seine Beispiele nach Änderungen der Operationspreise und Änderungen der Art und Weise, wie Gas verfolgt wird. Die Zahlen im Repository stammen aus einer festgeschriebenen Version der vorgeschlagenen Spezifikation und können sich ändern, wenn die Vorschläge überarbeitet werden.

Die erste Gruppe von Bedenken betrifft feste Zuwendungen und die Kosten für die Fertigstellung von Arbeit nach einem Aufruf. Entwickler haben möglicherweise ein Gaslimit für eine Operation festgelegt, die nun mehr kostet. Eine Reserve, die für einen abschließenden Schreibvorgang vorgesehen war, reicht möglicherweise nicht mehr aus. In einem anderen Fall kann der kleine Bruchteil, der bei einem Aufrufer verbleibt, ausreichen, um einen Fehlerpfad abzuschließen, von dem die Anwendung zuvor erwartet hatte, dass er zurückgesetzt wird.

Die Abrechnungsänderungen bringen weitere Möglichkeiten mit sich. Wenn ein separates Reservoir noch berechtigte State-Erzeugung finanzieren kann, kann ein Aufrufer einen Datensatz nach einem fehlgeschlagenen Aufruf schreiben, selbst wenn sein gewöhnliches Ausführungsbudget knapp ist. Das endgültige Ergebnis des Aufrufers kann dann davon abhängen, welche Operationen dieses separate Budget nutzen.

Das Löschen eines zuvor in derselben Transaktion erzeugten Slots kann in der geprüften Spezifikation sofort etwas State-Gas zurückgeben. Ein zurücksetzender Aufruf kann ebenfalls State-Gas zurückgeben. Code, der unter der Annahme geschrieben wurde, dass alles vor einem Revert verbrauchte Gas verloren ist, kann daher falsch interpretieren, was geschehen ist.

Ein Paar von gasleft()-Messungen kann ebenfalls eine unvollständige Sicht auf die Kosten von Arbeit liefern. Ein Contract, der die Differenz verwendet, um jemandem etwas in Rechnung zu stellen oder eine Rückerstattung zu berechnen, verlässt sich auf Annahmen darüber, wie sich Gas zwischen den beiden Messungen ändert. Gebühren, die aus einem separaten Pool entnommen werden, und State-Gas, das während der Ausführung zurückgegeben wird, können die Beziehung verändern.

Der achte Fall betrifft EIP-7702, das es einem Konto erlaubt, eine Delegation an Contract-Code zu autorisieren. Eine Transaktion kann aufgenommen werden, selbst wenn eine darin enthaltene Autorisierung nicht wirksam wurde, weil ihr das Gas ausging. Eine Wallet oder ein Dienst, der allein aus der Aufnahme der Transaktion schließt, dass die Delegation funktioniert hat, könnte eine unvollständige Aktion als abgeschlossen behandeln.

Das Repository gibt an, dass viele der bei seinen Autoren eingegangenen Befunde feste Beträge oder Reserven betrafen. Es bittet Entwickler und Auditoren, ihre Anwendungen anhand der Beispiele zu testen und Probleme zu melden. Das Inventar identifiziert Muster, die einer Prüfung bedürfen. Es impliziert nicht, dass jede Anwendung, die eines dieser Muster verwendet, einen Verlust verursachen wird.

Wie ein fehlgeschlagener Aufruf dennoch eine erfolgreiche Transaktion hinterlassen kann

Eine Ethereum-Transaktion kann mehrere Aufrufe enthalten. Ein Vertrag kann einen anderen Vertrag auffordern, einen Schritt auszuführen, und dann entscheiden, wie auf das Ergebnis zu reagieren ist. Ein fehlgeschlagener innerer Aufruf und eine fehlgeschlagene Transaktion sind unterschiedliche Ergebnisse.

Ein Stapelverarbeiter liefert ein nützliches Beispiel. Wenn ein Element fehlschlägt, könnte der Verarbeiter diesen Fehler aufzeichnen und mit dem nächsten Element fortfahren. Wenn ihm vor dem Aufzeichnen des Ergebnisses das Gas ausgeht, kann die äußere Transaktion zurückgesetzt werden und frühere Änderungen rückgängig machen. Derselbe innere Fehler hinterlässt daher einen unterschiedlichen Endzustand, je nachdem, was der Aufrufer danach tun kann.

Eine andere Anwendung könnte einen fehlgeschlagenen Aufruf als Grund dafür behandeln, zu ändern, wer eine Anfrage einreichen kann oder ob es erlaubt ist, sie erneut zu versuchen. Wenn der Aufrufer einen Pfad abschließen kann, von dem die Anwendung erwartete, dass er zurückgesetzt wird, kann der resultierende Zustand bestehen bleiben. Die Sicherheitsfolge hängt davon ab, was der abgeschlossene Pfad tatsächlich aufzeichnet.

Ein Akteur kann möglicherweise wählen, wie viel Gas eine Transaktion bereitstellt. Wenn diese Person genug Gas übrig lassen kann, damit der äußere Vertrag einen Pfad betritt, aber zu wenig, damit der innere Aufruf abgeschlossen werden kann, kann der Fehler durch das Transaktionsbudget herbeigeführt werden. Ein Vertrag, der auf den Fehler reagiert, muss diesen Fall von einem Aufruf unterscheiden, der den Aufgerufenen erreicht hat und legitimerweise fehlgeschlagen ist.

Das Weiterleitungslimit von EIP-150 ist ein Teil davon. Ein Aufrufer, der so viel Gas weiterleitet, wie erlaubt ist, behält unter der relevanten Regel etwa ein Vierundsechzigstel. Der zurückbehaltene Betrag muss noch die nachfolgenden Anweisungen bezahlen. Ob diese Anweisungen abgeschlossen werden, hängt vom Zeitplan und der auf sie angewandten Abrechnung ab.

Ein Vertrag kann für einen engen Bereich von Budgets anfällig sein. Geben Sie dem inneren Aufruf genug Gas, und er funktioniert normal. Geben Sie der gesamten Transaktion zu wenig, und der äußere Pfad wird zurückgesetzt. Das problematische Intervall ist der Bereich, in dem der innere Aufruf fehlschlägt, während der Aufrufer noch genug hat, um eine Aktion auszuführen, die der Entwickler für diesen Fehler nicht beabsichtigt hatte.

Warum das Ändern einer festen Gaszahl das Problem möglicherweise nicht löst

Ein fest codierter Schwellenwert kann einem Vertrag eine einfache Möglichkeit geben zu prüfen, ob er vor einem Aufruf genug Gas hat. Der Entwickler hat den Schwellenwert möglicherweise mit gängigen Transaktionen getestet und einen Puffer für die nachfolgende Arbeit gelassen. Die Zahl wird zu einer Abhängigkeit vom Zeitplan, unter dem sie gewählt wurde.

Eine Operation kann auch unterschiedliche Beträge kosten, je nachdem, ob die Anwendung einen bestehenden Datensatz aktualisiert oder einen neuen erstellt. Eine Übertragung an jemanden, der bereits ein Guthaben hat, kann auf einen anderen Speicherpfad treffen als eine Übertragung, die ein erstes Guthaben erstellt. Ein Test, der nur wiederholte Empfänger abdeckt, kann den teureren Pfad verfehlen.

Der Punkt, an dem der Vertrag Gas misst, ist wichtig. Ein Messwert unmittelbar vor dem Aufruf unterscheidet sich von einem Messwert nach mehreren Zustandszugriffen und dem Aufruf selbst. Ein Vertrag, der den Grund für das Scheitern aus dem letzteren Messwert ableitet, geht davon aus, dass er versteht, was dazwischen hätte berechnet oder zurückgegeben werden können.

Das Ändern eines Stipendiums kann eigene Konsequenzen haben. Es kann einen zuvor fehlschlagenden Pfad abschließen lassen und dem Aufgerufenen auch genug Gas geben, um Arbeit auszuführen, die er unter der alten Zuweisung nicht ausführen konnte. Der Entwickler muss wissen, was die Zuweisung verhindern sollte, bevor er sie anpasst.

Einige Verträge können durch einen Governance- oder Verwaltungsprozess geändert werden. Andere sind unveränderlich oder hängen von Komponenten ab, die nicht an Ort und Stelle geändert werden können. Selbst wenn ein Vertrag überarbeitet werden kann, müssen Dienste, die seine Transaktionen schätzen, sponsern oder weiterleiten, möglicherweise auch ihre eigenen Annahmen aktualisieren.

Was eine überzeugende Reproduktion zeigen muss

Ein Test kann mit derselben Transaktion, demselben Zustand und demselben Gaslimit unter den alten und den vorgeschlagenen Regeln beginnen. Ein Vergleich sollte identifizieren, welcher Aufruf einen Fehler zurückgibt, was der Aufrufer als Nächstes tut und ob die Transaktion Änderungen aufzeichnet, die zuvor nicht bestanden haben.

Das Testen von Budgets knapp über und unter dem Schwellenwert hilft zu zeigen, ob der Effekt einen engen Bereich einnimmt. Es kann auch identifizieren, wo die Ausführung divergiert. Eine frühe Guthabenprüfung, der an den Aufgerufenen weitergeleitete Betrag und ein Schreibvorgang im Fehlerbehandler sind unterschiedliche Punkte, an denen eine Änderung sichtbar werden kann.

Der Prüfer muss dann fragen, wer diesen Pfad erreichen kann. Eine in einem Testvertrag reproduzierte Änderung belegt einen Unterschied in der Ausführung. Eine reale Anwendung kann eine Autorisierung erfordern, eine separate Bedingung prüfen oder die betroffene Operation wiederholbar machen. Diese Details bestimmen, ob jemand ein unerwünschtes Ergebnis erzwingen kann.

Es gibt auch einen separaten Test für Client-Teams. Alle Ausführungsclients sollten bei einer Transaktion unter derselben Fork-Konfiguration zum selben Ergebnis gelangen. Eine Uneinigkeit zwischen Clients ist ein anderes Problem als wenn alle Clients konsistent ein Ergebnis produzieren, das eine Anwendung nicht vorhergesehen hat.

Eine Testsuite braucht sowohl erfolgreiche Pfade als auch Fehlschläge. Jeden fehlgeschlagenen Aufruf zum Revert zu zwingen, könnte eine unerwünschte Zustandsänderung verhindern, aber auch eine legitime Fähigkeit entfernen, den Rest eines Batches abzuschließen. Das beabsichtigte Anwendungsverhalten bestimmt, was eine Korrektur bewahren muss.

Eine gute Reproduktion sollte den Endzustand leicht überprüfbar machen. Wenn ein Fehlerdatensatz nach einem Lauf bestehen bleibt und nach einem anderen verschwindet, kann der Test den genauen Unterschied zeigen, anstatt sich auf einen allgemeinen Bericht über den Gasverbrauch zu verlassen. Das erleichtert die Bewertung sowohl des Risikos als auch einer vorgeschlagenen Änderung.

Was öffentliche Testnets nach einer lokalen Reproduktion hinzufügen

Ein Entwickler kann einen Edge Case auf einem lokalen Fork oder in einer kontrollierten Client-Umgebung testen. Ein öffentliches Testnet ermöglicht es dann mehreren Betreibern, dasselbe Upgrade auszuführen und sein Verhalten unter gemeinsamen Bedingungen zu vergleichen. Es gibt außerdem Wallet- und Infrastruktur-Teams einen Ort, um ihre eigene Software gegen die aktiven Regeln zu testen.

Sepolia und Hoodi dienen unterschiedlichen Schritten in diesem Prozess. Die Sepolia-Aktivierung zeigte, dass Entwickler den geplanten Code auf diesem Netzwerk ausführen und seinen Betrieb unter dem konfigurierten Gaslimit untersuchen konnten. Hoodi gibt ihnen eine weitere Bereitstellung, nachdem Erkenntnisse berücksichtigt wurden, die während der Überprüfung wichtig wurden.

Die Anwendungen, der Verkehr und der historische Zustand auf einem Testnet unterscheiden sich vom Mainnet. Ein reibungsloser Fork kann Belege über Client-Übereinstimmung und Routine-Transaktionen liefern, ohne jedes Vertragsmuster auszuführen, auf das Nutzer angewiesen sind. Eine gezielte Reproduktion liefert Belege über einen Edge Case, der im gewöhnlichen Testnet-Verkehr fehlen kann.

Die Upgrade-Anweisungen sind ein weiterer Teil des Tests. Ein Betreiber benötigt eine Version, die die beabsichtigte Konfiguration implementiert, und einen präzisen Aktivierungspunkt. Eine Anwendung muss wissen, wann ihre Simulationen beginnen sollten, die überarbeiteten Regeln zu verwenden. Ein neues Datum ist neben diesen Details nützlich.

Die Verschiebung im Oktober und der Statusbericht im November beschreiben denselben Aufschub zu unterschiedlichen Zeitpunkten. Der erste entfernte das geplante Hoodi-Datum. Der zweite erklärte, dass die Probleme noch gelöst werden mussten. Die nächste Bereitstellungsmitteilung kann zeigen, welche Änderungen für Betreiber zum Testen bereit sind.

Wie Wallets Erfolg melden können, während eine Aktion fehlschlägt

Wallets schätzen üblicherweise das Gas, bevor sie einen Nutzer zum Signieren auffordern. Die Schätzung hängt vom Zustand und den Regeln ab, die der Node in seiner Simulation anwendet. Ein Dienst, der eine ältere Fork-Konfiguration verwendet, kann eine Schätzung liefern, die für eine Transaktion, die die aktuelle Chain ausführt, nicht mehr geeignet ist.

Eine Transaktion, die revertet, kann den Sender dennoch Gas kosten. Eine äußere Transaktion, die nach dem Abfangen eines inneren Fehlers abgeschlossen wird, kann schwieriger zu interpretieren sein. Die Chain kann die Gesamttransaktion als erfolgreich aufzeichnen, während eine Aktion darin nicht stattgefunden hat. Das Wallet benötigt möglicherweise die Events oder den Zustand der Anwendung, um dem Nutzer den Unterschied zu erklären.

Relayer und Transaktionssponsoren stehen vor einem verwandten Problem. Sie können das Budget wählen oder die Kosten für eine Transaktion tragen, die jemand anderes anfordert. Wenn das Budget den beabsichtigten Pfad nicht mehr abdeckt, kann der Sponsor für eine Ausführung zahlen, die die angeforderte Aktion nicht liefert.

Indexer können die Auswirkung nach der Ausführung sehen. Ein Fehlerpfad, der nun abgeschlossen wird, kann Logs oder Zustandsänderungen erzeugen, die das nachgelagerte System zuvor nicht gesehen hat. Der Indexer folgt weiterhin dem tatsächlichen Zustand der Chain. Eine Anwendung, die auf den Indexer angewiesen ist, muss möglicherweise ändern, wie sie den resultierenden Datensatz interpretiert.

Ein End-to-End-Test kann die Schätzung eines Wallets, das übermittelte Budget eines Relayers, das Ausführungsergebnis des Clients und die Erklärung der Schnittstelle vergleichen. Jeder Schritt kann für sich erfolgreich sein, während der Nutzer dennoch eine irreführende Darstellung darüber erhält, welche Aktionen wirksam wurden. Die Unterscheidung ist am wichtigsten, wo die Anwendung ein Ergebnis als endgültig behandelt.

Was den Hoodi-Aufschub auflösen würde

Die Foundation bittet Anwendungsteams, die Annahmen zu identifizieren, die sie verwenden, und Fälle bereitzustellen, die Entwickler reproduzieren können. Einige Probleme können durch Änderungen an den vorgeschlagenen Gasregeln behoben werden. Andere können erfordern, dass eine Anwendung oder ein Infrastrukturanbieter überarbeitet, wie sie das neue Verhalten handhabt.

Wenn sich die Spezifikationen ändern, ist der relevante Test, ob ein Fall, der zuvor abwich, nun das beabsichtigte Ergebnis erreicht. Wenn Entwickler eine Verhaltensänderung beibehalten, benötigen Anwendungsteams genügend Details, um festzustellen, ob ihre Software auf dem vorherigen Ergebnis beruht. Beide Ergebnisse hängen davon ab, den betroffenen Aufruf und das, was danach bestehen bleibt, zu beschreiben.

Eine überarbeitete Spezifikation muss auch die Client-Builds erreichen, die Betreiber ausführen. Ein Build, der eine frühere Glamsterdam-Konfiguration unterstützte, enthält möglicherweise nicht die nachfolgenden Änderungen. Die Versionsnummern in einer neuen Hoodi-Mitteilung würden angeben, welche Versionen zusammen getestet werden können.

Das November-Update der Foundation besagt, dass die Arbeit an Hegota parallel weiterläuft. Das bedeutet, dass der Aufschub des früheren Forks nicht jede Entwicklungsentscheidung zum nächsten abdeckt. Für Glamsterdam ist der nächste relevante Meilenstein ein überarbeiteter Hoodi-Zeitplan mit einer Konfiguration, die Entwickler bereit sind, öffentlich auszuführen.

Ein erfolgreicher Fork würde den Teams eine gemeinsame Aufzeichnung geben, die sie vor einer Mainnet-Entscheidung prüfen können. Die Fälle, die die Verzögerung ausgelöst haben, bleiben die klarsten Tests dafür, ob die überarbeiteten Regeln bereit sind. Diese Tests müssen zeigen, was passiert, wenn ein Aufruf nahe an seinem Gaslimit fehlschlägt und die äußere Transaktion noch Arbeit zu erledigen hat.

Was die vorgeschlagenen Gaszahlen über verschiedene Pfade zeigen

Das Repository der Foundation gibt ein konkretes Beispiel für den Unterschied zwischen dem Erstellen von Zustand und dem Aktualisieren desselben. Unter ihrer festgelegten Glamsterdam-Spezifikation wird ein Kalt-Schreibvorgang, der einen neuen Slot erstellt, zwischen Ausführungskosten und einer deutlich größeren Zustandsgebühr aufgeteilt. Ein Schreibvorgang in einen bestehenden Slot wird ebenfalls neu bepreist, folgt aber einer anderen Berechnung.

Der Unterschied kann zwei Nutzer betreffen, die scheinbar dieselbe Anwendungsanfrage stellen. Ein Nutzer hat den Dienst möglicherweise schon einmal genutzt, sodass der Vertrag einen bestehenden Eintrag aktualisiert. Ein anderer benötigt möglicherweise einen neuen Datensatz. Eine Gaszuteilung, die für den ersten Nutzer funktioniert, kann für den zweiten fehlschlagen.

Das Repository besagt außerdem, dass ein separates Reservoir nur oberhalb eines bestimmten Transaktionsgaslimits in der getesteten Konfiguration verfügbar ist. Bei kleineren Transaktionen stammen die Zustandskosten stattdessen aus dem gewöhnlichen Budget. Diese Schwelle macht es wichtig, mehrere Budgets zu testen, anstatt anzunehmen, dass sich das Reservoir bei jedem Aufruf gleich verhält.

Code, der das verbleibende Gas liest, kann daher in manchen Fällen nur einen Teil der Ressourcen der Transaktion beobachten. Die Daten, die er liest, sind für das Budget, das die Anweisung offenlegt, weiterhin aussagekräftig. Was sich ändert, ist die Schlussfolgerung, die die Anwendung über die insgesamt verbrauchten oder noch verfügbaren Ressourcen ziehen kann.

Die Gasbeispiele sind an die vorgeschlagene Konfiguration gebunden. Sie geben keinen einzelnen Multiplikator an, der auf die bestehenden Schätzungen einer Wallet angewendet werden kann. Ein erstmaliger Speicherschreibvorgang, ein Aufruf mit einem festen Stipendium und eine fehlgeschlagene Delegation erfordern jeweils eine separate Prüfung, da sie auf unterschiedliche Teile der Regeln treffen.

Das ist auch der Grund, warum ein überarbeitetes Hoodi-Datum zusammen mit der Spezifikationsrevision und der Liste der von der Veröffentlichung abgedeckten Fälle nützlicher wäre. Diese Details würden es Teams ermöglichen, Tests erneut auszuführen, die zu ihren Anwendungen passen, bevor sie Schlussfolgerungen aus der allgemeinen Stabilität des Testnets ziehen.

Worauf zu achten ist

• Hoodi-Zeitplan: Ein überarbeitetes Fork-Datum sollte die Client-Versionen und die Fork-Konfiguration benennen, von denen erwartet wird, dass Betreiber sie ausführen.
• Client-Übereinstimmung: Client-übergreifende Tests können zeigen, ob Ausführungsclients rund um die neuen Grenzen denselben Zustand und dieselben Gas-Ergebnisse erreichen.
• Vertragsverhalten: Reproduktionen sollten zeigen, wann ein fehlgeschlagener externer Aufruf dem Aufrufer genügend Gas lässt, um abzuschließen, und was die äußere Transaktion aufzeichnet.
• Vorschlagsüberarbeitungen: Änderungen an EIP-8037 oder EIP-8038 werden helfen zu zeigen, welche Prüfungsergebnisse eine Protokolländerung erforderten.
• Anwendungs-Tooling: Simulations- und Gas-Schätzergebnisse können zeigen, ob Wallets und Infrastrukturanbieter die Fork-Regeln korrekt widerspiegeln.

FAQs