---
title: "Mempools und Transaktionspools"
description: "Node-lokaler Leitfaden zu Ethereum-Transaktionsannahme, ausstehenden und zurückgestellten Nonces, Weitergabe, Gebühreneignung, Ersetzung, privatem Orderflow, Aufnahme, Entfernung und Reorganisation."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Mempools und Transaktionspools
> 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.
## 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
- [Gasgebühren](/de/crypto/gas-fee/)
- [Mempool-Ersetzung](/de/crypto/mempool-replacement/)
- [MEV](/de/crypto/mev/)
## Quellen
- [Transactions](https://ethereum.org/developers/docs/transactions/) - Ethereum.org (abgerufen: 2026-08-13)
- [EIP-1559: Fee market change for ETH 1.0 chain](https://eips.ethereum.org/EIPS/eip-1559) - Ethereum Improvement Proposals (abgerufen: 2026-08-13)
- [txpool Namespace](https://geth.ethereum.org/docs/interacting-with-geth/rpc/ns-txpool) - go-ethereum (abgerufen: 2026-08-13)
- [Command-line Options](https://geth.ethereum.org/docs/fundamentals/command-line-options) - go-ethereum (abgerufen: 2026-08-13)
- [JSON-RPC API](https://ethereum.org/developers/docs/apis/json-rpc/) - Ethereum.org (abgerufen: 2026-08-13)
- [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals (abgerufen: 2026-08-13)
- [ERC-4337: Account Abstraction Using Alt Mempool](https://eips.ethereum.org/EIPS/eip-4337) - Ethereum Improvement Proposals (abgerufen: 2026-08-13)
- [MEV Protection Overview](https://docs.flashbots.net/flashbots-protect/overview) - Flashbots Documentation (abgerufen: 2026-08-13)
Source: https://wiki.fcontext.com/de/crypto/mempool/index.mdx