Peer-to-Peer-Gossip

Neugier

1. Wie findet ein neuer Node in einem leeren Netzwerk seinen ersten Peer?
2. Wie erreicht ein neuer Block innerhalb von Sekunden Tausende von Nodes, ohne dass jemand dies koordiniert?
3. Was verhindert, dass ein Angreifer einen Node vom Rest des Netzwerks isoliert?

Erkunden

1. Bitcoin funktioniert als dezentrales Peer-to-Peer-Netzwerk, in dem jeder Full Node einen eigenen, unabhängigen Zustand führt. Um beizutreten, muss ein neuer Node TCP-Verbindungen zu bestehenden Peers aufbauen. Das Mainnet nutzt für diese Verbindungen Port 8333. Die erste Peer-Erkennung stützt sich auf DNS-Seeds, die von langjährigen Community-Mitgliedern betrieben und in der Software hinterlegt sind, sowie auf fest codierte Fallback-Adressen. Sobald eine Verbindung besteht, kann ein Node mit „getaddr“ nach Adressen fragen und erhält diese in „addr“-Nachrichten; so lernt er weitere aktive Teilnehmer kennen und erweitert seine Peer-Menge dynamisch.
2. Bitcoin Core verwaltet eine bestimmte Topologie: 8 ausgehende Full-Relay-Verbindungen für die Verbreitung von Transaktionen und Blöcken sowie 2 Block-relay-only-Verbindungen, um den Bandbreitenverbrauch zu senken. Insgesamt sind bis zu 125 Verbindungen zulässig, eingehende und ausgehende zusammen. Diese Struktur sorgt für Redundanz: Trennt sich ein Peer oder reagiert er nicht mehr, bleibt der Node über andere Peers verbunden. Block-relay-only-Verbindungen übertragen weder Transaktionen noch Adressen, was es Beobachtern erschwert, die Topologie des Netzwerks zu kartieren.
3. Die Datenverbreitung folgt einem Ankündigungsmechanismus. Erhält ein Node eine neue Transaktion, kündigt er sie mit einer „inv“-Nachricht (Inventory) an, die den Hash enthält, nicht aber die Daten selbst; neue Blöcke werden heute meist direkt durch Senden des Headers oder eines Compact Blocks angekündigt. Peers, die diese Ankündigung erhalten, erkennen, dass ihnen das Objekt fehlt, und senden eine „getdata“-Anfrage. Der ursprüngliche Besitzer überträgt daraufhin die vollständigen Daten. Dieses zweistufige Verfahren verhindert, dass das Netzwerk mit redundanten großen Datenmengen überflutet wird, bevor die Peers ihr Interesse bestätigt haben, und sorgt so für eine effiziente Nutzung der Bandbreite im gesamten verteilten System.
4. Compact Blocks (BIP152), 2016 eingeführt, optimieren dies weiter. Da die meisten Transaktionen eines Blocks den Peers über die Mempool-Verbreitung bereits bekannt sind, wäre das Senden des vollständigen Blocks verschwenderisch. Stattdessen sendet ein Node den Block-Header plus kurze Kennungen (je 6 Bytes) für die enthaltenen Transaktionen sowie die Coinbase-Transaktion; der Empfänger rekonstruiert den Block aus seinem eigenen Mempool und fordert nur die wenigen Transaktionen an, die ihm fehlen. Das verringert die Latenz bei der Blockverbreitung erheblich, sodass das Netzwerk auch bei hohem Transaktionsvolumen schneller Konsens erreicht.
5. Eclipse-Angriffe zeigen, wie fragil die Vielfalt der Peers ist. Heilman et al. (2015) zeigten, dass ein Angreifer, der sämtliche Verbindungen eines Nodes übernimmt, ihn vom ehrlichen Netzwerk isolieren und ihm ein falsches Bild der Chain liefern kann. Bitcoin Core übernahm ab Version 0.10.1 ihre Gegenmaßnahmen, darunter Feeler-Verbindungen und ein sorgfältigeres Verdrängen von Einträgen aus der Adresstabelle, und führte später Anchor-Verbindungen ein, die Neustarts überdauern. Ein Node, der ausschließlich über Tor läuft, kann für Eclipse-Angriffe sogar anfälliger werden, nicht weniger anfällig.
6. Überprüfen Sie die Konnektivität Ihres Nodes, indem Sie in einem Terminal, das mit einer lokalen Bitcoin-Core-Instanz verbunden ist, „bitcoin-cli getpeerinfo“ ausführen. Die Ausgabe listet für jeden Peer die Adresse, den „connection_type“ (zum Beispiel outbound-full-relay oder block-relay-only), die Softwareversion und den Synchronisationsstand („synced_headers“, „synced_blocks“) auf. Ein gesunder Node zeigt etwa zehn ausgehende Verbindungen: acht Full-Relay- und zwei Block-relay-only-Verbindungen.

Kernfakten

Übung neun, sechs, drei, eins

Faktcheck

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

• Bitcoin Developer Guide, 'P2P Network' section
• Heilman et al., 'Eclipse Attacks on Bitcoin's Peer-to-Peer Network' (USENIX Security 2015)
• BIP152: Compact Block Relay