Hier soir, je cartographiais la structure de la récompense de bloc de @Dusk et j’ai découvert un piège économique que je n’avais vu documenté nulle part de façon claire.
À première vue, la répartition semble simple. 80 % pour le générateur de bloc, 10 % pour le comité de vote, 10 % pour Dusk. Rien de plus évident.
Mais les 80 % ne sont pas garantis.
La récompense du générateur est répartie en deux parties. 70 % est fixe : ils l’obtiennent quoi qu’il arrive. Les 10 % restants sont variables et dépendent entièrement du nombre de votes qu’ils incluent dans le certificat de bloc. Incluez tous les votes connus, et vous obtenez l’intégralité des 80 %. Excluez des votes, et votre récompense diminue.
Je me suis demandé pourquoi ce design précis existe.
Sur Dusk, les générateurs de blocs de toutes les itérations d’un tour sont prévisibles avant la fin du tour. Un générateur planifié pour l’itération 5 sait qu’il va arriver. La tentation est évidente : faire échouer les itérations précédentes, puis s’approprier soi-même la récompense de bloc. Les générateurs des itérations plus élevées ont donc une incitation à saboter les plus en amont.
La récompense variable inverse cette incitation. Si vous excluez des votes pour ralentir les itérations précédentes, vous réduisez directement votre propre paiement. Le protocole rend le sabotage économiquement contre-productif.
Puis il y a la couche de pénalité. Des fautes mineures entraînent une suspension : exclusion de la sélection pendant des périodes définies. Des fautes majeures, comme le vote double, déclenchent un slashing sévère : une partie de la mise est brûlée de façon permanente. Elle n’est pas verrouillée. Elle est brûlée.
$DUSK est l’actif mis en jeu dans chacune de ces décisions économiques.
Le design d’incitation de Dusk est-il assez sophistiqué pour empêcher les comportements incorrects des validateurs à grande échelle, ou la prévisibilité des futurs générateurs crée-t-elle des vecteurs d’attaque que la structure de récompense ne peut pas entièrement neutraliser ?
@Dusk $DUSK #dusk
$CATI
Qu’est-ce qui empêche les validateurs de mal se comporter ?
À première vue, la répartition semble simple. 80 % pour le générateur de bloc, 10 % pour le comité de vote, 10 % pour Dusk. Rien de plus évident.
Mais les 80 % ne sont pas garantis.
La récompense du générateur est répartie en deux parties. 70 % est fixe : ils l’obtiennent quoi qu’il arrive. Les 10 % restants sont variables et dépendent entièrement du nombre de votes qu’ils incluent dans le certificat de bloc. Incluez tous les votes connus, et vous obtenez l’intégralité des 80 %. Excluez des votes, et votre récompense diminue.
Je me suis demandé pourquoi ce design précis existe.
Sur Dusk, les générateurs de blocs de toutes les itérations d’un tour sont prévisibles avant la fin du tour. Un générateur planifié pour l’itération 5 sait qu’il va arriver. La tentation est évidente : faire échouer les itérations précédentes, puis s’approprier soi-même la récompense de bloc. Les générateurs des itérations plus élevées ont donc une incitation à saboter les plus en amont.
La récompense variable inverse cette incitation. Si vous excluez des votes pour ralentir les itérations précédentes, vous réduisez directement votre propre paiement. Le protocole rend le sabotage économiquement contre-productif.
Puis il y a la couche de pénalité. Des fautes mineures entraînent une suspension : exclusion de la sélection pendant des périodes définies. Des fautes majeures, comme le vote double, déclenchent un slashing sévère : une partie de la mise est brûlée de façon permanente. Elle n’est pas verrouillée. Elle est brûlée.
$DUSK est l’actif mis en jeu dans chacune de ces décisions économiques.
Le design d’incitation de Dusk est-il assez sophistiqué pour empêcher les comportements incorrects des validateurs à grande échelle, ou la prévisibilité des futurs générateurs crée-t-elle des vecteurs d’attaque que la structure de récompense ne peut pas entièrement neutraliser ?
@Dusk $DUSK #dusk
$CATI
Qu’est-ce qui empêche les validateurs de mal se comporter ?
💰 Economic rewards done right
67%
🔥 Stake slashing penalties
0%
👥 Committee oversight
0%
🔄 All three together
33%
6 Votes • Vote fermé