Je me suis penché sur la raison pour laquelle Dusk récompense spécifiquement les électeurs qui soutiennent des candidats issus d’itérations antérieures déjà échouées — et les mécanismes derrière cette incitation vont bien plus loin que la description basique en trois étapes.
Les trois étapes elles-mêmes sont simples sur le papier : la Proposition génère un candidat, la Validation le vérifie, la Ratification confirme que le contrôle était réel. Ce qui n’est pas évident, c’est comment Dusk amène des comités ultérieurs à réellement prendre la peine de relancer le candidat d’une itération précédente plutôt que d’attendre simplement un candidat tout nouveau.
Faites le calcul sur le partage de la récompense, en particulier. Les notes techniques de Dusk décrivent que le Block Certificate verse 90 % de la récompense du bloc précédent aux générateurs, les 10 % restants étant répartis entre les électeurs — divisés en 64 quotas, un par crédit de comité. Ainsi, un électeur disposant de plus de crédits pondérés par les enjeux gagne proportionnellement davantage de cette tranche.
Voici la partie qui m’a réellement surpris. Cette récompense de 10 % aux électeurs n’était pas toujours versée de cette façon. La mise à jour de Dusk explique qu’elle a été ajoutée précisément pour encourager, lors des itérations futures, les générateurs de blocs à voter pour des candidats d’itérations précédentes. Autrement dit, le système avait besoin d’une incitation financière délibérée avant que les comités ne prennent de façon fiable la peine de récupérer un bloc déjà expiré, plutôt que de le laisser mourir.
Ainsi, une itération échouée sur Dusk n’est pas une impasse par accident. Elle reste récupérable parce que Dusk a intégré un paiement spécifique dans le protocole pour que la récupération en vaille la peine pour un comité — pas parce que les comités le feraient naturellement gratuitement.
Payer les comités pour sauver des tentatives échouées, ou admettre discrètement que la première tentative a souvent besoin d’un petit coup de pouce financier pour aboutir correctement ? Je n’en suis pas encore sûr.
#dusk $DUSK @Dusk
Les trois étapes elles-mêmes sont simples sur le papier : la Proposition génère un candidat, la Validation le vérifie, la Ratification confirme que le contrôle était réel. Ce qui n’est pas évident, c’est comment Dusk amène des comités ultérieurs à réellement prendre la peine de relancer le candidat d’une itération précédente plutôt que d’attendre simplement un candidat tout nouveau.
Faites le calcul sur le partage de la récompense, en particulier. Les notes techniques de Dusk décrivent que le Block Certificate verse 90 % de la récompense du bloc précédent aux générateurs, les 10 % restants étant répartis entre les électeurs — divisés en 64 quotas, un par crédit de comité. Ainsi, un électeur disposant de plus de crédits pondérés par les enjeux gagne proportionnellement davantage de cette tranche.
Voici la partie qui m’a réellement surpris. Cette récompense de 10 % aux électeurs n’était pas toujours versée de cette façon. La mise à jour de Dusk explique qu’elle a été ajoutée précisément pour encourager, lors des itérations futures, les générateurs de blocs à voter pour des candidats d’itérations précédentes. Autrement dit, le système avait besoin d’une incitation financière délibérée avant que les comités ne prennent de façon fiable la peine de récupérer un bloc déjà expiré, plutôt que de le laisser mourir.
Ainsi, une itération échouée sur Dusk n’est pas une impasse par accident. Elle reste récupérable parce que Dusk a intégré un paiement spécifique dans le protocole pour que la récupération en vaille la peine pour un comité — pas parce que les comités le feraient naturellement gratuitement.
Payer les comités pour sauver des tentatives échouées, ou admettre discrètement que la première tentative a souvent besoin d’un petit coup de pouce financier pour aboutir correctement ? Je n’en suis pas encore sûr.
#dusk $DUSK @Dusk
Smart incentive design
Needs a financial nudge
6 heure(s) restante(s)