#dusk $DUSK @Dusk

Ich habe mir Dusks Konsens-Ansatz angesehen, und eine Sache, die ich nicht erwartet hatte, war, wie viel die Netzwerkebene ausmacht, wenn man Blöcke wirklich schnell finalisieren möchte.

Ein Block kann vollkommen gültig sein, aber wenn einige Bereitsteller ihn zu spät erhalten, kann der gesamte Konsensprozess Zeit verlieren.

Genau das hat meine Aufmerksamkeit auf Kadcast gelenkt. Dusk nutzt es für die Nachrichtenübertragung, während Succinct Attestation den Vorschlag, die Validierung und die Ratifizierung übernimmt. So ist die Blockpropagation nicht einfach „an alle senden“ – sie muss schnell genug durchs Netzwerk laufen, damit die Komitees mit denselben Informationen arbeiten können.

Außerdem habe ich bemerkt, dass Dusk von Bereitstellern verlangt, die Knoten synchron zu halten, wobei Kadcast den UDP-Port 9000 verwendet. Selbst der offizielle Troubleshooting-Guide rät Betreibern, die Peer-Konnektivität und die Blockhöhe zu prüfen, wenn die Kettenfortschritte ins Stocken geraten.

Und die minimale direkte Beteiligung beträgt 1.000 DUSK. Das heißt: Konsens-Infrastruktur zu betreiben ist nicht nur eine Frage des Haltens von Token – der Node muss online bleiben und synchronisiert sein.

Für mich ist das der interessante Teil an Dusk: Schnelle Finalität ist nicht nur eine Konsensformel. Die Netzwerkpropagation ist ebenfalls Teil des Geschwindigkeitslimits.

Was passiert, wenn Dusk auf deutlich stärker geografisch verteilte Bereitsteller skaliert?

Könnte die Propagation dann zum echten Engpass werden?

Propagationslimit?