@Dusk_Foundation
Au début, j’ai supposé que les tours de consensus de Dusk étaient surtout une question d’attendre suffisamment de votes. Mais en regardant davantage la structure d’itération, ce qui est resté avec moi, c’est qu’une tentative échouée ne disparaît pas simplement. Si la validation ou la ratification échoue, le protocole passe à une autre itération, avec un nouveau générateur et des comités sélectionnés via une sélection déterministe. Cela crée une petite mais intéressante dépendance : une tentative ultérieure est en partie façonnée par ce qui s’est passé lors des tentatives précédentes. Le livre blanc limite même un tour à 50 itérations, ce qui suggère que l’échec n’est pas traité comme un cas exceptionnel que l’on peut ignorer. Il doit s’inscrire dans un processus borné. Je trouve cela plus intéressant que la description habituelle de « finalité rapide ». Ici, le consensus semble consister autant à gérer une coordination infructueuse qu’à gérer une coordination réussie. Il est peut-être inévitable que ce soit le cas lorsque la participation au réseau n’est pas parfaitement fiable. Ce qui laisse la question plus discrète : comment un système de consensus doit-il équilibrer la persistance avec le coût de tentatives répétées pour parvenir à un accord ? #dusk $DUSK @Dusk $DUSK
Au début, j’ai supposé que les tours de consensus de Dusk étaient surtout une question d’attendre suffisamment de votes. Mais en regardant davantage la structure d’itération, ce qui est resté avec moi, c’est qu’une tentative échouée ne disparaît pas simplement. Si la validation ou la ratification échoue, le protocole passe à une autre itération, avec un nouveau générateur et des comités sélectionnés via une sélection déterministe. Cela crée une petite mais intéressante dépendance : une tentative ultérieure est en partie façonnée par ce qui s’est passé lors des tentatives précédentes. Le livre blanc limite même un tour à 50 itérations, ce qui suggère que l’échec n’est pas traité comme un cas exceptionnel que l’on peut ignorer. Il doit s’inscrire dans un processus borné. Je trouve cela plus intéressant que la description habituelle de « finalité rapide ». Ici, le consensus semble consister autant à gérer une coordination infructueuse qu’à gérer une coordination réussie. Il est peut-être inévitable que ce soit le cas lorsque la participation au réseau n’est pas parfaitement fiable. Ce qui laisse la question plus discrète : comment un système de consensus doit-il équilibrer la persistance avec le coût de tentatives répétées pour parvenir à un accord ? #dusk $DUSK @Dusk $DUSK