Je suis repassé hier soir dans la documentation de Dusk, et la section sur le mode d’urgence m’a amené à regarder le consensus un peu différemment.
Au début, je pensais qu’un mécanisme d’urgence était simplement une solution de secours lorsque les validateurs passent hors ligne. Mais les détails sont plus intéressants.
Dusk utilise des comités de validation et de ratification, avec des proposeurs sélectionnés aléatoirement qui votent pour déterminer si un bloc proposé est valide et si ce résultat doit être accepté. Le quorum nécessite des seuils différents selon le vote, y compris une supermajorité de 2/3 pour les votes « Valid ».
Que se passe-t-il lorsque le réseau n’arrive pas à atteindre ce quorum ?
Après 16 itérations échouées, d’après la documentation, le protocole passe en mode d’urgence. Au lieu d’attendre et d’abandonner, les itérations peuvent rester ouvertes jusqu’à ce qu’un candidat obtienne suffisamment de soutien. Plusieurs itérations peuvent s’exécuter simultanément, ce qui augmente les chances de produire un bloc, mais crée aussi un risque de forks.
J’ai trouvé ce compromis intéressant.
Si plusieurs blocs candidats parviennent à trouver un consensus, le protocole résout le fork en choisissant le candidat provenant de l’itération la plus basse. Je suis curieux de la manière dont cela se comporte en cas de congestion réseau prolongée ou d’isolement partiel, en particulier lorsque différentes parties du réseau voient les messages à des instants différents.
Le repli final est encore plus inhabituel. Si la dernière itération échoue, les proposeurs détenant une majorité de la mise totale peuvent demander un bloc d’urgence. Ce bloc ne contient aucune transaction et permet au réseau de passer au tour suivant.
Cela soulève pour moi des questions sur la gouvernance et la décentralisation.
Exiger une majorité de la mise pour un bloc d’urgence crée-t-il un mécanisme de sécurité utile, ou pourrait-il devenir un levier d’influence lors d’une grave défaillance du réseau ?
Et à quel point le système est-il robuste lorsque la communication est fortement perturbée mais que différents comités continuent de fonctionner ?
Je continue d’explorer les cas limites, mais ce sont les aspects de la conception du consensus que je trouve les plus intéressants à comprendre.
@Dusk $DUSK #dusk
#dusk $DUSK @Dusk
Au début, je pensais qu’un mécanisme d’urgence était simplement une solution de secours lorsque les validateurs passent hors ligne. Mais les détails sont plus intéressants.
Dusk utilise des comités de validation et de ratification, avec des proposeurs sélectionnés aléatoirement qui votent pour déterminer si un bloc proposé est valide et si ce résultat doit être accepté. Le quorum nécessite des seuils différents selon le vote, y compris une supermajorité de 2/3 pour les votes « Valid ».
Que se passe-t-il lorsque le réseau n’arrive pas à atteindre ce quorum ?
Après 16 itérations échouées, d’après la documentation, le protocole passe en mode d’urgence. Au lieu d’attendre et d’abandonner, les itérations peuvent rester ouvertes jusqu’à ce qu’un candidat obtienne suffisamment de soutien. Plusieurs itérations peuvent s’exécuter simultanément, ce qui augmente les chances de produire un bloc, mais crée aussi un risque de forks.
J’ai trouvé ce compromis intéressant.
Si plusieurs blocs candidats parviennent à trouver un consensus, le protocole résout le fork en choisissant le candidat provenant de l’itération la plus basse. Je suis curieux de la manière dont cela se comporte en cas de congestion réseau prolongée ou d’isolement partiel, en particulier lorsque différentes parties du réseau voient les messages à des instants différents.
Le repli final est encore plus inhabituel. Si la dernière itération échoue, les proposeurs détenant une majorité de la mise totale peuvent demander un bloc d’urgence. Ce bloc ne contient aucune transaction et permet au réseau de passer au tour suivant.
Cela soulève pour moi des questions sur la gouvernance et la décentralisation.
Exiger une majorité de la mise pour un bloc d’urgence crée-t-il un mécanisme de sécurité utile, ou pourrait-il devenir un levier d’influence lors d’une grave défaillance du réseau ?
Et à quel point le système est-il robuste lorsque la communication est fortement perturbée mais que différents comités continuent de fonctionner ?
Je continue d’explorer les cas limites, mais ce sont les aspects de la conception du consensus que je trouve les plus intéressants à comprendre.
@Dusk $DUSK #dusk
#dusk $DUSK @Dusk
