Ich bin letzte Nacht die Dusk-Dokumentation noch einmal durchgegangen, insbesondere die Abschnitte zum DS-Algorithmus und dazu, wie Provisioner für den Konsens ausgewählt werden.

Ich habe damit begonnen, die Regeln zur Eignung der Einsätze (Stake) abzubilden. Der Einsatz eines Provisioners S gilt nur dann als geeignet, wenn der Betrag mindestens dem Minimum entspricht (festgelegt auf 1000 DUSK) und sein Alter/seine Länge zwischen 0 und M liegt. Der DS-Prozess ordnet anschließend alle geeigneten Einsätze nach einem Score, der die Größe des Einsatzes mit einer deterministischen Funktion aus dem Hash des vorherigen Blocks und dem öffentlichen Schlüssel des Provisioners mischt. Der Provisioner mit der höchsten Punktzahl ist derjenige, der den nächsten Block vorschlagen kann.

Beim Weiterlesen wurde der Ablauf klarer: Der ausgewählte Provisioner sendet einen Kandidatenblock, ein Komitee aus weiteren Provisionern führt eine Validierung durch, und wenn eine einfache Mehrheit (½ + 1) der ValidBk-Nachrichten erscheint, wird der Block zur Ratifizierung weitergeleitet. Die Ratifizierung selbst benötigt einen stärkeren Schwellenwert ⅔ + 1, bevor der Block als final gilt und die neue Menge an Provisionern festgeschrieben wird. Bestätigungs- (Attestation-) und Abstimmungskomitees werden auf die gleiche deterministische Weise gebildet, nur mit unterschiedlichen Seeds.

Was für mich noch nicht vollständig geklärt ist, ist, wie empfindlich die gesamte Kette auf den exakten Wert von M und auf das 1000-DUSK-Minimum reagiert. Wenn sich diese Parameter ändern, ändert sich dann die effektive Dezentralisierung des Provisioner-Sets in einer Weise, die von außen schwer zu erkennen ist? Und sobald ein Block attestiert wurde: Wie viel praktischer Handlungsspielraum besteht, wenn eine spätere Prüfung zeigt, dass die DS-Rangfolge ausgenutzt (gegamet) wurde?

Mich interessiert, wie andere, die in die gleichen Seiten eingedrungen sind, die Sicherheitsreserven rund um diese Mehrheits-Schwellenwerte lesen.
#dusk $DUSK @Dusk