Ich habe mehrere Knoten im Testnetz „flakken“ lassen (@Dusk ) und nach dem Mitschnitt mit Wireshark war mein größter Eindruck: Viele Betreiber im Mainnet nutzen immer noch Kennzahlen aus der alten Zeit wie „CPU-Rotlinie + Speicherpegel“, aber sie merken nichts davon, dass zwischen den Knoten Signale sich stauen, doppelte Nachrichten anfallen und die Routing-Tabelle stark schwankt. Die frühe Bitcoin-Broadcast-Flut als Gegenbeispiel ist schon da: Sobald eine Transaktion einen Knoten erreicht, wird sie wahllos an alle Nachbarn weitergereicht; 8 bis 16 gleichzeitige Peers leiten dann parallel weiter, und die Bandbreite der Netzwerkschicht wird in multiplikativem Ausmaß verstärkt. In den Statistiken der frühen Bitcoin-Testnetze lagen die redundanten Duplikate beim Broadcast einer einzelnen Transaktion oft bei mehr als dem Dreifachen der Anzahl der Verbindungen. Sobald die Parallelität hochgeht, füllt sich die Netzwerkkarte mit Interrupts, noch bevor die Block-Synchronisierung nachkommt.

Kadcast geht nicht diesen alten Weg. Es drückt die XOR-Distanzlogik von Kademlia direkt in die Transport-/Propagationsschicht: Die Knoten berechnen zuerst die Distanz zwischen Ziel und eigener ID, stecken Nachbarn anhand der Präfixlänge in unterschiedliche k-buckets und multicastet dann synchron über einen baumartigen Routingpfad schrittweise. In meinen Messungen beim Stresstest zeigte sich: Der Peak der momentanen Bandbreite ist um eine Größenordnung niedriger als bei Flooding; außerdem können externe Sonden die Quell-IP aufgrund der Multi-Hop-Weiterleitung deutlich schlechter zurückrechnen. Design-seitig ist das auch begründet: In simulationsnahen Darstellungen auf Paper-Ebene reduziert Kadcast die Broadcasting-Redundanz von Gossip’ linearer Skalierung auf eine logarithmische. Eine Größenordnung weniger.

Aber meine Zweifel liegen genau hier. Wenn die Effizienz vollständig auf die Gesundheit der Routing-Tabelle setzt, bedeutet das, die Fehlertoleranz eines verteilten Systems an die Topologie-Annahmen auszulagern. Sobald ein Unterseekabel durchschnitten wird oder ein Angreifer mit kostengünstigen Sybil-Identitäten bestimmte k-buckets verunreinigt, werden Knoten sehr häufig Routing-Reparaturen und Umschaltungen auf Ausweichpfade auslösen. Die Adressierungs-Latenz wächst dann nicht linear, sondern wird verstärkt durch Jitter: Wenn in der Routing-Tabelle ein bucket mit hohem Präfix fehlt, kann die Abfrage-Sprungzahl von einer logarithmischen Größenordnung direkt ins Ausprobieren/Enumerieren kippen. In meinem Stresstest sah ich dabei eine noch unanschaulichere Szene: Bei identischen 2000 Transaktionen pro Injektion waren die Anzahl der Netzwerkkarten-Interrupts bei Flooding-Knoten viermal so hoch wie bei Kadcast-Knoten, aber sobald die Paketverlustrate über 3% liegt, liegt die Block-Synchronisierungszeit von Kadcast am Ende sogar vorne. Die Kosten reichen aus, um den anfangs eingesparten Bandbreitenvorteil wieder aufzufressen.

Das öffentliche Internet ist kein Labor: TCP-Retransmits, NAT-Traversal und QoS der Provider verstärken die Anfälligkeit der logischen Topologie. Bei der Bewertung solcher Underlay-/Basisschichten ist das Schlimmste nicht, dass die CPU hochläuft, sondern dass die Routing-Tabelle still und leise schlechter wird: Nach außen wirkt der Durchsatz normal, in Wahrheit haben Signale durch wiederholtes Senden und Bucket-Reparaturen bereits die Control-Plane durchstoßen.#dusk $DUSK $BTC