#dusk $DUSK @Dusk A traversé la section sur l’incitation au consensus cette semaine parce que je voulais comprendre si un plus gros miseur pouvait “truquer” le calendrier de génération des blocs.
Découverte inattendue : le livre blanc nomme ce problème exact lui-même. « Future-generator incentive problem » — des générateurs à plus haute itération peuvent en bénéficier si des itérations précédentes échouent, car ils remportent ensuite la récompense du bloc. C’est une vulnérabilité nommée, pas cachée.
La mise à niveau du protocole Aegis sur le réseau principal (3 mars 2026) a porté sur la résilience du réseau. Une partie de la raison pour laquelle la résilience compte ici : cette incitation exacte peut faire sous-performer les générateurs des itérations antérieures.
Trois mécanismes y répondent : des récompenses aux votants (les prestataires gagnent en votant, pas seulement en générant) ; des crédits supplémentaires (le générateur perd le bonus de 10 % s’il exclut des votes — donc le sabotage lui coûte aussi) ; l’exclusion des générateurs de l’itération suivante de l’étape de vote en cours.
La plupart des systèmes PoS ne présentent pas ce problème : aucune structure d’itération séquentielle ne signifie qu’aucun successeur n’attend pour bénéficier de l’échec d’un prédécesseur. La conception de Dusk crée cette vulnérabilité, puis la corrige.
Un protocole qui nomme explicitement sa propre faille de théorie des jeux fait quelque chose de peu courant. Les trois correctifs tiennent-ils sous une pression réelle du réseau avec une mise concentrée ? C’est la question ouverte honnête. @Dusk
$DUSK #dusk
Découverte inattendue : le livre blanc nomme ce problème exact lui-même. « Future-generator incentive problem » — des générateurs à plus haute itération peuvent en bénéficier si des itérations précédentes échouent, car ils remportent ensuite la récompense du bloc. C’est une vulnérabilité nommée, pas cachée.
La mise à niveau du protocole Aegis sur le réseau principal (3 mars 2026) a porté sur la résilience du réseau. Une partie de la raison pour laquelle la résilience compte ici : cette incitation exacte peut faire sous-performer les générateurs des itérations antérieures.
Trois mécanismes y répondent : des récompenses aux votants (les prestataires gagnent en votant, pas seulement en générant) ; des crédits supplémentaires (le générateur perd le bonus de 10 % s’il exclut des votes — donc le sabotage lui coûte aussi) ; l’exclusion des générateurs de l’itération suivante de l’étape de vote en cours.
La plupart des systèmes PoS ne présentent pas ce problème : aucune structure d’itération séquentielle ne signifie qu’aucun successeur n’attend pour bénéficier de l’échec d’un prédécesseur. La conception de Dusk crée cette vulnérabilité, puis la corrige.
Un protocole qui nomme explicitement sa propre faille de théorie des jeux fait quelque chose de peu courant. Les trois correctifs tiennent-ils sous une pression réelle du réseau avec une mise concentrée ? C’est la question ouverte honnête. @Dusk
$DUSK #dusk