À cause de ce typhon « ChadeL », j’attendais à l’aéroport avec des retards de vol. La diffusion répétait toutes les dix minutes : « Désolé, notification », puis le message est passé de « Retard prévu d’une heure » à « Deux heures », avant de devenir tout simplement : « Veuillez patienter. » Juste à côté, un grand monsieur, en colère, a appelé le service client : « Est-ce que ça décolle, oui ou non ? » Le service client a répondu : « C’est à cause de la météo. On attend aussi les toutes dernières instructions. » Et là, je me suis dit — cet état où l’on est “toujours en attente du résultat final”, n’est-ce pas exactement le dilemme de finalité des nombreuses blockchains ?
En clair, la confirmation des transactions sur la plupart des chaînes PoS, c’est aussi du “wait and see” (attendre et voir) : attendre que davantage de blocs se chaînent, attendre que la probabilité de bifurcation baisse suffisamment, puis seulement oser dire que cet argent est bien arrivé. Le problème, c’est que personne ne sait combien de temps il faudra attendre.
Le livre blanc de Dusk décrit la Rolling Finality (finalité progressive) en découpant cette question en quatre niveaux d’état : Accepted (accepté), Attested (attesté), Confirmed (confirmé) et Final (final). Accepted comporte une preuve de succès, mais ce bloc pourrait encore être remplacé par un bloc d’un tour inférieur ; Attested signifie que toutes les itérations précédentes ont échoué : ce bloc ne peut plus être remplacé dans la même itération ; Confirmed implique que suffisamment de blocs ont été ajoutés ensuite : sauf si un ancêtre est rétrolé, c’est pratiquement sûr ; Final, c’est le verrouillage total : dans aucun cas ce n’est réversible.
Les données qui justifient la nécessité de ce design : théoriquement, un bloc peut faire jusqu’à 50 itérations. Si 16 itérations consécutives échouent, le protocole passe automatiquement en mode d’urgence : tous les timeouts sont désactivés et les itérations continuent indéfiniment jusqu’à produire un bloc. 50 est la limite finale de configuration, mais en mode d’urgence, le chemin ouvert continue de fonctionner.
Franchement, quand je regardais avant d’autres projets qui parlaient de « finalité », je trouvais ça comme une annonce à l’aéroport : on le dit, mais ça ne sert à rien. Avec le système à quatre niveaux de Dusk, j’ai pour la première fois l’impression que la finalité peut être quantifiée et anticipée. De Accepted à Final, chaque niveau a des conditions mathématiques claires : ce n’est pas juste « attendre et voir » pour faire joli.
Aujourd’hui, ce vol a finalement décollé après quatre heures de retard. Si la finalité d’une blockchain devait fonctionner comme à l’aéroport, basée sur l’“attente”, qui oserait l’utiliser pour des paiements et des règlements financiers ? Dusk décompose le “non réversible” en quatre paliers, et chaque palier a des règles explicites : cette déterminisme, c’est justement ce dont la finance a besoin. #dusk $DUSK @Dusk
En clair, la confirmation des transactions sur la plupart des chaînes PoS, c’est aussi du “wait and see” (attendre et voir) : attendre que davantage de blocs se chaînent, attendre que la probabilité de bifurcation baisse suffisamment, puis seulement oser dire que cet argent est bien arrivé. Le problème, c’est que personne ne sait combien de temps il faudra attendre.
Le livre blanc de Dusk décrit la Rolling Finality (finalité progressive) en découpant cette question en quatre niveaux d’état : Accepted (accepté), Attested (attesté), Confirmed (confirmé) et Final (final). Accepted comporte une preuve de succès, mais ce bloc pourrait encore être remplacé par un bloc d’un tour inférieur ; Attested signifie que toutes les itérations précédentes ont échoué : ce bloc ne peut plus être remplacé dans la même itération ; Confirmed implique que suffisamment de blocs ont été ajoutés ensuite : sauf si un ancêtre est rétrolé, c’est pratiquement sûr ; Final, c’est le verrouillage total : dans aucun cas ce n’est réversible.
Les données qui justifient la nécessité de ce design : théoriquement, un bloc peut faire jusqu’à 50 itérations. Si 16 itérations consécutives échouent, le protocole passe automatiquement en mode d’urgence : tous les timeouts sont désactivés et les itérations continuent indéfiniment jusqu’à produire un bloc. 50 est la limite finale de configuration, mais en mode d’urgence, le chemin ouvert continue de fonctionner.
Franchement, quand je regardais avant d’autres projets qui parlaient de « finalité », je trouvais ça comme une annonce à l’aéroport : on le dit, mais ça ne sert à rien. Avec le système à quatre niveaux de Dusk, j’ai pour la première fois l’impression que la finalité peut être quantifiée et anticipée. De Accepted à Final, chaque niveau a des conditions mathématiques claires : ce n’est pas juste « attendre et voir » pour faire joli.
Aujourd’hui, ce vol a finalement décollé après quatre heures de retard. Si la finalité d’une blockchain devait fonctionner comme à l’aéroport, basée sur l’“attente”, qui oserait l’utiliser pour des paiements et des règlements financiers ? Dusk décompose le “non réversible” en quatre paliers, et chaque palier a des règles explicites : cette déterminisme, c’est justement ce dont la finance a besoin. #dusk $DUSK @Dusk
