La logique de finalité de Dusk est un peu particulière. Ce n’est pas une notion de temps traditionnelle, mais un résultat directement lié à la preuve de transaction.

Cette chaîne utilise le mécanisme de consensus Succinct Attestation. L’exigence principale est claire : les validateurs doivent confirmer les transitions d’état déjà vérifiées par preuve, plutôt que de faire un consensus général sur une pile de "transactions en attente". En d’autres termes, une transaction ne peut entrer dans le processus de finalité que si la preuve qui l’accompagne est validée.

Ce que les nœuds de consensus confirment, ce n’est pas "quelqu’un a soumis une transaction", mais "dans les règles actuelles, cette transition d’état a été prouvée légitime". Si la validation de la preuve échoue ? La transaction ne pourra pas du tout entrer dans le champ de discussion de la finalité.

Beaucoup de chaînes suivent un ordre où la consensus précède la détection de problème. Dusk inverse cette logique — la preuve est préalable, la finalité ne s’applique qu’aux états déjà prouvés légitimes. La conséquence directe est que les états en violation ne peuvent pas être confirmés puis annulés à répétition, car un état illégal ne peut pas entrer dans le chemin de confirmation.

C’est pourquoi Dusk peut considérer la finalité comme une condition de conformité pour les transactions, et pas seulement comme un indicateur de performance. L’objet du mécanisme de confirmation est très clair — il ne concerne que les transitions d’état déjà prouvées conformes aux règles, et non la validation des requêtes de transaction elles-mêmes. La clé pour évaluer l’intégrité d’une chaîne réside dans ce point : la finalité ne doit s’appliquer qu’aux états légitimes déjà prouvés. Si cet ordre n’est pas respecté, le mécanisme de confirmation ne devient pas un PoS universel, mais une garantie d’exécution sur mesure pour un volume de transactions réglementé.