Je suis retourné hier soir dans la documentation du @Dusk , en particulier la section consacrée à leur consensus « Succinct Attestation ». Il s’agit d’une configuration de preuve d’enjeu (proof-of-stake) permissionless, basée sur un comité, gérée par des « provisioners »… toute personne qui immobilise au moins 1000 DUSK comme mise.
Une mise correspond simplement au montant plus la hauteur de bloc à laquelle elle a été incluse. L’éligibilité n’est pas immédiate. Il existe une période de maturité calculée par M = 2 × epoch − (hauteur mod epoch), et l’epoch est actuellement de 2160 blocs. Ce n’est qu’après cette fenêtre de maturité, et si le montant atteint le minimum, que la mise entre dans la loterie déterministe de sortition, qui sélectionne le générateur de bloc et les comités de vote pour chaque tour.
Le processus lui-même fonctionne par tours et itérations. Chaque itération comporte trois étapes : proposition (un provisioner est sélectionné pour soumettre un bloc candidat), validation (un comité vote « Valid », « Invalid » ou « NoCandidate », en exigeant une supermajorité des 2/3 pour « Valid » ou une majorité simple pour « Invalid »), puis ratification (un comité fraîchement constitué confirme le résultat). Un tour peut aller jusqu’à 50 itérations avant d’échouer.
Ce que j’ai encore du mal à trancher, c’est la façon dont la sortition non interactive et les comités qui tournent influencent concrètement la décentralisation à long terme et le risque de captation par un comité. Les paramètres fixes… le minimum de 1000 DUSK, les epochs de 2160 blocs, le plafond de 50 itérations… semblent intentionnels, mais je n’ai pas trouvé de discussion claire sur la manière dont ils pourraient être ajustés plus tard, ni sur le processus de gouvernance qui contrôlerait cela.
Je suis curieux de savoir comment les autres interprètent les hypothèses de sécurité autour des comités de vote et du délai de maturité. La conception vous paraît-elle robuste, ou bien est-ce que je passe à côté de certains cas limites ?
#dusk $DUSK
Une mise correspond simplement au montant plus la hauteur de bloc à laquelle elle a été incluse. L’éligibilité n’est pas immédiate. Il existe une période de maturité calculée par M = 2 × epoch − (hauteur mod epoch), et l’epoch est actuellement de 2160 blocs. Ce n’est qu’après cette fenêtre de maturité, et si le montant atteint le minimum, que la mise entre dans la loterie déterministe de sortition, qui sélectionne le générateur de bloc et les comités de vote pour chaque tour.
Le processus lui-même fonctionne par tours et itérations. Chaque itération comporte trois étapes : proposition (un provisioner est sélectionné pour soumettre un bloc candidat), validation (un comité vote « Valid », « Invalid » ou « NoCandidate », en exigeant une supermajorité des 2/3 pour « Valid » ou une majorité simple pour « Invalid »), puis ratification (un comité fraîchement constitué confirme le résultat). Un tour peut aller jusqu’à 50 itérations avant d’échouer.
Ce que j’ai encore du mal à trancher, c’est la façon dont la sortition non interactive et les comités qui tournent influencent concrètement la décentralisation à long terme et le risque de captation par un comité. Les paramètres fixes… le minimum de 1000 DUSK, les epochs de 2160 blocs, le plafond de 50 itérations… semblent intentionnels, mais je n’ai pas trouvé de discussion claire sur la manière dont ils pourraient être ajustés plus tard, ni sur le processus de gouvernance qui contrôlerait cela.
Je suis curieux de savoir comment les autres interprètent les hypothèses de sécurité autour des comités de vote et du délai de maturité. La conception vous paraît-elle robuste, ou bien est-ce que je passe à côté de certains cas limites ?
#dusk $DUSK