Wie werden Transaktionen über das Bitcoin-Netzwerk verbreitet? (Ausführlich)

Ich kenne das allgemeine Klatschprotokoll, das auftritt, dh Transaktionen werden an benachbarte Knoten gesendet, die sie dann an ihre Kollegen senden usw., aber ich habe versucht, eine ausführlichere Antwort darauf zu finden, wie Transaktionen über das Bitcoin-Netzwerk gesendet werden.

Ich habe kurz in einem Artikel gelesen, dass es eine Art Transaktionswarteschlange gibt, die der Knoten für jeden Nachbarn führt, und dass sie nur eine zufällige (?) Anzahl dieser Transaktionen auswählen und eine INV-Nachricht an diese Knoten senden.

Warum senden sie ihnen nicht alle Transaktionen in der Warteschlange und warum wartet es eine zufällige Zeitspanne, um die Transaktionen in der Warteschlange zu senden?

Jede Hilfe wäre toll, danke!

Antworten (2)

Ich habe kurz in einem Artikel gelesen, dass es eine Art Transaktionswarteschlange gibt, die der Knoten für jeden Nachbarn führt, und dass sie nur eine zufällige (?) Anzahl dieser Transaktionen auswählen und eine INV-Nachricht an diese Knoten senden.

Beachten Sie, dass dies spezifisch für Bitcoin Core ist. Andere Full-Node-Software zeigt dieses Verhalten möglicherweise nicht.

Wenn Bitcoin Core eine Transaktion erhält, fügt es die Transaktion zu Listen hinzu, die es für jeden anderen Knoten verwaltet, mit dem es verbunden ist. Jeder Knoten hat seine eigene Liste und diese Liste enthält alle Transaktionen, die Ihr Knoten empfangen hat, aber möglicherweise nicht von dem anderen Knoten empfangen wurden. Nach einer bestimmten zufälligen Zeitverzögerung sendet Ihr Knoten dann Nachrichten an den anderen Knoten. Unter den gesendeten Nachrichten befindet sich ein INV für Transaktionen in der Liste für diesen Knoten.

Es werden jedoch nicht alle Transaktionen in der Liste gesendet. Nur ein Teil davon wird gesendet. Um auszuwählen, welche Transaktionen gesendet werden, sortiert Ihr Knoten die Transaktionsliste nach der Anzahl seiner Vorfahren (so dass übergeordnete Transaktionen vor untergeordneten Transaktionen weitergeleitet werden) und nach ihrer Gebührenrate. Die Transaktionen mit den wenigsten Vorfahren und der höchsten Gebührenrate werden an der Spitze stehen. Transaktionen werden aus dieser sortierten Liste ausgewählt, bis entweder die INV-Nachricht ihr Limit erreicht (was selten vorkommt) oder keine Transaktionen mehr übrig sind. Sobald Transaktionen ausgewählt sind, wird die INV gesendet.

Warum senden sie ihnen nicht alle Transaktionen in der Warteschlange und warum wartet es eine zufällige Zeitspanne, um die Transaktionen in der Warteschlange zu senden?

Die zufällige Verzögerung zwischen den Sendungen erfolgt aus Datenschutzgründen. Die Sortierung der Transaktionen erfolgt, um die Transaktionen zu priorisieren, die von den Minern zuerst ausgewählt werden. Es hilft auch bei der Privatsphäre.

Der Grund, warum diese beim Datenschutz helfen, ist, dass ein Spionageknoten, der sich mit Ihrem Knoten verbunden hat, nicht immer wissen kann, welche Transaktionen Ihr Knoten empfangen hat und wie Ihr Mempool aussieht. Es kann nicht wissen, welche Transaktionen Sie zuerst erhalten haben. Darüber hinaus ist es aufgrund der zufälligen Verzögerungen möglich, dass ein direkt mit Ihrem Knoten verbundener Knoten Ihre Transaktion zuerst von jemand anderem erhält, wenn eine Transaktion von Ihrem Knoten stammt, wodurch die Sicherheit solcher Analysen verringert wird.

Es gibt tatsächlich ein Limit, wie viel auf einmal verschickt wird, aber dieses Limit ist relativ hoch und wird selten erreicht. In den meisten Fällen wird der gesamte Puffer gesendet. Die Sortierung erfolgt in erster Linie, um sicherzustellen, dass die Eltern vor den Kindern geschickt werden, um Waisenkinder zu vermeiden.
"Sortieren Sie die Transaktionsliste nach der Anzahl der Vorfahren". Vielleicht möchten Sie erwähnen, dass dies nur eine rechengünstige Methode ist, um sicherzustellen, dass Eltern vor Kindern weitergeleitet werden.

Jeder Full-Node sendet eine INVNachricht an alle aktiven Peer-Kanäle, wenn eine neue Transaktion im lokalen Mempool organisiert wird, mit Ausnahme des Kanals, von dem die Transaktion empfangen wurde.

In einem bestimmten Kanal abonniert der Knoten intern die folgenden Ereignisse im Zusammenhang mit dem Empfang neuer eingehender Transaktionen:

  • 1) INVNachricht vom Peer
  • 2) TXNachricht vom Peer
  • 3) Lokale Mempool-Organisationsveranstaltung (neues TX akzeptiert)

Wenn er von einem Peer ein INV mit einer neuen TXID erhält, fordert er die vollständige Transaktion mit GETDATA(INV) an. Wenn es eine TX-Nachricht empfängt, wird diese im Mempool entweder akzeptiert oder abgelehnt. Nach der Annahme (lokales Mem-Pool-Organisationsereignis [3]) sendet ein Handler eine INV(TX)-Nachricht an alle Kanäle (außer demjenigen, wo der TX zuerst gesehen wurde).

Ich kenne keine einzelnen Kanal-Transaktionswarteschlangen in irgendeiner Bitcoin-Implementierung.