Was ist der Mempool überhaupt?
Bevor eine Transaktion Teil der Blockchain werden kann, muss sie zunächst von den Nodes im Netzwerk empfangen und überprüft werden.
Besteht sie diese Prüfung und erfüllt die lokalen Regeln einer Node, wird sie vorübergehend im Mempool (Memory Pool) gespeichert.
Der Mempool ist damit der Zwischenspeicher einer Node für gültige, aber noch unbestätigte Transaktionen. Von dort werden Transaktionen an andere Nodes weitergeleitet und können von Minern für den nächsten Block ausgewählt werden.
Erst wenn eine Transaktion in einen gültigen Block aufgenommen wurde, verlässt sie den Mempool und wird dauerhaft Teil der Blockchain.
Mempool einer Node
lokal · temporär · unbestätigt
Beispielzustand
4.448 Transaktionen
7,43 MiB RAM
maxmempool 300 MB
minRelayTxFee 1 sat/vB
Speicherlimit
7,43 MiB von 300 MB
Bei Erreichen des Limits können Transaktionen verdrängt werden.
Transaktionen im Mempool
- Fee-Rate · relative Balkenlänge innerhalb dieses Beispiels
- rbfReplace-by-Fee
- Parent / ChildAbhängigkeit
Indizes
vereinfachte Auswahl interner Sichten
- txid
- fee rate
- entry time
- ancestors
- descendants
Die Node verwaltet mehrere Sichten auf dieselben Mempool-Einträge.
Abhängigkeiten
Eine Mempool-Transaktion kann den Output einer anderen noch unbestätigten Transaktion ausgeben.
unbestätigter Output → neuer Input
Transaktion im Mempool
CTxMemPoolEntry · vereinfachte Darstellung
Ausgewählte Informationen, die diese Node zu einer unbestätigten Transaktion verwaltet.
- TXID
- 7f3a91bc…6d204e18
- Fee
- 8.320 sats
- Fee-Rate
- 32,4 sat/vB
- vSize
- 257 vB
- Weight
- 1.028 WU
- Aufgenommen
- vor 3 Minuten
- RBF
- signalisiert
- Ancestors
- 1
- Descendants
- 2
- lokaler Zustand dieser Node
- nicht Teil der Blockchain
- kann sich jederzeit ändern
- wird überwiegend im Arbeitsspeicher verwaltet
Warum landet nicht jede Transaktion im Mempool?
Eine Node nimmt eine Transaktion nicht allein deshalb in ihren Mempool auf, weil sie über das Netzwerk empfangen wurde.
Vor der Aufnahme prüft eine Node zunächst, ob die Transaktion die Konsensregeln von Bitcoin erfüllt. Anschließend entscheidet ihre lokale Mempool-Policy, ob die Transaktion gespeichert und an andere Nodes weitergeleitet wird.
Verletzt eine Transaktion die Konsensregeln, ist sie grundsätzlich ungültig. Das ist beispielsweise der Fall, wenn sie nicht vorhandene oder bereits ausgegebene UTXOs verwendet, eine Signaturprüfung fehlschlägt oder mehr Bitcoin ausgibt, als ihre Inputs bereitstellen.
Besteht sie die Konsensprüfung, ist ihre Aufnahme dennoch nicht garantiert. Zusätzlich muss sie auch die lokale Mempool-Policy der empfangenden Node erfüllen.
Die lokale Mempool-Policy kann eine Transaktion beispielsweise ablehnen, wenn:
- ihre Gebührenrate unter der aktuell erforderlichen Mindestgebührenrate liegt,
- sie nach den Standardness-Regeln als nicht standardmäßig gilt,
- sie mit einer bereits im Mempool vorhandenen Transaktion konkurriert und die Voraussetzungen für eine Ersetzung nicht erfüllt,
- unbestätigte Vorgängertransaktionen fehlen oder noch nicht im Mempool vorhanden sind,
- oder ihre Aufnahme gegen lokale Grenzen für zusammenhängende Transaktionen verstößt.
Eine Transaktion kann daher nach den Konsensregeln gültig sein und trotzdem nicht im Mempool einer bestimmten Node landen.
Das bedeutet nicht zwangsläufig, dass sie niemals bestätigt werden kann. Ein Miner könnte eine konsensgültige Transaktion direkt in einen Block aufnehmen, auch wenn andere Nodes sie zuvor aufgrund ihrer lokalen Policy weder in ihren Mempool aufgenommen noch weitergeleitet haben.
Warum spielen Gebühren eine so große Rolle?
Der Platz in einem Bitcoin-Block ist begrenzt. Deshalb können Miner nicht alle Transaktionen aus ihrem Mempool in den nächsten Block aufnehmen.
Bei der Auswahl spielt vor allem die Gebührenrate einer Transaktion
eine Rolle. Sie gibt an, wie viele Satoshis eine Transaktion pro virtuellem Byte zahlt und wird in sat/vB angegeben.
Eine hohe absolute Gebühr bedeutet daher nicht automatisch eine hohe Priorität. Entscheidend ist das Verhältnis zwischen der gezahlten Gebühr und dem Platz, den die Transaktion im Block benötigt.
Obwohl Transaktion B die höhere absolute Gebühr zahlt, ist Transaktion A für einen Miner pro belegtem virtuellem Byte wirtschaftlicher.
Solange im Mempool mehr Transaktionen warten, als in den nächsten Block passen, konkurrieren sie um den verfügbaren Blockplatz. Transaktionen mit einer höheren Gebührenrate haben daher in der Regel bessere Chancen, früher bestätigt zu werden.
Dabei betrachten Miner jedoch nicht immer nur einzelne Transaktionen. Hängen mehrere unbestätigte Transaktionen voneinander ab, kann ihre gemeinsame Gebührenrate für die Auswahl entscheidend sein. Dieses Verfahren wird bei Child Pays for Parent genutzt.
Wie Transaktionsgebühren entstehen und wie Wallets eine passende Gebührenrate bestimmen, betrachten wir auf der Seite Transaktionsgebühren ausführlich.
Was passiert mit konkurrierenden Transaktionen?
Zwei Transaktionen konkurrieren miteinander, wenn sie mindestens denselben UTXO ausgeben wollen.
Da ein UTXO nur einmal ausgegeben werden kann, können nicht beide Transaktionen Teil derselben gültigen Blockchain werden.
Befindet sich bereits eine der beiden Transaktionen im Mempool einer Node, lehnt die Node die konkurrierende Transaktion normalerweise ab. Welche Transaktion zuerst im Mempool landet, kann sich jedoch von Node zu Node unterscheiden, weil sie die Transaktionen zu unterschiedlichen Zeitpunkten und über unterschiedliche Peers empfangen.
Eine bereits gespeicherte Transaktion kann unter bestimmten Bedingungen ersetzt werden. Signalisiert sie Replace-by-Fee und erfüllt die neue Transaktion die geltenden Ersetzungsregeln, entfernt die Node die bisherige Transaktion aus ihrem Mempool und nimmt stattdessen die neue Version auf.
Ohne eine zulässige Ersetzung bleibt für diese Node zunächst Transaktion A im Mempool. Das ist jedoch noch keine endgültige Entscheidung darüber, welche Transaktion bestätigt wird.
Nimmt ein Miner Transaktion B in einen gültigen Block auf, akzeptieren die Nodes diesen Block und entfernen Transaktion A aus ihrem Mempool. Der gemeinsam verwendete UTXO wurde nun durch Transaktion B ausgegeben und kann nicht mehr von Transaktion A verwendet werden.
Was passiert, wenn der Mempool voll wird?
Der Mempool einer Node ist nicht unbegrenzt. In Bitcoin Core legt die Einstellung
maxmempool fest, wie viel Speicher der Mempool höchstens verwenden soll.
Nähert sich der Mempool diesem Limit, beginnt die Node, Transaktionen mit den niedrigsten effektiven Gebührenraten zu entfernen. Dabei werden auch Abhängigkeiten berücksichtigt: Wird eine Parent-Transaktion entfernt, müssen in der Regel auch ihre unbestätigten Descendants den Mempool verlassen.
Gleichzeitig steigt die lokale Mindestgebührenrate des Mempools. Neue Transaktionen werden dann nur noch aufgenommen, wenn ihre Gebührenrate über dieser Schwelle liegt.
Mempool erreicht sein Speicherlimit
maxmempool
Transaktionen mit niedriger effektiver Fee-Rate werden entfernt
inkl. abhängiger Descendants
lokale Mempool-Mindestgebühr steigt
höhere Aufnahmeschwelle
günstigere neue Transaktionen werden abgelehnt
unter der lokalen Schwelle
Diese Mindestgebührenrate ist kein fester Wert für das gesamte Bitcoin-Netzwerk. Sie hängt vom aktuellen Zustand und von der Konfiguration der jeweiligen Node ab.
Wird später durch neue Blöcke wieder Platz im Mempool frei, sinkt die erhöhte Mindestgebührenrate nicht sofort auf ihren Ausgangswert zurück, sondern wird mit der Zeit schrittweise abgesenkt.
Eine entfernte Transaktion wird dadurch nicht ungültig. Sie befindet sich lediglich nicht mehr im Mempool dieser Node. Sie kann später erneut empfangen und aufgenommen werden, sofern sie dann wieder die lokale Mempool-Policy erfüllt.
Warum sieht jede Node einen anderen Mempool?
Oft wird vom Mempool gesprochen, als gäbe es einen einzigen gemeinsamen Speicher für alle unbestätigten Transaktionen. Tatsächlich besitzt jedoch jede Node ihren eigenen lokalen Mempool.
Welche Transaktionen sich darin befinden, hängt von mehreren Faktoren ab. Nodes empfangen Transaktionen zu unterschiedlichen Zeitpunkten, sind mit unterschiedlichen Peers verbunden und können verschiedene Einstellungen für ihre Mempool-Policy verwenden.
Dadurch kann eine Transaktion im Mempool einer Node bereits vorhanden sein, während eine andere Node sie noch gar nicht gesehen oder aufgrund ihrer lokalen Policy abgelehnt hat.
Auch der aktuelle Zustand des Mempools spielt eine Rolle. Ist der Mempool einer Node nahezu voll, kann sie Transaktionen mit niedriger Gebührenrate verdrängen, während eine andere Node mit mehr freiem Speicher dieselben Transaktionen weiterhin behält.
Deshalb zeigt die folgende Visualisierung bewusst nur den lokalen Mempool der BitcoinVonInnen-Node: den Live-Stream eingehender Transaktionen als Kacheln. Die Kachelfläche entspricht der vSize, die Farbe der Fee-Rate in sat/vB. Andere Nodes können zur gleichen Zeit einen anderen Bestand sehen.
Mempool · Live
lädtQuelle: BitcoinVonInnen Node
Lade …
unbestätigt—
Stream0 TXs
Größe—
min fee—
Mit der Zeit gleichen sich die Mempools vieler Nodes häufig an, weil Transaktionen weitergeleitet und neue Blöcke gemeinsam verarbeitet werden. Vollständig identisch müssen sie jedoch zu keinem Zeitpunkt sein.
Einen Überblick über unterschiedliche Node-Ansichten im Netzwerk findest du unter wiz.biz/bitcoin/nodes.