Zum Inhalt springen
Financial Context Wiki

Ersetzung von Ethereum-Mempool-Transaktionen

Client-spezifischer Leitfaden zur Ersetzung von Ethereum-Transaktionen desselben Absenders und derselben Nonce, zur Erhöhung von Gebührenobergrenzen, zu Cancel-Rennen, Blob-Transaktionen, privaten Übermittlungswegen, Receipts und Finalität.

Aktualisiert

Nur zu Bildungszwecken; stellt keine Anlageberatung oder Anlageempfehlung dar. Anlagen können zu Verlusten führen.

Direkte Antwort

Die Ersetzung einer Ethereum-Transaktion ist eine lokale Richtlinie des Transaktionspools, nach der ein Node eine neu signierte Transaktion gegenüber einem anderen Kandidaten desselben Absenders mit derselben nonce bevorzugen kann. Sie ist kein globaler Replace-by-Fee-Schalter auf Konsensebene. Nimmt ein Node den neuen Hash an, löscht dies die ältere signierte Transaktion nicht bei anderen Nodes, privaten Relays oder Buildern. Nur die Aufnahme in die kanonische Chain entscheidet, welcher Kandidat die Account-Nonce verbraucht.

Die Wallet-Aktion Speed Up behält üblicherweise ursprüngliches Ziel, Wert und Calldata bei und erhöht die Gebührenfelder. Eine Cancel-Aktion im öffentlichen Pool erzeugt üblicherweise eine wertlose Übertragung an das eigene Konto mit demselben Absender und derselben Nonce. Das ist eine konkurrierende Transaktion und kein Rückgängigmachen: Wird das Original zuerst aufgenommen, werden seine Übertragung oder sein Contract Call nicht rückgängig gemacht. Produktspezifische private Übermittlungswege können andere Abbruch-APIs definieren. Flashbots Protect dokumentiert beispielsweise einen authentifizierten Abbruch, der nicht onchain veröffentlicht wird; dies darf nicht auf die öffentliche Ersetzung von Ethereum-Transaktionen verallgemeinert werden.

Funktionsweise

  1. Legen Sie die genaue Linie fest: Chain-ID, Client und Version, Head-Block und Base Fee, Übermittlungsweg, Absender, kanonische Account-Nonce, signierte Rohbytes, Hash und Typ der ursprünglichen Transaktion. Fragen Sie mehrere relevante öffentliche oder private Ansichten ab; ein Wallet-Label oder eine einzelne RPC-Antwort ist kein globaler Zustand.
  2. Ordnen Sie das Original korrekt als abgelehnt, lokal pending, hinter einer Nonce-Lücke queued, verworfen oder verdrängt, privat übermittelt, erfolgreich aufgenommen, mit status = 0 aufgenommen, durch eine Reorganisation entfernt oder finalisiert ein. Betrachten Sie eine Ersetzung nicht mehr als verfügbar, sobald die Nonce kanonisch verbraucht ist; eine Reorganisation kann das Rennen allerdings neu eröffnen.
  3. Definieren Sie die neue Absicht. Ein Speed-up muss jedes beabsichtigte semantische Feld reproduzieren; ein öffentlicher Abbruchversuch verwendet üblicherweise denselben Absender und dieselbe Nonce mit to = sender, value = 0 und leerem Calldata. Vergleichen Sie vor der Signatur Chain-ID, Typ, Ziel, Wert, Calldata, Access List, Gaslimit, Blob-Hashes und Autorisierung.
  4. Lesen Sie die tatsächliche Ersetzungsrichtlinie des Ziel-Nodes. Legacy- und Typ-1-Transaktionen verwenden gasPrice; Typ-2-Transaktionen stellen maxFeePerGas und maxPriorityFeePerGas bereit; Typ-3-Transaktionen enthalten zusätzlich maxFeePerBlobGas und benötigen das Sidecar. Die derzeitigen Geth-Standardwerte txpool.pricebump = 10 und blobpool.pricebump = 100 sind Konfigurationsbeispiele für Geth, keine Ethereum-weiten Konstanten.
  5. Berechnen Sie Zulässigkeit und Finanzierung der Erhöhung getrennt. Für Typ 2 lautet der effektive Preis min(maxFeePerGas, baseFeePerGas + maxPriorityFeePerGas). Der Kandidat benötigt außerdem eine gültige Codierung, ausreichend intrinsisches Gas und einen Saldo für Wert plus maximale Gebührenbelastung. Eine höhere Obergrenze repariert kein ungültiges Calldata und garantiert keine erfolgreiche EVM-Ausführung.
  6. Übermitteln Sie gezielt und bewahren Sie jede Antwort auf. Eine öffentliche Wiederverbreitung kann die Absicht offenlegen und MEV aussetzen; private Relays haben jeweils eigene Sichtbarkeit, Abbruchmechanismen, Builder-Abdeckung und Verfügbarkeit. Verfolgen Sie alten und neuen Hash auf jedem Weg, ohne anzunehmen, die lokale Annahme habe den Konkurrenten gelöscht, und ohne blind einen dritten wertübertragenden Kandidaten zu senden.
  7. Gleichen Sie den Gewinner auf der kanonischen Chain ab. Prüfen Sie Receipt-Block und -Hash, Transaktionsindex, status, Gasverbrauch, effektiven Gaspreis, Logs, Absender-Nonce, Salden und Contract-Zustand auf dem erforderlichen Finalitätsniveau. Erfassen Sie unterlegene Hashes evidenzbasiert als ersetzt, verworfen oder weiterhin beobachtet und beginnen Sie die Analyse nach einer Reorganisation neu.

Durchgerechnete Beispiele

  • Didaktische Erhöhung einer gewöhnlichen Typ-2-Transaktion. Ein alter Kandidat hat maxFeePerGas = 40 gwei und maxPriorityFeePerGas = 2 gwei. Unter einer didaktischen Geth-Konfiguration mit einer Erhöhung von 10% betragen die rechnerischen Schwellen 44 gwei und 2.2 gwei. Ein Kandidat mit 44/2.1 gwei verfehlt die Tip-Schwelle; 44/2.2 gwei erreicht beide didaktischen Schwellen. Bei einer Base Fee von 32 gwei und 21,000 verbrauchten Gaseinheiten beträgt der effektive Preis 34.2 gwei, die Gesamtgebühr 718,200 gwei = 0.0007182 ETH, der Base Burn 0.000672 ETH und der Tip 0.0000462 ETH. Die tatsächliche Annahme hängt von Implementierung, Version und Rundung auf ganze Wei ab.
  • Base-Fee-Sensitivität. Eine Ersatztransaktion hat Obergrenzen von 66/4.4 gwei. Bei einer Base Fee von 60 gwei beträgt der effektive Preis min(66, 60 + 4.4) = 64.4 gwei. Bei einer Base Fee von 65 gwei beträgt der effektive Preis 66 gwei und der effektive Tip nur 1 gwei. Bei einer Base Fee von 67 gwei gilt 66 < 67; der Kandidat ist damit unter dieser Obergrenze unzulässig, selbst wenn er einen lokalen Erhöhungstest erfüllt hat.
  • Cancel-Rennen. Die ursprüngliche Transaktion mit Nonce 20 sendet 5 ETH an einen Händler. Gewinnt sie bei 21,000 * 42 gwei = 0.000882 ETH, erhält der Händler 5 ETH und die Cancel-Transaktion hat danach eine zu niedrige Nonce. Gewinnt die wertlose Eigenübertragung bei 21,000 * 45 gwei = 0.000945 ETH, verbraucht sie Nonce 20 und verhindert, dass das Original später in dieselbe kanonische Historie gelangt. Aus dem Klick auf Cancel allein lässt sich keiner der Ausgänge ableiten.
  • Grenze des Blob Pools. Ein alter Typ-3-Kandidat hat eine Ausführungsgebührenobergrenze von 100 gwei, eine Tip-Obergrenze von 3 gwei und eine Blob-Fee-Obergrenze von 20 gwei. Unter einer didaktischen Geth-Blob-Pool-Konfiguration mit einer Erhöhung von 100% lauten die rechnerischen Schwellen 200/6/40 gwei. Ein Kandidat mit 200/6/39 gwei verfehlt die Blob-Obergrenze; 200/6/40 gwei erreicht alle drei didaktischen Schwellen, benötigt aber weiterhin gültiges Sidecar, Nonce, Guthaben und Pool-Zulassung. Diese Werte sind keine Regeln für gewöhnliche Transaktionen oder andere Clients.

Risiken

  • Auswahl der falschen Chain-ID oder des falschen Netzwerks.
  • Auswahl des falschen Absenders oder der falschen Account-Nonce.
  • Verwendung eines veralteten Heads, einer veralteten Base Fee oder kanonischen Nonce.
  • Ersetzungsversuch, nachdem das Original aufgenommen oder finalisiert wurde.
  • Anwendung gewöhnlicher Txpool-Regeln auf eine ERC-4337-UserOperation.
  • Annahme, ein anderer Client, Provider, eine andere Version oder Konfiguration nutze dieselbe Richtlinie.
  • Verfehlen einer Erhöhungsschwelle durch Rundung auf ganze Wei.
  • Erhöhung nur eines erforderlichen EIP-1559-Gebührenfelds.
  • Festlegung von maxFeePerGas unterhalb der Base Fee des Kandidatenblocks.
  • Missachtung einer Blob-Fee-Obergrenze, eines Sidecars oder einer besonderen Blob-Pool-Regel.
  • Unzureichendes Guthaben für Wert plus maximal autorisierte Gebühren.
  • Ungültige Signatur, ungültiger Typ, Codierung, intrinsisches Gas oder Chain-Domain.
  • Versehentliche Änderung von Ziel, Wert, Calldata, Access List oder Blob-Hashes.
  • Verlust des Inklusionsrennens durch eine öffentliche Cancel-Transaktion.
  • Fortbestehen der alten Transaktion bei anderen Nodes oder in Builder-Eingaben.
  • Offenlegung, Zensur, Verwerfen oder fehlgeschlagener Abbruch durch ein privates Relay.
  • Offenlegung der Absicht gegenüber Frontrunning, Sandwiching oder anderem MEV durch öffentliche Wiederverbreitung.
  • Blockieren späterer Transaktionen durch eine Nonce-Lücke oder Veranlassen einer doppelten Übertragung.
  • Aufnahme der Ersatztransaktion mit anschließendem Revert oder Out-of-Gas unter Verbrauch von Nonce und Gebühren.
  • Reaktivierung oder Fehlklassifizierung von Kandidaten durch Fehler bei Reorganisation, Finalität oder Receipt-Linie.

Häufige Missverständnisse

  • Ein Kandidat mit höherer Gebühr löscht die alte Transaktion global.
  • Zwei Transaktionen mit derselben numerischen Nonce ersetzen sich auch bei unterschiedlichen Absendern.
  • Die Cancel-Schaltfläche einer Wallet macht eine bereits aufgenommene Transaktion rückgängig.
  • Die Annahme der Ersatztransaktion durch einen Node beweist, dass Builder sie aufnehmen werden.
  • Eine universelle Erhöhungsregel von 10 % deckt alle Clients, Blob-Transaktionen, privaten Relays und UserOperation ab.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...