@Dusk
Au début, j’ai supposé que le mode d’urgence de Dusk était principalement une solution de secours en cas de blocage de la production de blocs. Mais plus je regardais, plus un petit détail sautait aux yeux : les itérations ouvertes peuvent continuer en même temps. Une nouvelle itération démarre après le délai maximal de temporisation de l’étape, tandis que les itérations précédentes restent en vie jusqu’à ce qu’elles atteignent réellement le quorum. Cela signifie que le protocole accepte des tentatives parallèles temporaires au lieu d’obliger le réseau à attendre un chemin bloqué. Le coût évident, c’est que plusieurs candidats peuvent éventuellement parvenir à un consensus, ce qui crée une fourche (fork) qui doit ensuite être résolue en choisissant l’itération la plus basse. Je trouve cet arbitrage plus intéressant que l’étiquette « urgence » elle-même. En pratique, Dusk échange un certain désordre à court terme contre une meilleure chance qu’au moins un chemin avance quand des provisionneurs manquent ou sont isolés. Peut-être que c’est un mode de défaillance raisonnable, mais cela déplace la complexité du fait d’attendre vers la résolution des forks.
Cela me fait me demander si la résilience tient parfois moins à éviter des états compliqués qu’à s’assurer que le chaos a une issue déterministe ?
@Dusk #dusk $DUSK
Au début, j’ai supposé que le mode d’urgence de Dusk était principalement une solution de secours en cas de blocage de la production de blocs. Mais plus je regardais, plus un petit détail sautait aux yeux : les itérations ouvertes peuvent continuer en même temps. Une nouvelle itération démarre après le délai maximal de temporisation de l’étape, tandis que les itérations précédentes restent en vie jusqu’à ce qu’elles atteignent réellement le quorum. Cela signifie que le protocole accepte des tentatives parallèles temporaires au lieu d’obliger le réseau à attendre un chemin bloqué. Le coût évident, c’est que plusieurs candidats peuvent éventuellement parvenir à un consensus, ce qui crée une fourche (fork) qui doit ensuite être résolue en choisissant l’itération la plus basse. Je trouve cet arbitrage plus intéressant que l’étiquette « urgence » elle-même. En pratique, Dusk échange un certain désordre à court terme contre une meilleure chance qu’au moins un chemin avance quand des provisionneurs manquent ou sont isolés. Peut-être que c’est un mode de défaillance raisonnable, mais cela déplace la complexité du fait d’attendre vers la résolution des forks.
Cela me fait me demander si la résilience tient parfois moins à éviter des états compliqués qu’à s’assurer que le chaos a une issue déterministe ?
@Dusk #dusk $DUSK
