Warum Ethereum-Transaktionen warten: Nonce-Reihenfolge, Ersetzen und Stornierungsversuche

Nach dem Signieren einer Ethereum-Transaktion kann die Wallet sie an einen Execution Client oder einen Transaktions-Relay-Dienst senden. Ein Node, der die Transaktion erhält, kann sie an andere Nodes weitergeben; ein Block-Proposer kann sie später in einen Block aufnehmen. Bis dahin verändert die Transaktion den Zustand der kanonischen Chain nicht. Wenn eine Wallet oder ein Block-Explorer „pending“ anzeigt, kennt der jeweilige Dienst die Transaktion in der Regel, hat sie aber noch nicht in einem Block bestätigt gesehen. Das bedeutet nicht, dass es eine einzige Warteschlange gibt, die das gesamte Netzwerk gemeinsam nutzt. Der Transaktionsleitfaden von Ethereum.org beschreibt den Ablauf vom Signieren und Weiterleiten bis zur Aufnahme in einen Block.

Eine Transaktion kann aus verschiedenen Gründen warten. Die Gebührenobergrenze passt möglicherweise nicht zu den Bedingungen eines Blocks, oder eine frühere Transaktion desselben Kontos ist noch nicht geklärt. Der Node, den Sie abfragen, hat die Transaktion womöglich nicht erhalten. Vielleicht ist auch die Wallet veraltet oder zeigt nur Daten eines bestimmten Anbieters. Je nach Ursache sind unterschiedliche Prüfungen nötig. Eine höhere Gebühr behebt nicht die Auswahl eines falschen Netzwerks. Wenn Sie dieselbe Zahlung erneut senden, ohne den Status der ersten Transaktion zu prüfen, kann sie doppelt ausgeführt werden.

„Ausstehend“, „bestätigt“, „finalisiert“ und „fehlgeschlagen“ bezeichnen nicht denselben Status. Ein Transaktions-Hash kann sichtbar sein, bevor eine Receipt verfügbar ist. Die Receipt lässt sich erst prüfen, nachdem die Transaktion in einen Block aufgenommen wurde. Anschließend durchlaufen Ethereum-Blöcke die Zustände des Konsensprozesses. Wallets und Explorer verwenden diese Begriffe möglicherweise unterschiedlich. Prüfen Sie deshalb den Transaktions-Hash, den Block, die Receipt und den aktuellen Chain-Zustand, statt sich auf eine kurze Statusmeldung zu verlassen.

Ein gewöhnliches Ethereum-Konto in externem Besitz (EOA) hat eine Nonce, die die Reihenfolge der Transaktionen festlegt. Die Nonce ist ein Zähler pro Konto und weder eine Gebühr noch ein Zeitstempel oder ein eindeutiger Transaktions-Hash. Die Chain akzeptiert eine Transaktion, deren Nonce mit der nächsten vom Kontostand erwarteten Nonce übereinstimmt. Dasselbe Konto kann in der kanonischen Chain nicht zwei Transaktionen mit derselben Nonce ausführen. Der Kontoleitfaden von Ethereum.org beschreibt die Nonce als Transaktionszähler eines Kontos und als Mittel gegen Replay-Angriffe.

Angenommen, die nächste verfügbare Nonce eines Kontos ist 41. Die nächste gültige Transaktion dieses Kontos verwendet Nonce 41. Nachdem sie aufgenommen und verarbeitet wurde, verwendet die darauf folgende Transaktion Nonce 42. Die Nonce gehört zum Absenderkonto, nicht zur Empfängeradresse. Jedes Konto hat seine eigene Reihenfolge. Daher können zwei verschiedene Konten gleichzeitig jeweils eine Transaktion mit Nonce 41 haben.

Sie können eine Transaktion mit einer höheren Nonce als der aktuellen On-Chain-Nonce signieren, aber bei der Ausführung lässt sich die Reihenfolge nicht überspringen. Die fehlende frühere Nonce muss zuerst verbraucht werden. Eine Transaktion, die eine bereits vom Konto verbrauchte Nonce erneut verwendet, ist veraltet und kann nicht als neue Transaktion ausgeführt werden. Diese Reihenfolgeregel sorgt dafür, dass die Transaktionen jedes Kontos nacheinander verarbeitet werden, auch wenn sie zu unterschiedlichen Zeiten über mehrere Nodes verbreitet werden.

Die Nonce-Regel gilt für gewöhnliche EOA-Transaktionen auf der Ethereum-Ausführungsschicht. Sie erklärt nicht pauschal das Verhalten jedes Account-Abstraction-Systems, Rollup-Sequencers oder anderer Chains. Smart-Account-Systeme können eigene Reihenfolgen für Vorgänge und zusätzliche Nonce-Regeln einführen; darauf gehen wir später ein.

Ethereum hat keinen einzelnen synchronisierten Warteraum, den jede Wallet, jeder Node, jeder Block-Explorer und jeder Block-Proposer auf dieselbe Weise sieht. Jeder Execution Client speichert lokal die Transaktionen, die er erhalten und nach seinen eigenen Grenzen und Richtlinien als gültig eingestuft hat. Ein Node kann eine Transaktion kennen, die einem anderen fehlt. Die Geth-Dokumentation zur txpool-RPC zeigt die lokalen Gruppen pending und queued dieses Clients und erklärt, dass es mehrere Kandidatentransaktionen desselben Absenders mit derselben Nonce geben kann.

Bei Geth bezeichnet pending üblicherweise Transaktionen, die sich anhand des aktuellen Kontostands in Nonce-Reihenfolge verarbeiten lassen. queued bezeichnet spätere Transaktionen, die darauf warten, dass eine Nonce-Lücke geschlossen wird. Das ist eine Unterscheidung in der Client-Schnittstelle und kein Konsensregelwerk, das allen Programmen dieselben Statusnamen vorschreibt. Manche Wallets bezeichnen die gesamte Liste unbestätigter Transaktionen als „pending“. Ein Explorer zeigt möglicherweise nur Transaktionen an, die sein eigener Datenanbieter beobachtet hat.

Kennt ein Node beispielsweise eine Transaktion mit Nonce 41 und eine mit Nonce 43, kann er 43 nicht vor 42 ausführen. Er kann 43 in die Warteschlange stellen, bis 42 eintrifft oder sich der Kontostand auf andere Weise ändert. Ein anderer Node, der 43 nicht erhalten hat, zeigt diese Transaktion gar nicht an. Wenn zwei Explorer eine Transaktion unterschiedlich als „pending“ oder „nicht gefunden“ anzeigen, beweist keiner der beiden Bildschirme allein, was alle Validatoren erhalten haben.

Manche Clients speichern mehrere unbestätigte Kandidaten für denselben Absender und dieselbe Nonce. Diese Kandidaten werden nicht alle nacheinander ausgeführt, sondern konkurrieren um dieselbe Sequenznummer. Pool-Kapazität, Aufbewahrungsdauer und Ersetzungsbedingungen sind Implementierungsrichtlinien und können sich mit der Softwareversion ändern. Beispielsweise enthalten die Einstellungen des Geth-Transaktionspools eine Preiserhöhungsschwelle, die dieser Client verwendet. Verwechseln Sie diesen Wert nicht mit einer Gebührenregel für jede Ethereum-Transaktion. Den Geltungsbereich der Einstellungen finden Sie in der Referenz zu den Geth-Befehlszeilenoptionen.

Angenommen, die nächste On-Chain-Nonce eines Kontos ist 41. Das Konto verbreitet Transaktion A mit Nonce 41 und sendet danach Transaktion B mit Nonce 42. Solange A ungeklärt ist, kann B nicht zuerst angewendet werden. B kann in einer lokalen Warteschlange bleiben, nur in der Wallet als ausstehend erscheinen oder in einem Explorer fehlen, der sie noch nicht erhalten hat. Entscheidend ist die Nonce-Reihenfolge, nicht die Reihenfolge, in der die Wallet die Transaktionen erstellt oder angezeigt hat.

Wird A später aufgenommen, steigt die Kontononce auf 42. B kann ausgeführt werden, sofern sie ihre eigenen Gültigkeits-, Gebühren- und Transaktionspoolbedingungen erfüllt. Wird A mit Nonce 41 durch eine andere gültige Transaktion ersetzt, belegt die Ersetzung diese Sequenz, falls sie aufgenommen wird. Hat eine andere Transaktion des Kontos Nonce 41 bereits verbraucht, sind frühere Kandidaten mit Nonce 41 veraltet und können später nicht mehr ausgeführt werden.

Eine neue Transaktion mit höherer Nonce löst eine feststeckende Transaktion daher normalerweise nicht. Sie fügt lediglich eine weitere Transaktion hinter der fehlenden Sequenz hinzu. Auch eine Stornierung von B, der späteren Transaktion, klärt A nicht. Suchen Sie zuerst die niedrigste ungeklärte Nonce des Kontos und prüfen Sie ihren Status, bevor Sie sie ersetzen.

Eine Nonce-Lücke kann nur kurz bestehen oder lange offenbleiben. Die frühere Transaktion wurde vielleicht nicht an den Node weitergeleitet, den Sie abfragen, ihre Gebühr ist unter den aktuellen Bedingungen möglicherweise nicht attraktiv oder sie wurde aus dem Pool eines bestimmten Nodes entfernt. Eine Wallet kann eine auf einem anderen Gerät erstellte Transaktion als vorgemerkt anzeigen. Der Bildschirm allein zeigt nicht, welcher Fall zutrifft. Vergleichen Sie die bestätigte Kontononce, den Transaktions-Hash und die Ergebnisse mehrerer vertrauenswürdiger Abfragen.

Nonce-Reihenfolge und Gebührenbedingungen sind getrennte Einschränkungen. Auch eine Transaktion mit der passenden nächsten Nonce kann warten, wenn sie die Bedingungen für die Aufnahme in einen Block nicht erfüllt. Umgekehrt kann eine Transaktion mit späterer Nonce nicht allein deshalb vorgezogen werden, weil sie ein höheres Trinkgeld bietet. Eine höhere Gebühr für Nonce 42 entfernt die Transaktion mit Nonce 41 nicht.

Bei einer gewöhnlichen EIP-1559-Transaktion muss die maximale Gebühr die Base Fee des Blocks abdecken, in den die Transaktion aufgenommen wird. Die Prioritätsgebühr kann die Auswahl durch den Block-Proposer beeinflussen. Während die Transaktion wartet, können sich Base Fee und verfügbarer Blockplatz ändern. Die maximale Gebühr ist eine Obergrenze; sie zu erhöhen garantiert keine Aufnahme zu einem bestimmten Zeitpunkt. Der Leitfaden zu Ethereum-Gasgebühren erklärt die einzelnen Bestandteile und die Berechnung der effektiven Gebühr.

Ein Node oder eine Wallet kann zusätzliche Schwellenwerte für Weiterleitung und Ersetzung anwenden. Diese Richtlinien bestimmen, welche Transaktionen ein bestimmter Dienst annimmt oder weiterleitet; sie sind keine Regeln, auf die sich alle einigen müssen. Geth kann beispielsweise die Preiserhöhungsschwelle festlegen, mit der eine ausstehende Transaktion im eigenen Pool ersetzt wird. Andere Clients, Anbieter, Wallets und Softwareversionen können sich anders verhalten. Betrachten Sie weder einen erinnerten Gebührenprozentsatz noch eine festgelegte Wartezeit als netzwerkweite Garantie.

Wenn eine Transaktion wegen einer ungeklärten niedrigeren Nonce wartet, suchen Sie zuerst die Transaktion, die diese Sequenz belegt. Wenn die aktuelle Base Fee der Grund zu sein scheint, verstehen Sie die Gebührenfelder der Transaktion, bevor Sie sie ändern. Für die Gebührenberechnung ist der verlinkte Gasgebühren-Leitfaden geeignet; dieser Artikel behandelt das davon getrennte Problem der Kontoreihenfolge.

Die Funktion „Beschleunigen“ einer Wallet erstellt üblicherweise eine neue Transaktion mit demselben Konto und derselben Nonce, aber angepassten Gebühreneinstellungen. Zwei Kandidaten mit derselben Nonce konkurrieren miteinander, denn das Konto kann in dieser Sequenz nur eine Transaktion ausführen. Wenn die betreffenden Transaktionspools die Ersetzung akzeptieren und die neue Transaktion in einen Block aufgenommen wird, kann sie diese Nonce belegen. Die ursprüngliche Transaktion kann dann nicht gemeinsam mit ihr in der kanonischen Chain ausgeführt werden. Die Hilfe von MetaMask zu ausstehenden Transaktionen erklärt, dass der Beschleunigungsablauf des Produkts die Transaktion mit derselben Nonce und einer höheren Gebühr erneut sendet.

Eine Ersatztransaktion kann Ziel und Aktion der ursprünglichen Transaktion beibehalten und nur die Gebührenfelder ändern. Gehen Sie davon jedoch nicht aus, ohne den Bildschirm zu prüfen. Wallet-Implementierungen unterscheiden sich, zeigen möglicherweise andere Eingaben an oder verwenden eine andere Funktionsbezeichnung. Prüfen Sie vor dem Signieren Absenderkonto, Nonce, Empfängeradresse, Betrag und Vertragsdaten. Ändert sich die Aktion der Transaktion, handelt es sich nicht bloß um eine Gebührenanpassung.

Es ist nicht garantiert, dass eine Ersatztransaktion überall angenommen oder schnell aufgenommen wird. Die ursprüngliche Transaktion kann bereits enthalten sein, oder ein Node lehnt die Ersetzung aufgrund seiner eigenen Richtlinien ab. Die Bedingungen der Ersatztransaktion sind für den Block-Proposer möglicherweise weiterhin nicht attraktiv, oder sie werden nicht an den Node weitergeleitet, den Sie beobachten. Wurde die ursprüngliche Transaktion bestätigt, lässt sie sich nicht durch eine neue Transaktion mit verbrauchter Nonce rückgängig machen. Die neue Transaktion wird normalerweise wegen der veralteten Nonce abgelehnt.

„Ersetzen“ meint hier eine konkurrierende Transaktion mit demselben Konto und derselben Nonce. Übertragen Sie Bitcoin-Verfahren wie RBF oder CPFP nicht auf Ethereum. Bitcoin hat eine andere Transaktionsstruktur, und seine Gebührenanpassungen beschreiben nicht die Verarbeitung von Ethereum-Kontotransaktionen.

Nachdem eine signierte Ethereum-Transaktion weitergeleitet wurde, gibt es keinen Protokollbefehl, der sie von allen Nodes zurückholen kann. Einige Wallets bieten eine Stornierungsfunktion für noch unbestätigte Transaktionen. Diese versucht üblicherweise, eine andere Transaktion desselben Kontos mit derselben Nonce weiterzuleiten. Eine gängige Wallet-Methode ist eine Transaktion mit dem Wert 0 an die eigene Adresse. Wird der Stornierungskandidat vor der ursprünglichen Transaktion angenommen und in einen Block aufgenommen, verbraucht er die Nonce. Der ursprüngliche Kandidat kann dann später nicht mehr ausgeführt werden. Die genaue Erstellung und Verfügbarkeit hängt von der Wallet ab.

Die ursprüngliche Transaktion und der Stornierungskandidat konkurrieren miteinander. Wird die ursprüngliche Transaktion zuerst aufgenommen, kann eine spätere Stornierung die bereits eingetretene Wirkung nicht rückgängig machen. Wird keiner der Kandidaten angenommen oder aufgenommen, kann die Nonce weiterhin ungeklärt sein. Weder ein Klick auf die Schaltfläche noch eine Erfolgsmeldung der Wallet beweist, dass der Stornierungskandidat gewonnen hat. Prüfen Sie den neuen Transaktions-Hash und den Zustand der kanonischen Chain. Auch die MetaMask-Anleitung beschränkt sich auf den Versuch, eine noch ausstehende Transaktion zu stornieren, und erklärt, dass eine bereits bestätigte Transaktion nicht storniert werden kann.

Prüfen Sie vor dem Signieren der Stornierung, ob sie dasselbe Konto und dieselbe Nonce wie die Zieltransaktion verwendet, und kontrollieren Sie alle angezeigten Felder. Bei Aufnahme kann eine neue Netzwerkgebühr anfallen. Je nach Transaktionspool-Richtlinie kann der Stornierungskandidat ebenfalls warten oder die ursprüngliche Transaktion nicht ersetzen. Auch wenn die Wallet „storniert“ anzeigt, bedeutet das nicht, dass das Protokoll eine bereits verarbeitete Transaktion rückgängig gemacht hat. Prüfen Sie, welche Transaktion die Nonce verbraucht hat, bevor Sie das Ergebnis beurteilen.

Wenn die Transaktion bereits ausgeführt wurde, etwa durch eine Token-Genehmigung, einen Vertragsaufruf oder eine Vermögensübertragung, macht die Stornierung einer späteren Transaktion diese Zustandsänderung nicht rückgängig. Manche Vertragsaktionen haben möglicherweise eine separate Folgefunktion; ob sie verfügbar ist und was sie bewirkt, hängt jedoch vom Vertrag ab. Signieren Sie keine unbekannte Transaktion, nur weil sie auf dem Bildschirm als „Stornierung“ bezeichnet wird.

Eine in einen Block aufgenommene Transaktion hat Blockinformationen und eine Receipt. Bei erfolgreicher Ausführung können die beabsichtigten Zustandsänderungen angewendet werden. Wird die EVM-Ausführung zurückgesetzt, werden die Zustandsänderungen dieser Ausführung zurückgerollt. Die Kontononce der Transaktion ist dennoch verbraucht, und es können Gasgebühren anfallen. Prüfen Sie die Receipt und den Ausführungsstatus, statt den Erfolg aus einer Wallet-Benachrichtigung abzuleiten. Der Transaktionsleitfaden von Ethereum.org und der Gasgebühren-Leitfaden erläutern den Unterschied zwischen Aufnahme und Ausführungsergebnis.

„Entfernt“ oder „nicht gefunden“ ist häufig ein Status, den eine bestimmte Wallet, ein Explorer, ein RPC-Anbieter oder lokaler Transaktionspool meldet. Diese Meldung allein beweist nicht, dass das Protokoll die Transaktion storniert hat oder die Nonce wieder frei ist. Ein anderer Node kann die Transaktion weiterhin haben, und die Wallet kann eine signierte Transaktion erneut weiterleiten. Umgekehrt kann die bestätigte Kontononce unverändert bleiben, auch wenn die Transaktion auf den von Ihnen geprüften Bildschirmen nicht sichtbar ist.

Wenn Sie den Transaktions-Hash nicht finden, prüfen Sie, ob Sie die richtige Chain und das Konto ausgewählt haben, von dem die Transaktion erstellt wurde. Vergleichen Sie die neueste On-Chain-Nonce des Kontos mit der Transaktionsnonce und prüfen Sie neuere Transaktionen des Absenderkontos. Eine Antwort nonce too low ist ein Hinweis darauf, dass die Nonce aus Sicht des abgefragten Endpunkts bereits verbraucht sein könnte; sie ist keine Aufforderung, dieselbe Anfrage immer wieder zu senden. Ermitteln Sie, welche Transaktion die Nonce verwendet hat, und prüfen Sie, ob ihr Block noch zur kanonischen Chain gehört.

Auch eine aufgenommene Transaktion kann vor der Stabilisierung der Chain von einer kurzen Reorganisation betroffen sein. Wallets und Explorer können ihre Anzeige korrigieren, wenn sich die beobachteten Daten ändern. Bei einer wichtigen Übertragung richten Sie sich nach der vom empfangenden Dienst verlangten Zahl an Bestätigungen und prüfen Sie bei Bedarf eine stärkere Konsensfinalität. „In einem Block sichtbar“ bedeutet nicht dasselbe wie „unter allen Umständen unumkehrbar“.

Prüfen Sie zuerst die richtige Chain, das Absenderkonto und den Transaktions-Hash. Suchen Sie den Hash in einem vertrauenswürdigen Explorer dieses Netzwerks und prüfen Sie, ob eine Receipt vorhanden ist, welche Nonce verwendet wurde, ob die Ausführung erfolgreich war und welche späteren Transaktionen das Absenderkonto gesendet hat. Zur Prüfung einer Transaktion müssen Sie Ihre Seed Phrase weder offenlegen noch eingeben. Eine öffentliche Adresse und ein Transaktions-Hash reichen aus, um öffentliche Chain-Daten nachzuschlagen.

Wenn der Hash nicht angezeigt wird, vergleichen Sie die jüngste bestätigte Kontononce mit der Nonce, die Ihre Wallet anzeigt. Entwickler und Node-Betreiber können eth_getTransactionCount mit den Block-Tags latest und pending abfragen. Laut Ethereum.org-Referenz zu JSON-RPC bezeichnet latest den Zustand des neuesten Blocks und pending den ausstehenden Zustand. Auch der pending-Wert ist die Beobachtung eines bestimmten RPC-Endpunkts. Zwei Anbieter können unterschiedliche Werte zurückgeben. Die meisten Nutzer erhalten dieselben ersten Hinweise über die Kontoaktivität ihrer Wallet und einen vertrauenswürdigen Explorer, ohne Befehle auszuführen.

Prüfen Sie die niedrigste Nonce, die noch nicht verbraucht ist. Wenn die ursprüngliche Transaktion weiterhin angezeigt wird und Ihre Wallet Ersetzungen unterstützt, prüfen Sie die Felder und Gebühreneinstellungen des Ersatzes, bevor Sie erneut signieren. Wenn die ursprüngliche Transaktion nicht angezeigt wird, nehmen Sie nicht an, sie sei aus dem Netzwerk verschwunden. Fragen Sie die Wallet oder den RPC-Anbieter, wie erneutes Senden und Ersetzen gehandhabt werden. Wurde die Nonce bereits verbraucht, ermitteln Sie vor dem nächsten Schritt die dafür verantwortliche Transaktion. Mehrere Transaktionen mit höheren Nonces können die Warteschlange verlängern, ohne die erste Lücke zu schließen.

Dieser Artikel behandelt gewöhnliche Ethereum-Transaktionen von extern verwalteten Konten. Account-Abstraction-Systeme können UserOperations über einen Bundler einreichen, und Smart Accounts können komplexere Nonce-Schlüssel und Sequenzen als einen einzigen einfachen Zähler verwenden. EIP-4337 definiert die für diese Vorgänge verwendete Nonce-Struktur. Daher kann sich eine Wallet mit Account Abstraction anders verhalten als das hier gezeigte EOA-Beispiel. Das Zielnetzwerk, die Adresse und der Übertragungsstatus werden in der Prüfliste für Krypto-Übertragungen behandelt.