Ich bin letzte Nacht noch einmal durch die Dusk-Dokumentation gegangen, und das Konsensdesign wurde viel klarer, als ich den Zahlen gefolgt bin – statt nur den Begriffen.

Ein Provisioner benötigt mindestens 1.000 DUSK. Die aktuelle Epoche ist 2.160 Blöcke, und die Eignung folgt der Reifeformel M = 2 × Epoche − (Höhe mod Epoche). Das bedeutet: Staking ist nicht sofort berechtigt; es wird am Anfang einer neuen Epoche aktiv.

Der SA-Prozess durchläuft anschließend Vorschlag, Validierung und Ratifizierung. Für „Valid“ benötigt die Validierung eine 2/3-Supermehrheit, während „Invalid“ oder „NoCandidate“ mit 1/2 + 1 das Quorum erreichen können. Eine Runde kann bis zu 50 Iterationen laufen.

Ich fand auch die 64 Committee-Credits interessant. Abstimmungen werden nach Credits gewichtet, während deterministisches Extracting Staking nutzt und das Gewicht eines Provisioners um 1 DUSK pro zugewiesenem Credit reduziert. Danach werden BLS-Signaturen aggregiert.

Die Sicherheitssabwägungen sind es, über die ich noch nachdenke. Nach 16 fehlgeschlagenen Iterationen beginnt der Notfallmodus, aber auch parallele offene Iterationen können das Fork-Risiko erhöhen. Das Protokoll löst das, indem es die niedrigste Iteration auswählt.

Dann gibt es die Transaktionsschicht: Moonlight ist kontobasiert und transparent, während Phoenix UTXOs, ZK-Beweise und Nullifier für die Privatsphäre nutzt.

Meine Fragen: Führt die stakgewichtete Auswahl im Zeitverlauf zu einer spürbaren Konzentration? Und wie robust ist der Notfallmodus bei anhaltenden Netzwerkstörungen?

#dusk $DUSK @Dusk