#dusk $DUSK
L’expression « emergency mode » revenait sans cesse dans le livre blanc de Dusk, et je passais toujours dessus. Quand j’ai enfin lu la section, le mécanisme est plus précis que ce que le nom laisse entendre.
Consensus Dusk normal : chaque tour s’exécute jusqu’à un maximum de 50 itérations. À chaque étape, Proposition, Validation, Ratification, il y a un délai d’expiration. Si aucun quorum ne se forme avant l’expiration, l’étape passe à la suivante et, éventuellement, une nouvelle itération commence. Séquentiel, borné, prévisible.
Le mode d’urgence est différent. Il se déclenche après 16 itérations échouées consécutives — où « échoué » signifie qu’aucun quorum n’a été atteint, généralement parce que les validateurs sont hors ligne ou isolés. Une fois déclenché : les délais d’étape sont désactivés. De nouvelles itérations sont lancées, mais chaque itération en cours reste active au lieu de se fermer. Plusieurs itérations ouvertes s’exécutent en parallèle. Cela augmente la probabilité de produire un bloc. Cela augmente aussi la probabilité de forks.
Les forks en mode d’urgence sont résolus en sélectionnant le bloc correspondant au plus petit numéro d’itération. Si le réseau ne parvient toujours pas à former un bloc, le dernier recours est un bloc d’urgence : un bloc vide, sans transactions, signé par Dusk l’entité à l’aide de sa clé publique globale. Les provisioners détenant une majorité des fonds en jeu le demandent.
Alors pourquoi le réseau n’utiliserait-il pas simplement le mode d’urgence dès qu’il veut aller plus vite.
Le mode normal sacrifie un peu de vitesse pour une finalité plus propre. Des itérations ouvertes concurrentes améliorent la vivacité sous contrainte, mais introduisent de la complexité, et le bloc vide de secours est une intervention centralisée — la chaîne continue d’avancer, mais c’est Dusk l’entité qui la fait avancer.
Je trouve en fait que le bloc d’urgence est la question de conception la plus intéressante — car cela signifie que la garantie de vivacité dépend en fin de compte de la disponibilité de l’entité Dusk et de sa volonté de signer. La sécurité du protocole et la décentralisation tirent là dans des directions légèrement différentes.
Ce que je n’ai pas vu expliqué, c’est ce qu’il advient des transactions qui étaient en cours lorsqu’un bloc d’urgence remplace un bloc normal — qu’elles soient réintégrées dans le tour suivant ou simplement abandonnées. @Dusk
$DUSK #dusk
L’expression « emergency mode » revenait sans cesse dans le livre blanc de Dusk, et je passais toujours dessus. Quand j’ai enfin lu la section, le mécanisme est plus précis que ce que le nom laisse entendre.
Consensus Dusk normal : chaque tour s’exécute jusqu’à un maximum de 50 itérations. À chaque étape, Proposition, Validation, Ratification, il y a un délai d’expiration. Si aucun quorum ne se forme avant l’expiration, l’étape passe à la suivante et, éventuellement, une nouvelle itération commence. Séquentiel, borné, prévisible.
Le mode d’urgence est différent. Il se déclenche après 16 itérations échouées consécutives — où « échoué » signifie qu’aucun quorum n’a été atteint, généralement parce que les validateurs sont hors ligne ou isolés. Une fois déclenché : les délais d’étape sont désactivés. De nouvelles itérations sont lancées, mais chaque itération en cours reste active au lieu de se fermer. Plusieurs itérations ouvertes s’exécutent en parallèle. Cela augmente la probabilité de produire un bloc. Cela augmente aussi la probabilité de forks.
Les forks en mode d’urgence sont résolus en sélectionnant le bloc correspondant au plus petit numéro d’itération. Si le réseau ne parvient toujours pas à former un bloc, le dernier recours est un bloc d’urgence : un bloc vide, sans transactions, signé par Dusk l’entité à l’aide de sa clé publique globale. Les provisioners détenant une majorité des fonds en jeu le demandent.
Alors pourquoi le réseau n’utiliserait-il pas simplement le mode d’urgence dès qu’il veut aller plus vite.
Le mode normal sacrifie un peu de vitesse pour une finalité plus propre. Des itérations ouvertes concurrentes améliorent la vivacité sous contrainte, mais introduisent de la complexité, et le bloc vide de secours est une intervention centralisée — la chaîne continue d’avancer, mais c’est Dusk l’entité qui la fait avancer.
Je trouve en fait que le bloc d’urgence est la question de conception la plus intéressante — car cela signifie que la garantie de vivacité dépend en fin de compte de la disponibilité de l’entité Dusk et de sa volonté de signer. La sécurité du protocole et la décentralisation tirent là dans des directions légèrement différentes.
Ce que je n’ai pas vu expliqué, c’est ce qu’il advient des transactions qui étaient en cours lorsqu’un bloc d’urgence remplace un bloc normal — qu’elles soient réintégrées dans le tour suivant ou simplement abandonnées. @Dusk
$DUSK #dusk
