Je me suis penché plus attentivement sur la manière dont @Dusk gère le consensus, et un détail que je trouve facile à négliger est que le processus n’est pas traité comme une seule décision unique.

Un bloc « Ama » est d’abord préparé et proposé. Ensuite, les participants au vote l’évaluent avant que le réseau ne se mette d’accord sur l’état qui en résulte.

Cette séparation compte pour moi, car produire un bloc candidat et accepter ce bloc ne sont pas la même chose. Si une proposition est incorrecte, l’étape de vote fournit un point distinct où les participants peuvent la rejeter, plutôt que de traiter la production de blocs elle-même comme une acceptation.

J’aime ce design d’un point de vue « systèmes ». Il rend la logique plus facile à séparer : proposer d’abord, parvenir à un accord ensuite.

Mais il y a un autre aspect auquel je pense. Des étapes plus explicites signifient aussi davantage de coordination entre les composants. Si ces étapes dépendent les unes des autres, une structure supplémentaire peut introduire de nouveaux endroits où la coordination doit fonctionner correctement.

Mon avis est que la question intéressante n’est pas de savoir si la conception paraît sophistiquée. La question est de savoir si cette séparation améliore réellement la résilience sans créer une complexité inutile.

Le consensus par étapes rend-il Dusk plus robuste face à de mauvaises propositions ? Ou bien la coordination ajoutée crée-t-elle un nouvel arbitrage ?
#dusk $DUSK