#dusk $DUSK @Dusk Ich habe diese Woche den Abschnitt zu Konsens-Anreizen durchgearbeitet, weil ich verstehen wollte, ob ein größerer Staker den Zeitpunkt der Blockgenerierung ausspielen kann.
Unerwartete Erkenntnis: Im Whitepaper wird dieses exakte Problem selbst benannt. „Future-generator incentive problem“ – höhere Iterations-Generatoren können profitieren, wenn frühere Iterationen scheitern, weil sie dann die Blockprämie gewinnen. Es ist eine benannte Schwachstelle, nicht versteckt.
Das Upgrade des Aegis-Protokolls im Mainnet (3. März 2026) konzentrierte sich auf die Netzresilienz. Ein Teil davon, warum Resilienz hier wichtig ist: Dieser exakte Anreiz kann dazu führen, dass Generatoren früherer Iterationen unterperformen.
Drei Mechanismen beheben das: Wählerbelohnungen (Provisioner verdienen durch Abstimmen, nicht nur durch Generieren); zusätzliche Guthaben belohnen (der Generator verliert die zusätzlichen 10 %, wenn er Stimmen ausschließt – Sabotage kostet sie also auch); Ausschluss von Generatoren der nächsten Iteration aus dem aktuellen Voting-Schritt.
Die meisten PoS-Systeme haben dieses Problem nicht: Keine sequentielle Iterationsstruktur bedeutet, dass kein Nachfolger darauf wartet, von dem Scheitern eines Vorgängers zu profitieren. Das Design von Dusk schafft diese Schwachstelle und behebt sie dann.
Ein Protokoll, das seinen eigenen spieltheoretischen Fehler explizit benennt, tut etwas Ungewöhnliches. Ob die drei Patches unter echter Netzbelastung mit konzentriertem Stake Bestand haben, ist die ehrliche offene Frage. @Dusk
$DUSK #dusk
Unerwartete Erkenntnis: Im Whitepaper wird dieses exakte Problem selbst benannt. „Future-generator incentive problem“ – höhere Iterations-Generatoren können profitieren, wenn frühere Iterationen scheitern, weil sie dann die Blockprämie gewinnen. Es ist eine benannte Schwachstelle, nicht versteckt.
Das Upgrade des Aegis-Protokolls im Mainnet (3. März 2026) konzentrierte sich auf die Netzresilienz. Ein Teil davon, warum Resilienz hier wichtig ist: Dieser exakte Anreiz kann dazu führen, dass Generatoren früherer Iterationen unterperformen.
Drei Mechanismen beheben das: Wählerbelohnungen (Provisioner verdienen durch Abstimmen, nicht nur durch Generieren); zusätzliche Guthaben belohnen (der Generator verliert die zusätzlichen 10 %, wenn er Stimmen ausschließt – Sabotage kostet sie also auch); Ausschluss von Generatoren der nächsten Iteration aus dem aktuellen Voting-Schritt.
Die meisten PoS-Systeme haben dieses Problem nicht: Keine sequentielle Iterationsstruktur bedeutet, dass kein Nachfolger darauf wartet, von dem Scheitern eines Vorgängers zu profitieren. Das Design von Dusk schafft diese Schwachstelle und behebt sie dann.
Ein Protokoll, das seinen eigenen spieltheoretischen Fehler explizit benennt, tut etwas Ungewöhnliches. Ob die drei Patches unter echter Netzbelastung mit konzentriertem Stake Bestand haben, ist die ehrliche offene Frage. @Dusk
$DUSK #dusk