#dusk $DUSK Heute schaue ich mir die Network-Layer-Dokumentation von @Dusk an. Ursprünglich dachte ich, dass die P2P-Netzwerke von Blockchains alle ziemlich ähnlich sind – Broadcast von Transaktionen, Synchronisierung von Blöcken, nicht viel zum Vertiefen. Erst als ich den Begriff „Kadcast“ sah, merkte ich, dass Dusk nicht den alten Weg mit dem Gossip-Protokoll gegangen ist.
Das Gossip-Protokoll funktioniert wie ein Spiel „Telefonieren“: Jeder Knoten wählt zufällig einige Nachbarn aus, um die Nachricht weiterzuleiten; die Nachbarn geben sie wiederum an ihre eigenen Nachbarn weiter – am Ende weiß das ganze Netz Bescheid. Der Vorteil ist eine gute Fehlertoleranz, aber der Preis ist ein erheblicher Bandbreitenverbrauch – dieselbe Nachricht kann bei demselben Knoten mehrfach ankommen.
Kadcast ersetzt das zufällige Broadcasting durch ein strukturiertes Overlay-Netzwerk. Knoten wählen nicht zufällig Nachbarn, sondern leiten Nachrichten gerichtet nach einer vorbereiteten Topologiestruktur weiter. Die offiziellen Dokumente sagen, dass dies die Bandbreite gegenüber dem traditionellen Gossip-Protokoll um 25% bis 50% einsparen kann.
Ich verstehe, dass diese Gestaltung mit bestimmten Einschränkungen zu tun hat: In Finanzszenarien dürfen Transaktionsbestätigungen nicht auf der Zufälligkeit beruhen, dass „wenn man es nur ein paar Mal öfter streut, schon irgendwer es bekommt“. Strukturiertes Routing bedeutet, dass sich die Ausbreitungswege von Nachrichten besser vorhersagen lassen und auch die Latenz besser kontrollierbar ist. Für Finanzmärkte, bei denen eine deterministische Abwicklung erforderlich ist, ist es genauso wichtig zu wissen, „wie lange es ungefähr dauert, bis die Nachricht ankommt“, wie zu wissen, „dass sie ankommt“.
Doch die andere Seite dieser Optimierung ist: Strukturierten Netzwerken gegenüber sind Knoten-Neuzugänge und -Abgänge empfindlicher. Wenn viele Knoten gleichzeitig nicht online sind, könnte die Effizienz des Neuaufbaus der Routing-Tabellen die gesamte Kommunikation ausbremsen. In den derzeit öffentlich verfügbaren Dokumenten habe ich jedoch keine Latenzdaten bei großen Schwankungen der Knotenanzahl gefunden.
Beim Lesen von #dusk s Network Layer schaue ich mir nicht nur TPS und Blockzeit an – ich möchte sehen, welche Bandbreite und welche Latenzverteilungen Kadcast im Live-Betrieb auf dem Mainnet unter der realen Knotenverteilung tatsächlich einspart. Wenn die DUSK-Basis zuverlässig läuft, dann haben die darüberliegenden Finanzanwendungen auch ein solides Fundament. #dusk @Dusk