Zum Inhalt springen
Financial Context Wiki

Mempools und Transaktionspools

Node-lokaler Leitfaden zu Ethereum-Transaktionsannahme, ausstehenden und zurückgestellten Nonces, Weitergabe, Gebühreneignung, Ersetzung, privatem Orderflow, Aufnahme, Entfernung und Reorganisation.

Aktualisiert

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

Direkte Antwort

Ein Mempool oder Transaktionspool ist die temporäre, im Arbeitsspeicher und gelegentlich persistent gehaltene Menge signierter Transaktionen, die eine Node nach ihren aktuellen Validierungs- und Richtlinienregeln angenommen hat, die aber nicht in ihrer kanonischen Chain enthalten sind. Er ist weder Konsensobjekt noch globale Warteschlange oder Aufnahmezusage. Zwei ehrliche Nodes können unterschiedliche Transaktionen halten, weil sie anderes Gossip empfangen, andere Clients oder Einstellungen verwenden, neu gestartet wurden, Einträge entfernt haben oder verschiedene öffentliche und private Übermittlungswege nutzen.

Bei einem Ethereum Execution Client wird eine ausführbare Transaktion mit der nächsten Konto-nonce üblicherweise als pending bezeichnet; eine spätere Nonce, die von einer Lücke blockiert wird, als queued. Diese Bezeichnungen sind Client-Schnittstellen, keine endgültigen Protokollzustände. Eine Transaktion kann vor der Annahme abgelehnt, weitergegeben, durch eine andere signierte Transaktion desselben Absenders und derselben Nonce ersetzt, entfernt, verworfen, erfolgreich aufgenommen, aufgenommen und revertiert oder nach einer Reorganisation erneut berücksichtigt werden.

1
Erstellen

Eine Wallet erstellt eine Transaktion mit Ziel, Wert, Gebührenparametern und Replay-Schutzdaten wie ausgegebenen UTXOs oder einer Nonce.

Funktionsweise

  1. Umgebung festlegen: Chain ID, Execution Client und Version, aktueller Head und Base Fee, Transaktionstyp, Absender, Nonce, Wert, Calldata, Gaslimit, Gebührenobergrenzen und Übermittlungsweg. Öffentliches Gossip, privaten Relay oder Builder und einen ERC-4337-UserOperation-Pfad unterscheiden; sie teilen keinen universellen Pool.
  2. Signierte Bytes decodieren und Prüfungen vor der Annahme durchführen. Signatur und Absender, Chain ID, Typ und Kodierung, Intrinsic Gas, Nonce-Beziehung, Guthaben für Wert plus maximale Gebührenbelastung, Gebührenfelder und erforderliches Blob-Sidecar prüfen. Eine Ablehnung hier ist kein EVM-REVERT und erzeugt normalerweise weder Receipt noch Onchain-Gebühr.
  3. Lokale Pool-Richtlinie erfassen. Festhalten, ob der Client die Transaktion als pending oder queued einstuft, welche Kapazitäten pro Konto und global, Mindestgebührenfilter, Lebensdauer, Ausnahmen für lokale Konten, Replacement Bump und Persistenz gelten. Geth-Flags und Standardwerte dokumentieren Geth, nicht Ethereum-Konsens oder jeden Anbieter.
  4. Weitergabe beobachten, ohne eine globale Sicht zu unterstellen. Raw-Transaction-Hash und signierte Bytes über unabhängige Nodes vergleichen, Abwesenheit aber als mehrdeutig behandeln: Die Node könnte die Transaktion nicht erhalten, nach lokaler Richtlinie abgelehnt, entfernt oder ihren Pool nicht offengelegt haben. Ein privater Pfad kann öffentliches Gossip umgehen und die Transaktion dennoch mit Betreibern und Buildern teilen.
  5. Blockeignung und Reihenfolge im Kandidatenblock modellieren. Bei einer Typ-2-Transaktion beträgt der Execution-Gaspreis min(maxFeePerGas, baseFeePerGas + maxPriorityFeePerGas); übersteigt die Base Fee die Max Fee, ist die Transaktion unter dieser Obergrenze nicht geeignet. Nonce-Abhängigkeiten, Gas- und Blob-Limits, Zustandsgültigkeit, Builder Bundles und MEV können wichtiger sein als der Empfangszeitpunkt.
  6. Lebenszyklus bewusst steuern. Warten oder einen dokumentierten Ersatz mit derselben Nonce erst nach Bestätigung von aktiver Chain, Absender und Ersetzungsrichtlinie senden. Eine Selbstüberweisung mit derselben Nonce ist nur ein weiterer Ersetzungskandidat, keine Stornierungsprimitive. Eine Wertübertragung niemals wiederholen, nur weil ein Explorer das Original nicht mehr zeigt.
  7. Mit dem Konsenszustand abstimmen. Jeden signierten Hash und die Ersetzungslinie aufbewahren, anschließend kanonisches Receipt, Block-Hash, Status, verbrauchtes Gas, Logs, verbrauchte Nonce sowie Konto- oder Contract-Zustand auf erforderlicher Bestätigungs- oder Finalitätsstufe prüfen. Entfernt eine Reorganisation den Block, kann eine weiterhin gültige Transaktion in einige lokale Pools zurückkehren; das hängt von Client und Zustand ab.

Durchgerechnete Beispiele

  • Eignung unter der Gebührenobergrenze. Eine Typ-2-Überweisung hat gasUsed = 21,000, baseFeePerGas = 32 gwei, maxPriorityFeePerGas = 3 gwei und maxFeePerGas = 34 gwei. Ihr effektiver Preis beträgt min(34, 32 + 3) = 34 gwei, der tatsächliche Tip somit 2 gwei. Die Gebühr beträgt 21,000 * 34 = 714,000 gwei = 0.000714 ETH, aufgeteilt in 0.000672 ETH verbrannte Base Fee und 0.000042 ETH Tip. Steigt die Base Fee des Kandidatenblocks auf 35 gwei, reicht die Obergrenze von 34 gwei für diesen Block nicht aus.
  • Nonce-Lücke. Die kanonische Konto-Nonce ist 10. Ein lokaler Pool erhält Transaktionen mit den Nonces 10 und 12, aber keine mit 11; er kann 10 als pending und 12 als queued einstufen. Nach Aufnahme von Nonce 10 wird die kanonische Nonce zu 11; 12 bleibt blockiert, bis eine gültige Transaktion mit Nonce 11 aufgenommen wurde. Die Sichtbarkeit von Nonce 12 in einem Pool macht sie nicht eigenständig ausführbar.
  • Richtlinienspezifische Ersetzung. In einer didaktischen Geth-Konfiguration mit txpool.pricebump = 10 hat die alte Transaktion maxFeePerGas = 40 gwei und maxPriorityFeePerGas = 2 gwei. Ein Aufschlag von 10 % ergibt Schwellen von 44 gwei und 2.2 gwei. Ein Vorschlag mit 43 gwei und 3 gwei kann weiterhin abgelehnt werden, weil eine Obergrenze den konfigurierten Aufschlag verfehlt; 44 gwei und 2.2 gwei erreichen beide didaktischen Schwellen. Exakte Ganzzahlrundung, Transaktionstyp und Annahmelogik sind versionsabhängig; eine andere Node kann einen anderen Kandidaten behalten.
  • Kein globaler Pool. Node A meldet 120,000 verschiedene Transaktions-Hashes, Node B 100,000, ihre Schnittmenge beträgt 80,000. Die Vereinigungsmenge ist 120,000 + 100,000 - 80,000 = 140,000; die Jaccard-Übereinstimmung beträgt 80,000 / 140,000 = 57.1428571429%. 40,000 Hashes sind nur für A und 20,000 nur für B sichtbar. Keine der Zahlen beweist, was Builder, private Relays oder der Rest des Netzwerks sehen.

Risiken

  • Auf der falschen Chain ID oder im falschen Netzwerk signieren oder senden.
  • Einem bösartigen, veralteten oder falsch konfigurierten RPC-Endpunkt vertrauen.
  • Ungültige Signatur, Transaktionstyp, Kodierung oder Blob-Sidecar.
  • Unzureichendes Guthaben für Wert plus maximale Gebührenbelastung.
  • Ablehnung vor der Annahme durch Intrinsic-Gas- oder Calldata-Regeln.
  • Bereits verbrauchte oder zu niedrige Nonce.
  • Eine Nonce-Lücke hält spätere Transaktionen in der Queue.
  • Same-Nonce-Ersatz wird lokal als zu niedrig bepreist abgelehnt.
  • Max Fee liegt unter der Base Fee des Kandidatenblocks.
  • Niedrige effektive Priorität oder Ressourcenlimits verzögern die Aufnahme.
  • Abweichende Richtlinien von Client, Anbieter, Version oder Konfiguration.
  • Pool-Kapazität, Ablauf, Neustart oder Entfernung beseitigt eine Transaktion.
  • Schlechte Peer-Weitergabe, Eclipse oder selektives Relay-Verhalten.
  • Leck, Zensur, Ausfall oder fehlende Builder-Teilnahme beim privaten Relay.
  • Frontrunning, Sandwich oder sonstiges MEV bei öffentlichem Orderflow.
  • Builder-Reihenfolge, Bundles oder private Transaktionen verändern den Ausführungszustand.
  • Simulation wird vor der Aufnahme veraltet.
  • Blinde Doppeleinreichung oder Verlust der Ersetzungslinie.
  • Aufgenommener REVERT, Out of Gas oder abgefangener Subcall-Fehler trotz Pool-Annahme.
  • Reorganisation, Finalitätsverwechslung oder ERC-4337-Mempool als gewöhnlichen Txpool behandeln.

Häufige Irrtümer

  • Der Mempool ist eine global synchronisierte FIFO-Warteschlange.
  • Ein Transaktions-Hash beweist Annahme oder Weitergabe durch das Netzwerk.
  • Pending bedeutet aufgenommen, erfolgreich, unumkehrbar oder beim Empfänger bezahlt.
  • Eine ausreichend hohe Gebühr garantiert Aufnahme und erfolgreiche Ausführung.
  • Ein privater Übermittlungsweg ist automatisch vertraulich, zensurresistent und garantiert erfolgreich.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...