Relay

Was ist mit Relay gemeint?

Relay bezeichnet in Bitcoin die Weitergabe von Transaktionen und Blöcken zwischen miteinander verbundenen Peers.

Eine Node ist nicht mit allen Nodes des Bitcoin-Netzwerks direkt verbunden. Sie kommuniziert nur mit ihren eigenen Peers.

Erhält eine Node eine neue Transaktion oder einen neuen Block, kann sie die Information darüber an weitere Peers weitergeben. Diese wiederum können sie an ihre eigenen Peers weiterleiten.

Auf diese Weise verbreiten sich neue Transaktionen und Blöcke schrittweise durch das Bitcoin-Netzwerk.

Dabei entscheidet jede Node selbst, welche Daten sie akzeptiert und weiterleitet. Bei unbestätigten Transaktionen spielen unter anderem die lokalen Policy-Regeln und der Mempool der Node eine Rolle.

Wie diese Weitergabe technisch über P2P-Nachrichten wie INV, GETDATA und TX funktioniert, betrachten wir im nächsten Abschnitt.

Wie verbreitet sich eine Transaktion?

Eine neue Transaktion wird im Bitcoin-Netzwerk normalerweise nicht sofort vollständig an alle verbundenen Peers gesendet.

Stattdessen kündigt eine Node eine ihr bekannte Transaktion zunächst gegenüber anderen Peers an. Ein Peer, der diese Transaktion noch nicht besitzt und sie anfordern möchte, kann anschließend die vollständigen Transaktionsdaten abrufen.

Der grundlegende Ablauf besteht aus drei P2P-Nachrichten:

1. INV: eine Node kündigt eine Transaktion an.
2. GETDATA: ein Peer fordert die angekündigte Transaktion an.
3. TX: die vollständige Transaktion wird übertragen.

Empfängt deine Node beispielsweise ein INV für eine ihr unbekannte Transaktion, kann sie diese mit GETDATA anfordern. Der Peer überträgt daraufhin die vollständige Transaktion mit einer TX-Nachricht.

Nach dem Empfang prüft deine Node die Transaktion. Wird sie akzeptiert und in den Mempool aufgenommen, kann deine Node nun selbst zum Ankündiger werden und die Transaktion gegenüber weiteren Peers bekannt machen.

Der gleiche Ablauf beginnt damit erneut, nur mit vertauschten Rollen:

Deine Node kündigt mit INV an → ein Peer fordert mit GETDATA an → deine Node überträgt mit TX.

Mehrere Peers können dieselbe Transaktion nahezu gleichzeitig ankündigen. Deine Node muss die vollständige Transaktion deshalb nicht von jedem dieser Peers herunterladen. Wird die Transaktion bereits angefordert, führen weitere Ankündigungen derselben Transaktion normalerweise nicht zu zusätzlichen GETDATA-Anfragen.

Auf diese Weise verbreitet sich eine Transaktion schrittweise von Node zu Node durch das Bitcoin-Netzwerk.

INV – Transaktion ankündigen

INV steht für Inventory.

Mit einer INV-Nachricht informiert eine Node einen Peer darüber, dass sie bestimmte Objekte kennt.

Bei einer Transaktion enthält die Ankündigung nicht die vollständige Transaktion. Stattdessen wird ein Inventory-Eintrag übertragen, über den die Transaktion identifiziert werden kann.

Vereinfacht sagt die sendende Node damit:

„Ich kenne diese Transaktion.“

Dabei kann deine Node sowohl Sender als auch Empfänger einer INV-Nachricht sein.

Empfängt deine Node ein INV, kann sie feststellen, ob ihr die angekündigte Transaktion bereits bekannt ist. Ist sie unbekannt und möchte deine Node sie erhalten, kann sie die Transaktion anschließend mit GETDATA anfordern.

Hat deine Node eine Transaktion dagegen bereits selbst akzeptiert, kann sie diese gegenüber anderen Peers mit INV ankündigen. Diese entscheiden wiederum selbst, ob ihnen die Transaktion bereits bekannt ist oder ob sie diese anfordern möchten.

Die vollständige Transaktion wird mit INV noch nicht übertragen. Dadurch müssen Peers keine Transaktionsdaten herunterladen, die ihnen bereits bekannt sind.

GETDATA – Transaktion anfordern

Mit einer GETDATA-Nachricht fordert eine Node ein zuvor angekündigtes Objekt von einem Peer an.

Vereinfacht sagt die anfordernde Node damit:

„Schick mir dieses angekündigte Objekt.“

Hat deine Node beispielsweise ein INV für eine ihr unbekannte Transaktion erhalten, kann sie die Transaktion mit GETDATA bei diesem Peer anfordern.

Die Richtung kann jedoch genauso umgekehrt sein: Kündigt deine Node eine Transaktion mit INV an, kann ein anderer Peer diese anschließend mit GETDATA bei deiner Node anfordern.

Die Anfrage identifiziert die gewünschte Transaktion über den entsprechenden Inventory-Eintrag.

Erst wenn die Transaktion tatsächlich angefordert wird, muss der Peer die vollständigen Transaktionsdaten übertragen.

TX – Transaktion übertragen

Mit einer TX-Nachricht wird die vollständige serialisierte Transaktion zwischen zwei Peers übertragen.

Hat deine Node eine Transaktion zuvor mit GETDATA angefordert, kann der Peer darauf mit TX antworten und die vollständige Transaktion übertragen.

Umgekehrt kann auch deine Node eine TX-Nachricht senden: Fordert ein Peer eine von deiner Node angekündigte Transaktion mit GETDATA an, kann deine Node ihm die vollständige Transaktion mit TX übertragen.

Im Gegensatz zu INV enthält TX nicht nur eine Ankündigung, sondern die eigentlichen Transaktionsdaten.

Nach dem Empfang kann die empfangende Node die Transaktion prüfen.

Wird sie akzeptiert, kann sie in den Mempool der Node aufgenommen werden.

Anschließend kann die empfangende Node die Transaktion wiederum gegenüber weiteren Peers ankündigen.

Damit beginnt derselbe Ablauf mit vertauschten Rollen erneut:

INV → GETDATA → TX

Auf diese Weise verbreitet sich eine Transaktion schrittweise von Node zu Node durch das Bitcoin-Netzwerk.

Wie verbreitet sich ein Block?

Neue Blöcke müssen sich ebenso wie Transaktionen zwischen den Nodes des Bitcoin-Netzwerks verbreiten.

Bei Blöcken ist eine schnelle Weitergabe besonders wichtig. Je schneller andere Nodes von einem neuen Block erfahren, desto schneller können sie ihn prüfen und ihre lokale Sicht auf die Blockchain aktualisieren.

Bitcoin verwendet dafür verschiedene P2P-Nachrichten und Relay-Verfahren.

Der klassische Ablauf zur Ankündigung und Übertragung eines vollständigen Blocks ähnelt dem Transaction Relay:

1. INV: eine Node kündigt einen Block an.
2. GETDATA: ein Peer fordert den angekündigten Block an.
3. BLOCK: der vollständige Block wird übertragen.

Empfängt deine Node beispielsweise ein INV für einen ihr unbekannten Block, kann sie diesen mit GETDATA anfordern. Der Peer überträgt daraufhin den vollständigen Block mit einer BLOCK-Nachricht.

Nach dem Empfang prüft deine Node den Block. Wird er akzeptiert und an die lokale Chain angefügt, kann deine Node den Block gegenüber weiteren Peers ankündigen.

Der gleiche Ablauf beginnt damit erneut, nur mit vertauschten Rollen:

Deine Node kündigt mit INV an → ein Peer fordert mit GETDATA an → deine Node überträgt mit BLOCK.

Mehrere Peers können denselben Block nahezu gleichzeitig ankündigen. Deine Node muss den vollständigen Block deshalb nicht von jedem dieser Peers herunterladen.

INV – Block ankündigen

Eine INV-Nachricht kann neben Transaktionen auch einen Block ankündigen.

Dabei wird nicht der vollständige Block übertragen. Die Nachricht informiert den Peer zunächst darüber, dass die sendende Node einen bestimmten Block kennt.

Vereinfacht:

„Ich kenne diesen Block.“

Dabei kann deine Node sowohl Sender als auch Empfänger einer INV-Nachricht sein.

Benötigt der empfangende Peer den Block, kann er die entsprechenden Blockdaten anschließend anfordern.

GETDATA – Block anfordern

Mit GETDATA kann ein Peer einen angekündigten Block anfordern.

Vereinfacht sagt die anfordernde Node damit:

„Schick mir diesen angekündigten Block.“

Wie beim Transaction Relay können auch hier die Rollen wechseln: Deine Node kann einen Block von einem Peer anfordern oder selbst auf die Anfrage eines anderen Peers reagieren.

Erst wenn der Block tatsächlich angefordert wird, müssen die vollständigen Blockdaten übertragen werden.

BLOCK – vollständigen Block übertragen

Wird ein vollständiger Block angefordert, kann dieser mit einer BLOCK-Nachricht übertragen werden.

Hat deine Node einen Block zuvor mit GETDATA angefordert, kann der Peer darauf mit BLOCK antworten.

Umgekehrt kann auch deine Node eine BLOCK-Nachricht senden: Fordert ein Peer einen von deiner Node angekündigten Block mit GETDATA an, kann deine Node ihm den vollständigen Block mit BLOCK übertragen.

Vereinfacht ergibt sich damit:

INV → GETDATA → BLOCK

Wie werden Transaktionen an Peers angekündigt?

Wird eine Transaktion von einer Node akzeptiert, bedeutet das nicht, dass sie die Transaktion sofort und gleichzeitig gegenüber allen verbundenen Peers ankündigt.

Transaction Relay wird für jede Peer-Verbindung einzeln behandelt.

Ob eine Transaktion gegenüber einem bestimmten Peer angekündigt wird, hängt unter anderem davon ab, ob über diese Verbindung Transaktionen weitergeleitet werden und welche Relay-Einstellungen der Peer mitgeteilt hat.

Nicht jeder Peer erhält jede Ankündigung

Eine Peer-Verbindung kann so konfiguriert oder ausgehandelt sein, dass darüber keine Transaktionen weitergeleitet werden.

Zusätzlich kann ein Peer mit FEEFILTER mitteilen, unterhalb welcher Fee-Rate er keine Transaktionsankündigungen erhalten möchte.

Die sendende Node kann diesen Wert bei ihren Ankündigungen berücksichtigen und Transaktionen unterhalb dieses Schwellenwerts gegenüber diesem Peer nicht ankündigen. Mehr zur Gebührenpolitik unter Wann ist eine Gebühr zu niedrig?.

Dadurch kann dieselbe Node gegenüber verschiedenen Peers unterschiedliche Transaktionen ankündigen.

Ankündigungen erfolgen zeitlich versetzt

Transaktionen werden außerdem nicht einfach unmittelbar nach ihrer Annahme gleichzeitig an alle geeigneten Peers angekündigt.

Bitcoin Core plant Transaktionsankündigungen für einzelne Peer-Verbindungen zeitlich versetzt ein.

Dadurch kann beispielsweise folgende Situation entstehen:

Peer A erhält INV(X) früher als Peer B, während Peer C die Transaktion aufgrund seiner Relay-Einstellungen möglicherweise gar nicht angekündigt bekommt.

Diese zeitliche Streuung reduziert gleichzeitig die Möglichkeit, aus dem Zeitpunkt einer Ankündigung unmittelbar darauf zu schließen, von welcher Node eine Transaktion ursprünglich in das Netzwerk gelangt ist.

Welche Auswirkungen dieses Verhalten auf die Beobachtbarkeit von Transaktionen hat, betrachten wir unter Relay und Privatsphäre genauer.

Warum sendet eine Node nicht sofort die gesamte Transaktion?

Eine Node kündigt eine Transaktion zunächst mit INV an, anstatt sofort die vollständigen Transaktionsdaten zu übertragen.

Dadurch kann der empfangende Peer selbst entscheiden, ob er die Transaktion überhaupt benötigt. Kennt er sie bereits, muss sie nicht erneut übertragen werden.

Erst wenn der Peer die Transaktion mit GETDATA anfordert, werden die vollständigen Daten mit TX übertragen.

Das vermeidet unnötige Datenübertragungen und reduziert den Netzwerkverkehr. Derselbe Grundgedanke steckt auch hinter der Ausbreitung im P2P-Netzwerk.

Relay und Privatsphäre

Beim Transaction Relay können Peers beobachten, von welcher Node und zu welchem Zeitpunkt ihnen eine Transaktion angekündigt wurde.

Würde eine Node eine neu erhaltene Transaktion sofort gleichzeitig an alle ihre Peers weiterleiten, könnte ein Beobachter aus diesen Zeitpunkten leichter Rückschlüsse darauf ziehen, von welcher Node die Transaktion ursprünglich in das Netzwerk gelangt sein könnte.

Bitcoin Core kündigt Transaktionen deshalb nicht einfach unmittelbar und gleichzeitig gegenüber allen geeigneten Peers an. Die Weitergabe wird für einzelne Peer-Verbindungen zeitlich versetzt.

Dadurch wird die zeitliche Reihenfolge der beobachteten INV-Nachrichten weniger aussagekräftig und die Bestimmung des ursprünglichen Ausgangspunkts einer Transaktion erschwert.

Vollständige Anonymität entsteht dadurch jedoch nicht.

Ein Beobachter mit vielen Verbindungen zu verschiedenen Nodes kann weiterhin versuchen, die Ausbreitung einer Transaktion zu analysieren und daraus Rückschlüsse auf ihren möglichen Ursprung zu ziehen.

Relay reduziert solche Informationen, verhindert eine Netzwerkanalyse aber nicht vollständig.