#dusk $DUSK @Dusk
J’ai raté un vote de quarante secondes le mois dernier et j’ai passé la demi-heure suivante à rafraîchir mon tableau de bord, persuadé d’avoir perdu ma mise. Finalement, non. Ça m’a fait tomber dans un terrier et m’a amené à comprendre comment le système de récompenses de Dusk fonctionne vraiment, et la conception a répondu à mes inquiétudes mieux que je ne l’aurais cru.
La répartition des récompenses donne au générateur de bloc jusqu’à quatre-vingts pour cent, avec une partie de ce surplus liée au nombre de crédits inclus dans le certificat. Dix pour cent vont à un fonds de développement et les dix derniers sont partagés équitablement entre les comités de validation et de ratification. Rien de choquant là-dedans. Ce qui a attiré mon attention, en revanche, c’est à quel point la répartition est délibérément pondérée en faveur du générateur. Au début, ça m’a paru étrange que tant de choses aillent à un seul rôle, mais ça se comprend une fois qu’on réfléchit à qui fait réellement le gros du travail à chaque bloc.
Le point qui compte vraiment, c’est le système de faute. Dusk distingue les fautes mineures des fautes majeures plutôt que de traiter toute erreur de la même manière. Rater un vote parce que votre nœud a eu un hoquet et vous êtes suspendu un moment avec une partie de la mise temporairement bloquée. Rien n’est brûlé. Faire quelque chose de manifestement malveillant, comme signer des votes contradictoires, relève d’une autre catégorie avec une mise réellement brûlée. Je me souviens avoir lu des protocoles il y a des années qui brûlaient la mise pour tout temps d’arrêt et, honnêtement, ça m’a toujours semblé punitif plutôt que protecteur.
Je réfléchis peut-être trop, mais cette distinction ressemble vraiment à l’enseignement clé de la conception. Elle ne punit pas les opérateurs honnêtes pour des problèmes d’infrastructure tout en rendant les attaques intentionnelles coûteuses. La question est de savoir si cet équilibre tient face à une contrainte réseau réelle, à grande échelle : j’en suis encore curieux. Les systèmes de « slashing » ont toujours l’air plus nets sur le papier que dans la réalité une fois que des milliers de validateurs les exécutent réellement.
$TUT
$ZRO
Comment Dusk devrait-il gérer les fautes des validateurs ?
J’ai raté un vote de quarante secondes le mois dernier et j’ai passé la demi-heure suivante à rafraîchir mon tableau de bord, persuadé d’avoir perdu ma mise. Finalement, non. Ça m’a fait tomber dans un terrier et m’a amené à comprendre comment le système de récompenses de Dusk fonctionne vraiment, et la conception a répondu à mes inquiétudes mieux que je ne l’aurais cru.
La répartition des récompenses donne au générateur de bloc jusqu’à quatre-vingts pour cent, avec une partie de ce surplus liée au nombre de crédits inclus dans le certificat. Dix pour cent vont à un fonds de développement et les dix derniers sont partagés équitablement entre les comités de validation et de ratification. Rien de choquant là-dedans. Ce qui a attiré mon attention, en revanche, c’est à quel point la répartition est délibérément pondérée en faveur du générateur. Au début, ça m’a paru étrange que tant de choses aillent à un seul rôle, mais ça se comprend une fois qu’on réfléchit à qui fait réellement le gros du travail à chaque bloc.
Le point qui compte vraiment, c’est le système de faute. Dusk distingue les fautes mineures des fautes majeures plutôt que de traiter toute erreur de la même manière. Rater un vote parce que votre nœud a eu un hoquet et vous êtes suspendu un moment avec une partie de la mise temporairement bloquée. Rien n’est brûlé. Faire quelque chose de manifestement malveillant, comme signer des votes contradictoires, relève d’une autre catégorie avec une mise réellement brûlée. Je me souviens avoir lu des protocoles il y a des années qui brûlaient la mise pour tout temps d’arrêt et, honnêtement, ça m’a toujours semblé punitif plutôt que protecteur.
Je réfléchis peut-être trop, mais cette distinction ressemble vraiment à l’enseignement clé de la conception. Elle ne punit pas les opérateurs honnêtes pour des problèmes d’infrastructure tout en rendant les attaques intentionnelles coûteuses. La question est de savoir si cet équilibre tient face à une contrainte réseau réelle, à grande échelle : j’en suis encore curieux. Les systèmes de « slashing » ont toujours l’air plus nets sur le papier que dans la réalité une fois que des milliers de validateurs les exécutent réellement.
$TUT
$ZRO
Comment Dusk devrait-il gérer les fautes des validateurs ?
🟢 Suspend
100%
🔥 Slash
0%
⚖️ Both
0%
🤔 Depends
0%
1 Votes • Vote fermé