#dusk $DUSK $ENA $PROM @Dusk J'ai remarqué un petit détail en observant le consensus de Dusk que j'aurais probablement ignoré auparavant : la partie difficile n'est pas toujours d'amener les valideurs à se mettre d'accord. Parfois, il s'agit surtout de transporter une preuve du fait qu'ils sont parvenus à un accord, sans pour autant alourdir la preuve elle-même.
Un comité peut produire de nombreuses signatures individuelles. Plus de participation peut renforcer l’argument, bien sûr, mais cela laisse aussi le réseau avec davantage de données à déplacer et à vérifier. BLS12-381 change cette donne. Dusk peut agréger plusieurs signatures dans une représentation compacte, de sorte que le réseau n’a pas besoin de continuer à pousser chaque signature séparément.
Cela paraît simple, jusqu'à ce qu'on y regarde de plus près.
Les votes doivent toujours être valides. Les signataires doivent toujours être éligibles. Les clés doivent toujours être gérées, les signatures doivent toujours être vérifiées, et l’implémentation doit toujours composer avec des choses très ordinaires, comme la sérialisation et le coût CPU. Dusk a même travaillé sur la mise en cache des conversions de clés publiques BLS, ce qui en dit long sur les endroits où ces systèmes se compliquent réellement.
Donc je ne vois pas BLS simplement comme un moyen de rendre les signatures plus petites. Cela change la façon dont l’accord collectif circule à travers le protocole.
Ce que je veux surveiller ensuite, c’est si cette compression conserve son avantage à mesure que la participation du comité et l’activité réseau augmentent.
Un comité peut produire de nombreuses signatures individuelles. Plus de participation peut renforcer l’argument, bien sûr, mais cela laisse aussi le réseau avec davantage de données à déplacer et à vérifier. BLS12-381 change cette donne. Dusk peut agréger plusieurs signatures dans une représentation compacte, de sorte que le réseau n’a pas besoin de continuer à pousser chaque signature séparément.
Cela paraît simple, jusqu'à ce qu'on y regarde de plus près.
Les votes doivent toujours être valides. Les signataires doivent toujours être éligibles. Les clés doivent toujours être gérées, les signatures doivent toujours être vérifiées, et l’implémentation doit toujours composer avec des choses très ordinaires, comme la sérialisation et le coût CPU. Dusk a même travaillé sur la mise en cache des conversions de clés publiques BLS, ce qui en dit long sur les endroits où ces systèmes se compliquent réellement.
Donc je ne vois pas BLS simplement comme un moyen de rendre les signatures plus petites. Cela change la façon dont l’accord collectif circule à travers le protocole.
Ce que je veux surveiller ensuite, c’est si cette compression conserve son avantage à mesure que la participation du comité et l’activité réseau augmentent.
