Über die Blockchain-Performance denken zehn von neun Menschen zuerst an TPS. Der Rest schaut vielleicht auf die Latenz. Bei dem Projekt Dusk ist es aber so: Wenn du das Whitepaper herausholst und es sorgfältig durchgehst, merkst du, dass etwas mehr Aufmerksamkeit verdient als die Transaktionsgeschwindigkeit – nämlich wie die Knoten „miteinander sprechen“.
Das mit dem großen Kuchen (BTC) ist ja noch okay – BTC ist nicht so stark gefallen!
Ich sage das nicht, weil TPS unwichtig ist, sondern weil „schnell rechnen“ und „schnell übertragen“ zwei völlig verschiedene Dinge sind. Selbst wenn deine Execution-Layer noch so stark ist und das Konsensdesign noch so ausgeklügelt – wenn Nachrichten im Knotennetz stecken bleiben, wartet der komplette Drei-Phasen-Ablauf. Vorschläge kommen nicht beim Validierer an, Validierungsergebnisse erreichen nicht das Ratification-Komitee – und schon läuft alles nur im Leerlauf. Wenn Blöcke ein paar Sekunden zu spät eintreffen, kostet das leicht die Nutzererfahrung; im schlimmsten Fall sehen unterschiedliche Knoten unterschiedliche Kandidatenblöcke, und die Rate für stale blocks schießt rasant in die Höhe.
Dusk ist diesen Weg gegangen: Kadcast. Das ist kein Gossip-Modell, bei dem man „einfach an alle weiterleitet“, sondern ein strukturiertes Overlay-Netz, das auf einer Kademlia-DHT basiert. Die XOR-Distanz zwischen den Node-IDs bestimmt die Weiterleitung; Nachrichten entfalten sich wie ein Baum von Stufe zu Stufe. Klingt nach Wissenschaft, oder? Aber die Kernlogik lässt sich auf einen Satz herunterbrechen: Jede Nachricht nimmt nur den vorgesehenen Weg – keinen Umweg.
Das Whitepaper zitiert Forschungen, nach denen Kadcast im Vergleich zu Gossip 25% bis 50% Bandbreite spart. Beispiel: Wenn früher 100 Einheiten Bandbreite verbraucht wurden, sind es jetzt ungefähr 50 bis 75 – aber diese Zahl lässt sich nicht einfach als „Halbierung der Knotenkosten“ übersetzen. An der Hardware ändert sich nichts, am Proof-Computing ändert sich nichts, am Storage-Overhead ändert sich nichts; verändert wird nur die Übertragungskosten auf der Netzwerkebene. Aber mal zurück zur Praxis: Was bedeutet das für Leute, die Nodes betreiben? Bedeutet es doch, dass man bei gleichem Bandbreitelimit mehr Nodes anbinden kann – oder dass man bei gleicher Knotengröße nicht so leicht durch Bandbreitekosten am Halsband gelandet wird.
Ein Detail verdeutlicht das besonders gut. In der Node-Dokumentation ist 9000/udp als für Kadcast notwendiger Port markiert. Der Provisioner muss am Konsens teilnehmen können – daher muss dieser Kanal erreichbar sein. 8080/tcp ist hingegen optional: Es wird nur benötigt, wenn ein Abfrage-Interface verwendet werden soll. Kurz gesagt: Kadcast ist kein Deko-Element in der Architekturzeichnung – es legt direkt fest, ob eine Node überhaupt erst die Schwelle erreichen kann, um am Konsens teilzunehmen.
Wer mit dem P2P-Broadcast bei BTC vertraut ist, weiß: Wie Nachrichten durch das Knotennetz laufen, ist nie nur eine Kleinigkeit. @Dusk $DUSK #dusk
Das mit dem großen Kuchen (BTC) ist ja noch okay – BTC ist nicht so stark gefallen!
Ich sage das nicht, weil TPS unwichtig ist, sondern weil „schnell rechnen“ und „schnell übertragen“ zwei völlig verschiedene Dinge sind. Selbst wenn deine Execution-Layer noch so stark ist und das Konsensdesign noch so ausgeklügelt – wenn Nachrichten im Knotennetz stecken bleiben, wartet der komplette Drei-Phasen-Ablauf. Vorschläge kommen nicht beim Validierer an, Validierungsergebnisse erreichen nicht das Ratification-Komitee – und schon läuft alles nur im Leerlauf. Wenn Blöcke ein paar Sekunden zu spät eintreffen, kostet das leicht die Nutzererfahrung; im schlimmsten Fall sehen unterschiedliche Knoten unterschiedliche Kandidatenblöcke, und die Rate für stale blocks schießt rasant in die Höhe.
Dusk ist diesen Weg gegangen: Kadcast. Das ist kein Gossip-Modell, bei dem man „einfach an alle weiterleitet“, sondern ein strukturiertes Overlay-Netz, das auf einer Kademlia-DHT basiert. Die XOR-Distanz zwischen den Node-IDs bestimmt die Weiterleitung; Nachrichten entfalten sich wie ein Baum von Stufe zu Stufe. Klingt nach Wissenschaft, oder? Aber die Kernlogik lässt sich auf einen Satz herunterbrechen: Jede Nachricht nimmt nur den vorgesehenen Weg – keinen Umweg.
Das Whitepaper zitiert Forschungen, nach denen Kadcast im Vergleich zu Gossip 25% bis 50% Bandbreite spart. Beispiel: Wenn früher 100 Einheiten Bandbreite verbraucht wurden, sind es jetzt ungefähr 50 bis 75 – aber diese Zahl lässt sich nicht einfach als „Halbierung der Knotenkosten“ übersetzen. An der Hardware ändert sich nichts, am Proof-Computing ändert sich nichts, am Storage-Overhead ändert sich nichts; verändert wird nur die Übertragungskosten auf der Netzwerkebene. Aber mal zurück zur Praxis: Was bedeutet das für Leute, die Nodes betreiben? Bedeutet es doch, dass man bei gleichem Bandbreitelimit mehr Nodes anbinden kann – oder dass man bei gleicher Knotengröße nicht so leicht durch Bandbreitekosten am Halsband gelandet wird.
Ein Detail verdeutlicht das besonders gut. In der Node-Dokumentation ist 9000/udp als für Kadcast notwendiger Port markiert. Der Provisioner muss am Konsens teilnehmen können – daher muss dieser Kanal erreichbar sein. 8080/tcp ist hingegen optional: Es wird nur benötigt, wenn ein Abfrage-Interface verwendet werden soll. Kurz gesagt: Kadcast ist kein Deko-Element in der Architekturzeichnung – es legt direkt fest, ob eine Node überhaupt erst die Schwelle erreichen kann, um am Konsens teilzunehmen.
Wer mit dem P2P-Broadcast bei BTC vertraut ist, weiß: Wie Nachrichten durch das Knotennetz laufen, ist nie nur eine Kleinigkeit. @Dusk $DUSK #dusk