Der Mempool scheint derzeit fast 60.000 unbestätigte Transaktionen zu enthalten , und die Zahl scheint zu steigen. Laut dieser Frage scheinen unbestätigte Transaktionen schließlich gelöscht zu werden.
Andere Antworten weisen darauf hin, dass es unpraktisch ist, die Transaktionen anderer zu behindern, indem Sie versuchen, Blöcke mit Ihren eigenen Transaktionen zu füllen. Diese Frage erwähnt jedoch nicht die Probleme, denen die Nodes gegenüberstehen würden, wenn sie mit einer zu großen Anzahl von Transaktionen umgehen müssten, die herumgereicht werden (ohne zu berücksichtigen, dass sie überhaupt in den Block aufgenommen werden).
Wäre es für einen böswilligen Benutzer möglich, viele Transaktionen (z. B. von derselben gültigen Adresse) an das Netzwerk zu senden, um die Größe der Knoten-Mempools zu erhöhen und somit Probleme zu verursachen? Ist so etwas passiert?
Oder erfolgt die Bereinigung schnell genug und sind die nicht ausgegebenen Transaktionen klein genug, damit ein wachsender Mempool kein Problem für die Netzwerkknoten darstellt? Sind noch weitere gemeinsame Features implementiert, die vor einem Aufblähen des Mempools schützen?
Zunächst einmal gibt es kein "The Mempool". Jeder Full Node hat einen individuellen Mempool, und da diese keine bereits in Blöcken befindlichen Transaktionen (bestätigte Transaktionen) enthalten, kann definitionsgemäß nicht garantiert werden, dass Nodes darüber übereinstimmen. Was Sie also sehen, ist der Mempool von blockchain.info, der dem anderer Knoten ähnlich sein kann oder auch nicht.
Was kann Unterschiede zwischen Mempools verursachen? Ein offensichtliches Beispiel ist der Fall einer doppelten Ausgabe: Es sind keine widersprüchlichen Transaktionen zulässig. Wenn also zwei unterschiedliche Transaktionen, die dieselben Eingaben ausgeben, an verschiedene Stellen des Netzwerks gesendet werden, akzeptieren einige die eine, andere die andere. basierend darauf, was sie zuerst hören. Das ist aber nicht der einzige Unterschied. Knoten können auch unterschiedliche Mempool-Akzeptanzrichtlinien haben.
Der Mempool eines Knotens ist letztendlich seine Erwartung für das, was Transaktionen kurz- bis mittelfristig vernünftigerweise bestätigen können. Gute Mempool-Akzeptanzrichtlinien versuchen, diese Erwartung zu modellieren. Wenn die Gebühr einer Transaktion sehr niedrig ist, lohnt es sich möglicherweise nicht, sie zu behalten, wenn zuerst viele Transaktionen mit höheren Gebühren abgebaut werden müssen.
Und das ist die Grundlage für den Mempool-DoS-Schutz, der in Bitcoin Core 0.12 hinzugefügt wurde. Immer wenn die Speichernutzung des Mempools eine bestimmte vorkonfigurierte Größe (die -maxmempoolEinstellung) überschreitet, werfen wir die Transaktionen mit der niedrigsten Gebührenrate aus und erhöhen (vorübergehend) die Mindestgebührenrate, um in Zukunft auf die der geräumten zu gelangen. Das löst das Problem der unbegrenzten Speichernutzung.
Aber was ist mit der Bandbreite? Dinge wie BIP125 und diese oben beschriebene Räumung führen im Wesentlichen dazu, dass Broadcasting-Transaktionen beibehalten und akzeptiert und andere Transaktionen ersetzt werden können, ohne wirklich etwas zu bezahlen. Ich sage hier zahlen, weil die grundlegende Regel, auf der wir Entscheidungen über Mempool-Richtlinien stützen, lautet, dass wir erwarten, dass Transaktionen im Mempool bestätigt werden und somit ihre Gebühr zahlen. Daher möchten wir eine Regel, dass immer dann, wenn etwas aus dem Mempool entfernt wird (aus irgendeinem anderen Grund als der Bestätigung), etwas anderes "etwas" für dieses Relais bezahlt. In der Praxis wird dies durch eine separat konfigurierte Relaisgebühr erreicht (die sich nicht ändert, wenn der Mempool voll ist), die den "Preis" für das Relais festlegt. Im Falle einer Mempool-Räumung,
OO