@Dusk J’étais en train de fouiller dans les mises à jour d’ingénierie de Dusk, essayant de comprendre comment Succinct Attestation finalise réellement un bloc, et pas seulement la formule marketing sur la « finalité probabiliste rapide ». Le passage qui m’a arrêté : chaque membre du comité reçoit un ou plusieurs votes, appelés crédits. Et l’ensemble total des votes d’un tour est fixe : les votes du comité sont appelés Credits, et le nombre de votes dans le comité est appelé Committee Credits. D’accord, c’est juste un vote pondéré par la mise. Rien de surprenant.
Ce que je n’avais pas envisagé, c’est ce qu’il advient ensuite de tous ces votes individuels. Ils ne restent pas simplement là, comme des signatures séparées. Le générateur de blocs les collecte et produit un certificat, qui est une attestation valide d’un bloc, incluse dans le bloc enfant suivant. Ainsi, la « preuve qu’un bloc est légitime » n’est pas la parole d’un seul validateur : c’est l’ensemble de chaque vote crédité compressé dans un seul objet agrégé BLS, et c’est cet objet que la future consensus référence réellement.
C’est là que le problème de l’unicité disparaît discrètement. L’agrégation oblige chaque crédit à pointer vers un seul candidat par tour. Vous ne pouvez pas faire compter votre vote deux fois, ni le compter pour deux blocs en concurrence, parce que le certificat n’a de la place que pour un seul ensemble canonique. Ce n’est pas une fonctionnalité d’UX. C’est ce qui fait que la finalité signifie quelque chose dans la $DUSK #dusk consensus. Je ne suis toujours pas sûr de son comportement en cas de timeouts d’itération lourds, cependant.
Ce que je n’avais pas envisagé, c’est ce qu’il advient ensuite de tous ces votes individuels. Ils ne restent pas simplement là, comme des signatures séparées. Le générateur de blocs les collecte et produit un certificat, qui est une attestation valide d’un bloc, incluse dans le bloc enfant suivant. Ainsi, la « preuve qu’un bloc est légitime » n’est pas la parole d’un seul validateur : c’est l’ensemble de chaque vote crédité compressé dans un seul objet agrégé BLS, et c’est cet objet que la future consensus référence réellement.
C’est là que le problème de l’unicité disparaît discrètement. L’agrégation oblige chaque crédit à pointer vers un seul candidat par tour. Vous ne pouvez pas faire compter votre vote deux fois, ni le compter pour deux blocs en concurrence, parce que le certificat n’a de la place que pour un seul ensemble canonique. Ce n’est pas une fonctionnalité d’UX. C’est ce qui fait que la finalité signifie quelque chose dans la $DUSK #dusk consensus. Je ne suis toujours pas sûr de son comportement en cas de timeouts d’itération lourds, cependant.