MSTR Cat

Blockchain/Niveau II · Mechanik/2.2 Transaktionen/Lektion 5

Der Mempool

Der lokale Warteraum, den jeder Node unabhängig verwaltet

MaterialienEin Block-Explorer mit Mempool-Ansicht (z. B. mempool.space)Optional: ein Bitcoin-Core-Node („getmempoolinfo“)

Neugier

  1. Warum wird eine Transaktion, die auf einem Full Node gültig ist, von seinem Nachbarn abgelehnt?
  2. Was passiert mit den Transaktionen mit den niedrigsten Gebühren, wenn ein Node seine Speichergrenze erreicht?
  3. Wie entscheiden die Miner, welche noch nicht bestätigten Transaktionen in ihrem nächsten Block Platz finden sollen?

Erkunden

  1. Der Mempool ist keine zentrale Datenbank, sondern eine lokale Liste im Arbeitsspeicher, die jeder Full Node unabhängig verwaltet. Bitcoin Core verwirft unbestätigte Transaktionen, die zu lange warten: nach 72 Stunden, als das Ablaufen in Version 0.12 eingeführt wurde, und seit Version 0.14 nach zwei Wochen (336 Stunden). Zwei Nodes, die Transaktionen in unterschiedlicher Reihenfolge erhalten haben oder mit anderen Einstellungen laufen, haben leicht unterschiedliche Mempools.
  2. Jeder Node wendet Konsensregeln an (etwa gültige Skripte und kein Double Spending) und zusätzlich lokale Richtlinien wie Mindestgebührenraten und RBF-Einstellungen. Erfüllt eine Transaktion die Mindestgebührenrate eines bestimmten Nodes nicht, lehnt dieser Node sie ab oder entfernt sie, falls sie bereits aufgenommen wurde, selbst wenn andere Nodes sie akzeptieren.
  3. Standardmäßig begrenzt Bitcoin Core die Größe des Mempools über den Parameter „maxmempool“ in der Datei bitcoin.conf auf 300 MB. Ist diese Grenze erreicht, hebt der Node seine Mindestgebührenschwelle dynamisch an, um Platz für profitablere Transaktionen zu schaffen, und verdrängt dabei zuerst die am wenigsten wertvollen. Führen Sie „getmempoolinfo“ aus und beobachten Sie, wie „mempoolminfee“ über den statischen Wert „minrelaytxfee“ steigt, wenn sich der Mempool füllt.
  4. Miner wählen Transaktionen aus ihren eigenen Mempools aus, um Blöcke zu bauen, und priorisieren dabei die höchste Gebühr pro virtuellem Byte, bewertet zusammen mit allen unbestätigten Eltern-Transaktionen. Sobald ein gültiger Block eintrifft, entfernt jeder Node die bestätigten Transaktionen sowie alle dazu in Konflikt stehenden aus seinem Pool.
  5. Richtlinien sind kein Konsens. Eine Transaktion, die die meisten Nodes nicht weiterleiten, weil sie unter ihrer Gebührenuntergrenze liegt oder eine nicht standardmäßige Form verwendet, kann in einem Block trotzdem gültig sein, und manche Miner nehmen solche Transaktionen direkt an. Daher ist der Mempool jedes Nodes nur eine Schätzung dessen, was der nächste Block enthalten wird, und verschiedene Nodes können in Grenzfällen voneinander abweichen.
  6. Beim Herunterfahren speichert Bitcoin Core seinen Mempool in einer Datei, mempool.dat, und lädt ihn beim Start wieder, wobei alles verworfen wird, was nicht mehr gültig ist; so beginnt ein neu gestarteter Node nicht mit einem leeren Pool. Um den Mempool bei der Arbeit zu beobachten, öffnen Sie mempool.space: Die dort projizierten Blöcke zeigen, was Miner voraussichtlich als Nächstes aufnehmen, und jeder neue Block räumt die oberste Schicht ab.

Kernfakten

  • Der Mempool ist ein lokaler Speicherpool auf jedem Node, kein einzelner universeller Dienst.
  • Bitcoin Core verwendet standardmäßig eine Obergrenze von 300 MB für die Größe des Mempools über den Parameter „maxmempool“.
  • Bitcoin Core löscht standardmäßig nach zwei Wochen (336 Stunden, seit Version 0.14) unbestätigte Transaktionen.
  • Nodes wenden sowohl Konsensregeln als auch lokale Richtlinien an, einschließlich Mindestgebührenraten.
  • Ist der Mempool voll, heben Nodes ihre Gebührenschwellen dynamisch an, um weniger profitable Transaktionen zu verdrängen.
  • Bitcoin Core speichert seinen Mempool beim Herunterfahren in „mempool.dat“, damit er nach einem Neustart erhalten bleibt.

Übung neun, sechs, drei, eins

9SammelnListen Sie 9 verschiedene unbestätigte Transaktionen aus der Mempool-Ansicht eines Block-Explorers auf. Notieren Sie ihre aktuellen Gebührenraten, ihre Größe in virtuellen Bytes und die Anzahl ihrer Bestätigungen (alle null).
6GruppierenGruppieren Sie die 9 Transaktionen in 6 Kategorien danach, warum sie feststecken könnten: niedrige Gebührenrate, großer Umfang, RBF-Signalisierung, unbestätigte Inputs, Orphan-Status oder andere Richtliniengründe.
3VerdichtenReduzieren Sie die 6 Gruppen auf 3 zentrale Gründe, warum ein Node eine Transaktion ablehnen oder aus seinem Mempool entfernen würde, obwohl sie konsensgültig ist.
1KristallisierenSchreiben Sie 1 Satz, der erklärt, wie lokale Richtlinienunterschiede zwischen Nodes zu einer fragmentierten, nicht einheitlichen Sicht auf ausstehende Transaktionen im gesamten Netzwerk führen.

Faktcheck

Datumsangaben, Zahlen und Behauptungen wurden mit den unten aufgeführten veröffentlichten Quellen abgeglichen.

In der interaktiven Akademie öffnen →

EN PT ES ZH JA KO RU FR MS