Je suis retourné(e) dans le livre blanc « Dusk » hier soir, en me concentrant sur les sections « emergency mode », « fallback » et « rolling finality ». Les détails étaient plus nuancés que je ne l’avais d’abord imaginé.

Le mode d’urgence s’active après 16 itérations échouées. Les dépassements de délai (« timeouts ») des étapes sont alors désactivés, et les itérations ouvertes continuent jusqu’à ce qu’un bloc candidat atteigne le quorum à la fois dans la validation et dans la ratification. Plusieurs itérations peuvent s’exécuter en même temps, ce qui améliore les chances de produire un bloc, mais augmente aussi la probabilité de forks. Si plusieurs candidats parviennent à un consensus, l’itération la plus basse est sélectionnée. À la dernière itération, les provisionneurs peuvent demander un bloc d’urgence, mais cela nécessite des provisionneurs détenant la majorité de la mise totale du réseau.

Les règles de fallback ont également attiré mon attention : un bloc provenant de l’itération J > 0 peut potentiellement être remplacé par un bloc d’itération inférieure qui atteint ensuite le consensus, tandis que l’itération 0 ne peut pas être remplacée de cette manière.

Puis la finalité « rolling » ajoute une couche supplémentaire. Si n itérations précédentes échouent à l’attestation, un bloc est accepté et doit obtenir 2×n blocs attestés ou confirmés consécutifs pour devenir confirmé. L’exemple du document utilise l’itération 5, avec n=2, ce qui signifie qu’il faut 4 blocs supplémentaires.

Je me pose encore la question : cette conception crée-t-elle un risque réel de centralisation lié à la récupération d’urgence pondérée par la mise ?

@Dusk #dusk $DUSK