Jungs: Die meisten Blockchains gehen davon aus, dass der Konsens weiterläuft. $DUSK actually hat jedoch einen Plan für den Fall, dass das nicht passiert.
In seinem SA-Konsens trägt jeder Block einen Seed, der aus der Signatur des vorherigen Blockgenerators abgeleitet wird. Das verändert die Zufälligkeit ständig und macht es dadurch schwierig, künftige Blockgeneratoren und Komitees im Voraus vorherzusagen.
Der spannendere Teil ist jedoch, was passiert, wenn es schiefgeht.
Wenn genug Provisioner offline gehen und 16 aufeinanderfolgende Iterationen fehlschlagen, wechselt Dusk in den Notfallmodus. Anstatt einfach aufzugeben, probiert das Netzwerk weiter, bis ein Kandidatenblock Quorum erreicht.
Mehrere Iterationen können sogar gleichzeitig offen bleiben, was die Chance erhöht, dass eine erfolgreich ist. Der Trade-off? Mehr parallele Versuche können auch Forks erzeugen, die Dusk auflöst, indem es den Kandidaten aus der niedrigsten Iteration auswählt.
Und wenn das Netzwerk die letzte Iteration erreicht, ohne voranzukommen, können Provisioner, die eine Mehrheit des Stakes halten, einen Notfallblock anfordern. Dieser Block enthält keine Transaktionen, gibt dem Netzwerk aber einen neuen Seed, damit es in die nächste Runde übergehen kann.
Ich finde das tatsächlich spannender als die übliche Behauptung „schneller Konsens“. Es zeigt, was das Protokoll tut, wenn sich das Netzwerk schlecht verhält – nicht nur dann, wenn alles perfekt funktioniert.
Aber ich frage mich ständig: Macht ein ausgearbeiteter Notfallpfad Dusk widerstandsfähiger, oder führt die zusätzliche Komplexität zu neuen Randfällen?
Würdet ihr lieber eine Blockchain mit einem detaillierten Mechanismus zur Fehlerbehebung nutzen – oder eine mit einem einfacheren Konsensdesign?
#dusk $DUSK @Dusk
In seinem SA-Konsens trägt jeder Block einen Seed, der aus der Signatur des vorherigen Blockgenerators abgeleitet wird. Das verändert die Zufälligkeit ständig und macht es dadurch schwierig, künftige Blockgeneratoren und Komitees im Voraus vorherzusagen.
Der spannendere Teil ist jedoch, was passiert, wenn es schiefgeht.
Wenn genug Provisioner offline gehen und 16 aufeinanderfolgende Iterationen fehlschlagen, wechselt Dusk in den Notfallmodus. Anstatt einfach aufzugeben, probiert das Netzwerk weiter, bis ein Kandidatenblock Quorum erreicht.
Mehrere Iterationen können sogar gleichzeitig offen bleiben, was die Chance erhöht, dass eine erfolgreich ist. Der Trade-off? Mehr parallele Versuche können auch Forks erzeugen, die Dusk auflöst, indem es den Kandidaten aus der niedrigsten Iteration auswählt.
Und wenn das Netzwerk die letzte Iteration erreicht, ohne voranzukommen, können Provisioner, die eine Mehrheit des Stakes halten, einen Notfallblock anfordern. Dieser Block enthält keine Transaktionen, gibt dem Netzwerk aber einen neuen Seed, damit es in die nächste Runde übergehen kann.
Ich finde das tatsächlich spannender als die übliche Behauptung „schneller Konsens“. Es zeigt, was das Protokoll tut, wenn sich das Netzwerk schlecht verhält – nicht nur dann, wenn alles perfekt funktioniert.
Aber ich frage mich ständig: Macht ein ausgearbeiteter Notfallpfad Dusk widerstandsfähiger, oder führt die zusätzliche Komplexität zu neuen Randfällen?
Würdet ihr lieber eine Blockchain mit einem detaillierten Mechanismus zur Fehlerbehebung nutzen – oder eine mit einem einfacheren Konsensdesign?
#dusk $DUSK @Dusk