Avant, je trouvais la confirmation par blocs très simple : la transaction entre dans un bloc, puis on compte quelques blocs supplémentaires, et on considère que c’est à peu près sûr. Mais ce soir, en lisant la documentation sur le cycle de vie de la transaction @Dusk , une phrase m’a bloqué : « accepted blocks can still be reverted ». Si c’est accepté, pourquoi peut-on encore l’annuler ?
En relisant le Whitepaper 2024, j’ai enfin compris. Le consensus de Dusk passe par plusieurs itérations au cours d’un même cycle, et il peut y avoir des blocs concurrents dans une même round. Un bloc issu d’une itération plus élevée peut, même s’il a déjà été accepté, être remplacé si un bloc concurrent d’itération plus faible satisfait aux conditions requises ; un fallback peut alors être déclenché. « Voir la mise en chaîne » ne signifie pas que c’est non remplaçable.
La « Rolling Finality » est encore plus contre-intuitive. Le livre blanc utilise n pour désigner le nombre d’itérations qui n’ont pas encore permis de déterminer la finalité des attestations. Pour qu’un bloc « accepted » devienne « confirmed », il doit ensuite être suivi par 2×n blocs consécutifs attestés ou confirmés. Par exemple, si n = 3, il faut observer les 6 blocs suivants qui remplissent les conditions.
C’est là que j’ai réalisé que « le nombre de confirmations » n’est pas une mesure universelle. À chaîne incluse, d’accord, mais l’historique du consensus peut être différent, et donc le niveau de stabilité aussi.
Les recommandations actuelles des Docs sont encore plus directes : ne pas considérer « included », « accepted » et même « confirmed » comme des signaux de règlement. Il faut attendre la vraie « finalized ».
Pour un petit transfert, quelques secondes peuvent suffire comme différence ; mais dans un règlement DvP d’un gros OTC ou d’un RWA, « voir la transaction » et « règlement irréversible » sont deux choses totalement différentes. À l’avenir, pour les grosses transactions sur Dusk, je ne demanderai qu’une chose : est-ce que c’est finalized ?
#dusk $DUSK @Dusk
En relisant le Whitepaper 2024, j’ai enfin compris. Le consensus de Dusk passe par plusieurs itérations au cours d’un même cycle, et il peut y avoir des blocs concurrents dans une même round. Un bloc issu d’une itération plus élevée peut, même s’il a déjà été accepté, être remplacé si un bloc concurrent d’itération plus faible satisfait aux conditions requises ; un fallback peut alors être déclenché. « Voir la mise en chaîne » ne signifie pas que c’est non remplaçable.
La « Rolling Finality » est encore plus contre-intuitive. Le livre blanc utilise n pour désigner le nombre d’itérations qui n’ont pas encore permis de déterminer la finalité des attestations. Pour qu’un bloc « accepted » devienne « confirmed », il doit ensuite être suivi par 2×n blocs consécutifs attestés ou confirmés. Par exemple, si n = 3, il faut observer les 6 blocs suivants qui remplissent les conditions.
C’est là que j’ai réalisé que « le nombre de confirmations » n’est pas une mesure universelle. À chaîne incluse, d’accord, mais l’historique du consensus peut être différent, et donc le niveau de stabilité aussi.
Les recommandations actuelles des Docs sont encore plus directes : ne pas considérer « included », « accepted » et même « confirmed » comme des signaux de règlement. Il faut attendre la vraie « finalized ».
Pour un petit transfert, quelques secondes peuvent suffire comme différence ; mais dans un règlement DvP d’un gros OTC ou d’un RWA, « voir la transaction » et « règlement irréversible » sont deux choses totalement différentes. À l’avenir, pour les grosses transactions sur Dusk, je ne demanderai qu’une chose : est-ce que c’est finalized ?
#dusk $DUSK @Dusk
