Ich bin gestern Abend noch einmal durch das Dusk-Whitepaper gegangen und habe dabei mich auf die Abschnitte zum Notfallmodus, Fallback und zur rollenbasierten Finalität konzentriert. Die Details waren differenzierter, als ich zuerst erwartet hatte.

Der Notfallmodus wird nach 16 fehlgeschlagenen Iterationen aktiviert. Dann werden Schritt-Timeouts deaktiviert, und offene Iterationen laufen weiter, bis ein Kandidatenblock in beiden Bereichen Validierung und Ratifizierung Quorum erreicht. Mehrere Iterationen können gleichzeitig laufen, was die Wahrscheinlichkeit erhöht, einen Block zu erzeugen, aber auch die Möglichkeit von Forks erhöht. Wenn mehrere Kandidaten Konsens erreichen, wird die niedrigste Iteration ausgewählt. In der letzten Iteration können Provisioner einen Notfallblock anfordern, aber dafür müssen Provisi­oner über eine Mehrheit des gesamten Netzwerk-Stakes verfügen.

Auch die Fallback-Regeln haben meine Aufmerksamkeit geweckt: Ein Block aus Iteration J > 0 kann potenziell durch einen Block aus einer niedrigeren Iteration ersetzt werden, der später Konsens erreicht, während Iteration 0 auf diese Weise nicht ersetzt werden kann.

Dann bringt die rollenbasierte Finalität noch eine weitere Ebene hinzu. Wenn n vorherige Iterationen bei der Attestation fehlgeschlagen sind, wird ein Block akzeptiert und muss 2×n aufeinanderfolgende attestierte oder bestätigte Blöcke erhalten, um bestätigt zu werden. Das Beispiel im Paper verwendet Iteration 5, n=2, das bedeutet, es werden 4 weitere Blöcke benötigt.

Ich frage mich immer noch: Schafft dieses Design irgendein bedeutendes Zentralisierungsrisiko im Zusammenhang mit dem stake-gewichteten Notfall-Recovery?

@Dusk #dusk $DUSK