Zu Hause habe ich gerade nichts Besseres zu tun gehabt und zwei herumliegende Rechner hochgefahren, um ein privates Netz aufzubauen. Ich habe ein paar Testknoten für Dusk laufen lassen und ein wenig damit gespielt. Nebenbei habe ich auch ein paar On-Chain-Asset-Transfers mit Zero-Knowledge-Beweisen simuliert. Die dabei ausgegrabenen Logs aus der darunterliegenden Netzwerkschicht waren ziemlich interessant und geben mir eine etwas andere Sicht auf die aktuell überall herumgereichten Compliance-Erzählungen.
Wenn man sich sonst über Compliance bei RWA austauscht, gilt die ganze Aufmerksamkeit meist den schicken Zero-Knowledge-Algorithmus-Claims – aber wenn man das selbst einmal praktisch ausprobiert und ein paar private Transaktionen abschickt, merkt man: Die Rechenleistung für die Generierung des Beweises ist nur die erste Hürde. Noch quälender ist die Datenverbreitung. Die Datenmenge von Privacy-Transaktionen ist typischerweise viel größer als bei normalen Überweisungen. Wenn es dann eine klassische Gossip-Zufalls-Flut-Broadcast-Übertragung in einer alten Proof-of-Work-/Legacy-Kette wäre, die einfach zwischen dutzenden Knoten wild Pakete hin- und herschickt: Trifft das auf einen Netzwerkspitzenmoment, ist schon das Bestätigungs-Traffic-Volumen komplett bandwidth-fressend. Bei großen Liquiditäts- und Clearing-Aufträgen, die dann genau „unterwegs“ stecken bleiben, wird das richtig dramatisch.
Dusk hat in der darunterliegenden Schicht direkt ein strukturiertes Transportprotokoll namens Kadcast eingeführt. Ich habe mit einem Packet Capture einen Vergleich gemacht: Es lässt die Knoten nicht einfach beliebig miteinander „Hallo“ sagen, sondern sperrt die Broadcast-Pfade strikt nach einer hierarchischen Entfernungsschichtung. Die Daten werden wie beim Schneiden eines Kuchens Schicht für Schicht präzise verteilt. Dadurch sinken redundante verlorene Pakete und wiederholte Handshakes gleich um einen großen Teil. Für großvolumige grenzübergreifende Clearings ist diese geringe Jitter-Rate und extrem deterministische Zustellgeschwindigkeit in der Praxis viel hilfreicher als die reine TPS-Zahl auf dem Papier.
Aber bei meinem eigenen Herumprobieren ist mir auch eine Schwachstelle aufgefallen: Diese präzise baumartige Topologie stellt extrem hohe Anforderungen an den Online-Status der Knoten. Wenn ein Backbone-Knoten plötzlich ausfällt, braucht das Netzwerk Zeit, um neu zu routen. Und wenn das gerade in dem Moment passiert, in dem eine starke Abwärtsbewegung einsetzt und massenhaft Clearing-Anfragen ins Netz gespült werden: Kann es dann lokal zu einem kurzfristigen Nachrichtenstau kommen? Und verursacht die Pflege dieser Topologie am Ende einen Wartungsaufwand, der die Stabilität des Mainnets wieder ausbremst? Diese Fragen sieht man in Testnetzen kaum – man muss abwarten, bis Dusk im Mainnet echte große institutionelle Gelder mit voller Wucht vor die Nase bekommt.
Aber mal ehrlich: Ein Team, das bereit ist, Zeit in genau solche schmutzigen, mühseligen Arbeiten in der Transportschicht zu investieren, ist wirklich nicht so häufig. Wenn das Fundament in der Tiefe nicht richtig steht, wird auch der schönste Finanztempel darüber nur ein Luftschloss.
Wenn du in den Low-Level-Kennzahlen einer institutionellen Chain auswählen müsstest: Welche Sache ist deiner Meinung nach für das Kapital am wichtigsten?#dusk $DUSK @Dusk $ZEC