@Dusk_Foundation
Zunächst ging ich davon aus, dass die Fallback-Regel von Dusk vor allem dazu dient, durch Netzwerkverzögerungen verursachte Forks aufzuräumen. Doch je genauer ich hinsah, desto seltsamer wirkte die Regel. Wenn zwei Blöcke in derselben Runde zum Konsens gelangen, kann Dusk einen Block aus einer höheren Iteration durch einen aus einer niedrigeren Iteration ersetzen – sogar nachdem der Block aus der höheren Iteration bereits lokal akzeptiert wurde. Ein akzeptierter Block ist also nicht zwangsläufig ein endgültig festgelegter Block. Das Spannende ist, dass das Protokoll nicht jedes erfolgreiche Konsensergebnis als gleich stark behandelt. Die Iterationsnummer behält Bedeutung, nachdem die Abstimmung abgeschlossen ist. Ein Block aus Iteration null kann nicht durch einen anderen Block aus einer niedrigeren Iteration ersetzt werden, während spätere Iterationen weiterhin dem Fallback ausgesetzt bleiben. Das bedeutet, dass die Historie, wie der Konsens zustande kam, ein Teil der Stabilität des Blocks ist. Das ist eine kleine Einzelheit, aber sie verändert, wie ich über „Übereinstimmung“ in diesem Design nachdenke. Vielleicht ist die Frage also nicht, ob ein Konsens zustande gekommen ist. Sondern: Wie viel Geschichte noch in der Lage ist, zu verändern, was diese Übereinstimmung bedeutet?
@Dusk_Foundation #dusk $DUSK