Ich bin der Frage nachgegangen, warum Dusk ganz speziell Wähler belohnt, die Kandidaten aus früheren, bereits gescheiterten Iterationen unterstützen — und die Mechanik hinter dieser Belohnung geht tiefer, als die grundlegende Drei-Schritt-Beschreibung vermuten lässt.
Die drei Schritte an sich sind auf dem Papier simpel: Proposal erzeugt einen Kandidaten, Validation prüft ihn, Ratification bestätigt, dass die Prüfung echt war. Was aber nicht offensichtlich ist, ist, wie Dusk spätere Komitees dazu bringt, sich überhaupt die Mühe zu machen, eine frühere Iteration wiederzubeleben, statt einfach auf einen frischen Kandidaten zu warten.
Rechnen wir die Aufteilung der Belohnung speziell durch. In Dusk-eigenen Engineering-Notizen wird beschrieben, dass das Block Certificate Generators mit 90% der Belohnung des vorherigen Blocks bezahlt, die verbleibenden 10% jedoch auf die Wähler aufgeteilt werden — verteilt in 64 Quoten, jeweils eine pro Committee-Credit. Dadurch erhält ein Wähler mit mehr stakgewichteten Credits anteilig mehr von diesem Anteil.
Und hier ist der Teil, der mich tatsächlich überrascht hat. Diese 10%-Wählerbelohnung wurde nicht immer auf diese Weise ausgezahlt. In Dusk-eigenen Updates wird erklärt, dass sie gezielt hinzugefügt wurde, um Block-Generatoren in zukünftigen Iterationen dazu zu ermutigen, über Kandidaten aus früheren Iterationen abzustimmen — das heißt, das System brauchte einen bewussten finanziellen Anreiz, bevor Komitees zuverlässig damit begannen, einen bereits abgelaufenen Block wiederherzustellen, statt ihn einfach sterben zu lassen.
Also ist eine gescheiterte Iteration bei Dusk kein Zufalls-Dead-End. Sie bleibt wiederherstellbar, weil Dusk eine konkrete Zahlung in das Protokoll eingebaut hat, die Recovery für den Aufwand eines Komitees lohnt — nicht weil Komitees das von Natur aus umsonst tun würden.
Komitees dafür zu bezahlen, gescheiterte Versuche zu retten, oder stillschweigend zuzugeben, dass der erste Versuch normalerweise erst mit einem finanziellen Anstoß richtig zu Ende gebracht wird? Ich bin da noch am Grübeln.
#dusk $DUSK @Dusk
Die drei Schritte an sich sind auf dem Papier simpel: Proposal erzeugt einen Kandidaten, Validation prüft ihn, Ratification bestätigt, dass die Prüfung echt war. Was aber nicht offensichtlich ist, ist, wie Dusk spätere Komitees dazu bringt, sich überhaupt die Mühe zu machen, eine frühere Iteration wiederzubeleben, statt einfach auf einen frischen Kandidaten zu warten.
Rechnen wir die Aufteilung der Belohnung speziell durch. In Dusk-eigenen Engineering-Notizen wird beschrieben, dass das Block Certificate Generators mit 90% der Belohnung des vorherigen Blocks bezahlt, die verbleibenden 10% jedoch auf die Wähler aufgeteilt werden — verteilt in 64 Quoten, jeweils eine pro Committee-Credit. Dadurch erhält ein Wähler mit mehr stakgewichteten Credits anteilig mehr von diesem Anteil.
Und hier ist der Teil, der mich tatsächlich überrascht hat. Diese 10%-Wählerbelohnung wurde nicht immer auf diese Weise ausgezahlt. In Dusk-eigenen Updates wird erklärt, dass sie gezielt hinzugefügt wurde, um Block-Generatoren in zukünftigen Iterationen dazu zu ermutigen, über Kandidaten aus früheren Iterationen abzustimmen — das heißt, das System brauchte einen bewussten finanziellen Anreiz, bevor Komitees zuverlässig damit begannen, einen bereits abgelaufenen Block wiederherzustellen, statt ihn einfach sterben zu lassen.
Also ist eine gescheiterte Iteration bei Dusk kein Zufalls-Dead-End. Sie bleibt wiederherstellbar, weil Dusk eine konkrete Zahlung in das Protokoll eingebaut hat, die Recovery für den Aufwand eines Komitees lohnt — nicht weil Komitees das von Natur aus umsonst tun würden.
Komitees dafür zu bezahlen, gescheiterte Versuche zu retten, oder stillschweigend zuzugeben, dass der erste Versuch normalerweise erst mit einem finanziellen Anstoß richtig zu Ende gebracht wird? Ich bin da noch am Grübeln.
#dusk $DUSK @Dusk
Smart incentive design
Needs a financial nudge
1 Stunde(n) übrig