Ganz ehrlich: Als ich am Anfang die Dusk-Knoten laufen ließ, habe ich mich nicht sonderlich darum gekümmert, die Netzwerkschicht wirklich ernst zu nehmen. Solange Konsens durchläuft, Blöcke rausgehen und die Belohnungen ankommen—wer hat da schon Zeit, ständig die UDP-Pakete auf den Ports zu verfolgen, hin und her? Bis mir irgendwann aus dem Rechenzentrum jemand Rückmeldung gab: Der ausgehende Netzwerkverkehr der Knoten sei deutlich höher als erwartet. Nach einer Runde Analyse stellte sich heraus, dass entweder RPC abgefischt wurde oder dieses Gossip-Broadcasting nach dem Hochskalieren anfängt, „Quatsch zu verbreiten“. Eine Nachricht wird in einem Gruppen-Chat einmal gerufen, dann von jedem noch einmal weitergeleitet—der Effekt von N², das wissen alle, die P2P kennen.
Die große Hoffnung ist ein bisschen eingebrochen—aber BTC baut weiter auf!
Als ich in den Dusk-Dokumenten dann Kadcast herausgegriffen gesehen habe, habe ich mir das tatsächlich mit einer gewissen Skepsis angeschaut. Die Formulierung „strukturierte Abdeckung“: Im Grunde zeichnet man der Nachricht eine Route bzw. Karte vor und schickt sie nicht einfach zufällig drauflos. Der offizielle Wert, dass die Bandbreite um 25% bis 50% sinkt—ich habe in zwei Wochen Laufzeit einen groben Vergleich gemacht, indem ich meine eigenen Knoten als Testbasis nahm. Kadcast-Optimierungs-Schalter ausgeschaltet (im Testnet gibt es diese Option) vs. eingeschaltet: Im Vergleich konnte man den ausgehenden Traffic tatsächlich um fast 40% drücken. Aber das muss man klar sagen: Das sind reine Zahlen zur Netzwerkschicht. Das darf man nicht mit „Knotenkosten um ein Sechstel“ gleichsetzen. Das Geld für Maschine, Speicher und diese Prover-Hardware-Ausgaben bleibt genauso fällig, keinen Cent weniger.
Was mich dann wirklich überzeugt hat, dass man diese Sache herausgreifen sollte, sind die Details bei der Port-Konfiguration. Im Node-Guide sind 9000/UDP als zwingend markiert, 8080/TCP dagegen nur optional—das ist ein so eindeutiges Signal, dass Kadcast in dieser Dusk-Architektur nicht bloß „Nice to have“ ist, sondern das Kommunikations-Lebensnerv. Ein Vorschlag muss raus, Verifikationsstimmen müssen fliegen, im Genehmigungsstadium wird zusammengefasst—und wenn irgendwo ein Schritt wegen Netzwerküberlast stockt, bricht die Konsens-Erfahrung direkt auseinander. Selbst wenn der Block noch so schnell ausgegeben wird: Wenn die Nachricht nicht durchkommt, ist der Nutzen gleich null.
Leute, die die Node-Setups bei ETH schon mal durchlaufen haben, kennen das Gefühl: Bei ein paar Tausend Knoten im Testnet fängt die Synchronisationslatenz an, zu driften. Dusk holt die Effizienz der Verbreitung als eigene Optimierungsschicht hervor—die Richtung stimmt. Aber langfristig kommt es darauf an, ob die Kadcast-„Karte“ auch dann noch eine niedrige Wiederholrate und stabile Latenz halten kann, wenn die Knotenzahl sich verdoppelt oder sogar verfacht. Das hat nichts mit TPS zu tun, auch nichts mit Sicherheits-Schwellenwerten—es ist schlicht die eigene Hausaufgabe der Kommunikationsschicht.
@Dusk $DUSK #dusk
Die große Hoffnung ist ein bisschen eingebrochen—aber BTC baut weiter auf!
Als ich in den Dusk-Dokumenten dann Kadcast herausgegriffen gesehen habe, habe ich mir das tatsächlich mit einer gewissen Skepsis angeschaut. Die Formulierung „strukturierte Abdeckung“: Im Grunde zeichnet man der Nachricht eine Route bzw. Karte vor und schickt sie nicht einfach zufällig drauflos. Der offizielle Wert, dass die Bandbreite um 25% bis 50% sinkt—ich habe in zwei Wochen Laufzeit einen groben Vergleich gemacht, indem ich meine eigenen Knoten als Testbasis nahm. Kadcast-Optimierungs-Schalter ausgeschaltet (im Testnet gibt es diese Option) vs. eingeschaltet: Im Vergleich konnte man den ausgehenden Traffic tatsächlich um fast 40% drücken. Aber das muss man klar sagen: Das sind reine Zahlen zur Netzwerkschicht. Das darf man nicht mit „Knotenkosten um ein Sechstel“ gleichsetzen. Das Geld für Maschine, Speicher und diese Prover-Hardware-Ausgaben bleibt genauso fällig, keinen Cent weniger.
Was mich dann wirklich überzeugt hat, dass man diese Sache herausgreifen sollte, sind die Details bei der Port-Konfiguration. Im Node-Guide sind 9000/UDP als zwingend markiert, 8080/TCP dagegen nur optional—das ist ein so eindeutiges Signal, dass Kadcast in dieser Dusk-Architektur nicht bloß „Nice to have“ ist, sondern das Kommunikations-Lebensnerv. Ein Vorschlag muss raus, Verifikationsstimmen müssen fliegen, im Genehmigungsstadium wird zusammengefasst—und wenn irgendwo ein Schritt wegen Netzwerküberlast stockt, bricht die Konsens-Erfahrung direkt auseinander. Selbst wenn der Block noch so schnell ausgegeben wird: Wenn die Nachricht nicht durchkommt, ist der Nutzen gleich null.
Leute, die die Node-Setups bei ETH schon mal durchlaufen haben, kennen das Gefühl: Bei ein paar Tausend Knoten im Testnet fängt die Synchronisationslatenz an, zu driften. Dusk holt die Effizienz der Verbreitung als eigene Optimierungsschicht hervor—die Richtung stimmt. Aber langfristig kommt es darauf an, ob die Kadcast-„Karte“ auch dann noch eine niedrige Wiederholrate und stabile Latenz halten kann, wenn die Knotenzahl sich verdoppelt oder sogar verfacht. Das hat nichts mit TPS zu tun, auch nichts mit Sicherheits-Schwellenwerten—es ist schlicht die eigene Hausaufgabe der Kommunikationsschicht.
@Dusk $DUSK #dusk