Es gibt keine Bitcoin-Zentrale, die man anrufen, keinen Server, den man abschalten könnte. Trotzdem finden zehntausende Bitcoin-Nodes weltweit zuverlässig zueinander und tauschen ununterbrochen Daten aus. Wie soll das ganz ohne Koordinationsstelle funktionieren? Dieser Beitrag zeigt, wie ein einzelner, frisch gestarteter Node den Weg ins Netzwerk findet, und wie das Netzwerk als Ganzes trotzdem effizient bleibt.
Der erste Kontakt: DNS-Seeds
Ein Node, der zum allerersten Mal startet, kennt buchstäblich niemanden. Als ersten Anlaufpunkt nutzt Bitcoin Core eine kleine, fest im Programmcode hinterlegte Liste von acht DNS-Seed-Servern (src/kernel/chainparams.cpp), Domainnamen wie seed.bitcoin.sipa.be, betrieben von einzelnen, langjährig bekannten Bitcoin-Entwicklern (u.a. Pieter Wuille, einem der Bitcoin-Core-Mitentwickler seit 2011, und mehreren weiteren unabhängigen Community-Mitgliedern). Eine einfache Namensauflösung an einen dieser Seeds liefert eine Liste aktuell erreichbarer Bitcoin-Node-Adressen, vergleichbar mit einem Telefonbuch, das nur einen einzigen Zweck hat: dir die ersten paar Nummern zu geben, danach brauchst du es nicht mehr.
Danach übernimmt jeder Node sein eigenes Adressbuch
Sobald ein Node einmal mit ein paar Peers verbunden ist, führt er sein eigenes, lokales Adressbuch, die sogenannte AddrMan-Datenstruktur. Bemerkenswert daran ist die bewusste Aufteilung in zwei getrennte Tabellen: eine "New"-Tabelle für Adressen, von denen der Node nur gehört hat (aber noch nie selbst erfolgreich verbunden war), und eine "Tried"-Tabelle für Adressen, zu denen bereits erfolgreich eine Verbindung bestand. Jede Tabelle ist zusätzlich in viele einzelne "Buckets" unterteilt (1024 für "New", 256 für "Tried", festgelegt in src/addrman_impl.h), in die Adressen nach einem Zufallsschema einsortiert werden.
Warum dieser Aufwand? Er erschwert gezielt sogenannte Eclipse-Angriffe: den Versuch, einen einzelnen Node komplett zu isolieren, indem man ihn ausschließlich mit eigenen, kontrollierten Adressen "umzingelt". Ein Angreifer müsste dafür gleichzeitig große Teile beider getrennter Tabellen dominieren, was den Aufwand erheblich erhöht, verglichen mit einer einzigen, einfachen Adressliste.
Wie eine Nachricht überhaupt als "echte Bitcoin-Nachricht" erkannt wird
Jede Nachricht, die zwischen zwei Bitcoin-Nodes verschickt wird, beginnt mit vier ganz bestimmten Bytes, den sogenannten "Magic Bytes" (im Mainnet-Netzwerk exakt 0xf9 0xbe 0xb4 0xd9, festgelegt in src/kernel/chainparams.cpp). Diese vier Bytes haben nur einen Zweck: sicherzustellen, dass niemals Nachrichten aus dem Test-Netzwerk (Testnet) oder einem anderen experimentellen Netzwerk versehentlich im echten, produktiven Bitcoin-Netzwerk (Mainnet) landen. Fehlen die korrekten Magic Bytes am Anfang, verwirft ein Node die Nachricht sofort, ohne sie überhaupt weiter zu verarbeiten.
Danach folgt ein kurzer Handschlag: Zwei neu verbundene Nodes tauschen zunächst version-Nachrichten aus (unter anderem: welche Protokollversion spreche ich, welche Funktionen unterstütze ich, wie spät ist es bei mir, wie hoch ist mein aktueller Blockstand) und bestätigen sich das gegenseitig mit einer kurzen verack-Nachricht. Erst danach beginnt der eigentliche Austausch von Transaktionen und Blöcken.
Bewusst wenige eigene Verbindungen
Ein einzelner Node hält standardmäßig maximal 125 gleichzeitige Verbindungen (DEFAULT_MAX_PEER_CONNECTIONS in src/net.h), aber davon sind nur maximal acht selbst aktiv aufgebaute, vollwertige ausgehende Verbindungen (MAX_OUTBOUND_FULL_RELAY_CONNECTIONS). Der Rest der Slots ist für eingehende Verbindungen von anderen Nodes sowie für ein paar spezialisierte Verbindungstypen reserviert (etwa reine "Block-only"-Verbindungen ohne Transaktions-Weiterleitung, oder kurze "Feeler"-Verbindungen, die nur testen, ob eine Adresse überhaupt noch erreichbar ist).
Diese bewusst niedrige Zahl an aktiv gewählten Verbindungen ist ein Kompromiss: Mehr Verbindungen würden Angriffe wie das erwähnte Eclipsing erschweren, kosten aber auch mehr Bandbreite und Systemressourcen, bei tausenden Nodes weltweit würde eine unkontrolliert wachsende Vernetzung schnell ineffizient.
Warum niemand einfach "mehr Stimmen" bekommt, indem er mehr Nodes betreibt
Ein verbreitetes Missverständnis lohnt sich an dieser Stelle aufzuklären: Wer zehn eigene Bitcoin-Nodes gleichzeitig betreibt, hat dadurch NICHT zehnmal so viel Einfluss auf das Netzwerk, anders als bei der weiter oben in Teil 2 beschriebenen Rechenleistung beim Mining, die tatsächlich zählt. Ein Node prüft lediglich, ob Transaktionen und Blöcke den bekannten Regeln entsprechen, und leitet sie weiter, er "stimmt" über nichts ab. Das Konzept eines sogenannten Sybil-Angriffs (benannt nach einem bekannten Fallbeispiel multipler Persönlichkeiten, bei dem eine einzelne Instanz sich als viele verschiedene ausgibt) geht bei Bitcoin ins Leere, weil es beim reinen Betrieb eines Nodes gar nichts gibt, worüber man durch pure Anzahl "abstimmen" könnte. Das einzige, was tatsächlich zählt, ist Rechenleistung beim Miningprozess (Teil 2), und die lässt sich nicht durch das Starten zusätzlicher Software-Instanzen vervielfachen, sondern nur durch echte, physische Hardware und echten Stromverbrauch.
Verstecken können sich Nodes trotzdem: Tor-Unterstützung
Wer seinen eigenen Node betreibt, aber nicht möchte, dass sein Internetanbieter oder neugierige Beobachter im Netzwerk sehen können, dass ausgerechnet sein Haushalt gerade eine bestimmte Bitcoin-Transaktion verschickt hat, kann seinen Node über das Anonymisierungsnetzwerk Tor laufen lassen (im Code als eigenständige, gut unterstützte Betriebsart vorgesehen, src/torcontrol.h u.a.). Der eigene Node ist dann nur über eine Tor-"Onion"-Adresse erreichbar, statt über die eigene, sonst leicht zuordenbare IP-Adresse. Interessant dabei: Aus Sicht des restlichen Netzwerks verhält sich ein solcher Node vollkommen normal, er befolgt exakt dieselben Regeln, sendet und empfängt dieselben Nachrichten, nur eben über einen zusätzlichen anonymisierenden Umweg.
Effizienter Blockversand: Compact Blocks
Ein neu gefundener Block enthält oft hunderte oder tausende Transaktionen, die meisten davon kennt ein empfangender Node aber ohnehin schon aus dem eigenen Mempool, weil sie ja vorher genau auf demselben Weg durchs Netzwerk gewandert sind. Diesen Umstand nutzt die sogenannte Compact-Blocks-Technik (offiziell BIP152): Statt den kompletten Block zu übertragen, schickt ein Node im "High-Bandwidth"-Modus an bis zu drei bevorzugte Nachbar-Nodes gleichzeitig nur eine sehr kompakte Version mit kurzen Transaktions-Kennungen. Der Empfänger rekonstruiert daraus den vollständigen Block größtenteils selbst aus dem eigenen Mempool und fragt nur die wenigen, ihm tatsächlich unbekannten Transaktionen gezielt nach. Das spart erhebliche Bandbreite und beschleunigt, wie schnell sich ein neuer Block im gesamten Netzwerk verbreitet, wichtig, weil eine langsame Verbreitung das Risiko kurzzeitig konkurrierender Ketten erhöht.
Eine Reise durch die ersten Sekunden eines neuen Nodes
Um alles noch einmal im Zusammenhang zu sehen, hier der komplette Ablauf, den ein Node in seinen allerersten Sekunden durchläuft: Er startet ohne jede Kenntnis des Netzwerks, fragt die acht fest hinterlegten DNS-Seeds nach ersten Adressen, versucht parallel, zu einer Handvoll davon eine echte Verbindung aufzubauen, tauscht mit jeder erfolgreichen Verbindung den version/verack-Handschlag aus, bei dem beide Seiten auch mitteilen, welche zusätzlichen Dienste sie anbieten (etwa, ob sie die komplette Blockchain-Historie vorhalten oder nur einen aktuellen Ausschnitt). Danach bittet der neue Node seine frischen Nachbarn höflich um weitere, ihnen bekannte Adressen (über eine getaddr-Nachricht), speichert die Antworten in seiner eigenen, noch leeren AddrMan-Tabelle ab, und beginnt, sich mit weiteren dieser neu gelernten Adressen zu verbinden, bis er seine acht ausgehenden Verbindungen erreicht hat. Erst danach beginnt der eigentliche Download der fehlenden Blockchain-Historie bzw. der laufende Empfang neuer Blöcke und Transaktionen. All das passiert typischerweise innerhalb weniger Sekunden nach dem Programmstart, komplett automatisch, ohne dass der Betreiber selbst etwas konfigurieren müsste.
Absichtliche Verzögerung als Datenschutz-Werkzeug
Ein besonders unauffälliges, aber cleveres Detail im Code betrifft die Frage, WANN genau ein Node eine neue Transaktion oder eine neue Adresse an seine Nachbarn weiterleitet. Man könnte annehmen, "sofort" wäre die logische Antwort: schnelle Weiterleitung klingt erst einmal nach gutem Netzwerkverhalten. Genau das würde aber ein Sicherheitsproblem schaffen: Ein Beobachter, der gleichzeitig mit vielen Nodes im Netzwerk verbunden ist, könnte allein anhand dessen, WER eine bestimmte Transaktion als Erster verschickt, ziemlich zuverlässig darauf schließen, von welchem Node (und damit potenziell von welcher realen Internetverbindung) sie ursprünglich stammt.
Bitcoin Core begegnet dem mit bewusst eingebauter, zufälliger Verzögerung: Sowohl neue Adress-Informationen (im Schnitt alle 30 Sekunden pro Nachbar-Verbindung, aber mit zufällig schwankendem exaktem Zeitpunkt, gesteuert über eine sogenannte Exponentialverteilung) als auch neue Transaktions-Ankündigungen werden nicht sofort, sondern nach einer kurzen, zufällig gewürfelten Wartezeit weitergereicht, für eingehende Verbindungen sogar mit einer eigenen, zusätzlichen zufälligen Verzögerung pro einzelner Verbindung. Der Effekt: Ein Angreifer, der versucht, den Ursprung einer Transaktion durch reine Zeitmessung zu rekonstruieren, sieht durch dieses künstliche "Rauschen" ein deutlich verschwommeneres Bild, als es ohne diese Verzögerung der Fall wäre. Ein schönes Beispiel dafür, dass Privatsphäre bei Bitcoin nicht nur eine Frage der Kryptografie ist, sondern manchmal ganz pragmatisch mit ein paar Zeilen Timing-Logik umgesetzt wird.
Was das für die Ausfallsicherheit von Bitcoin insgesamt bedeutet
Die praktische Konsequenz all dieser einzelnen Entscheidungen ist erstaunlich robust: Weil es keinen zentralen Server gibt, gibt es auch keinen einzelnen Angriffspunkt, dessen Abschalten das Netzwerk lahmlegen würde. Selbst wenn sämtliche acht DNS-Seeds gleichzeitig ausfallen würden, könnten bereits laufende Nodes über ihre eigenen, längst gefüllten AddrMan-Tabellen und über direkt von Nutzern eingegebene, bereits bekannte Node-Adressen weiterhin problemlos miteinander kommunizieren, die Seeds sind ausschließlich für den allerersten Einstieg wichtig, nicht für den laufenden Betrieb. Diese Redundanz auf allen Ebenen (viele unabhängige Seeds, viele unabhängige Verbindungen pro Node, keine zentrale Koordinationsstelle) ist der eigentliche Grund, warum Bitcoin seit seinem Start durchgehend, ohne eine einzige nennenswerte netzwerkweite Downtime, erreichbar geblieben ist.
Fazit: Ordnung ohne Zentrale
Von der ersten DNS-Abfrage über das eigene, angriffsresistente Adressbuch bis zum cleveren Compact-Block-Trick zeigt die Netzwerkschicht exemplarisch, wie Bitcoin ohne jede zentrale Koordinationsstelle trotzdem zuverlässig und effizient funktioniert: durch eine Kombination aus wenigen, festen Startpunkten und lauter kleinen, lokalen Entscheidungen, die jeder Node für sich selbst trifft.
Weiter geht's mit Teil 6: Deine Wallet von innen, wie sie Guthaben auswählt und Zahlungen zusammenstellt.
