La lógica de finalización de Dusk es un poco especial. No es un concepto de tiempo en el sentido tradicional, sino un resultado directamente ligado a la prueba de transacciones.

Esta cadena utiliza el mecanismo de consenso de Atestación Sucinta (Succinct Attestation). Los requisitos principales son claros: los validadores deben confirmar las transferencias de estado que ya han sido verificadas mediante pruebas, en lugar de hacer un consenso general sobre un montón de "transacciones pendientes". En otras palabras, solo cuando la prueba adjunta a una transacción ha sido validada, esa transacción puede entrar en el proceso de confirmación final.

El nodo de consenso no confirma el hecho de que "alguien haya enviado una transacción", sino que "bajo las reglas actuales, esta transferencia de estado ha sido demostrada como legal". ¿Qué pasa si la prueba falla? Entonces, esa transacción ni siquiera entra en el rango de discusión final.

Muchas cadenas primero alcanzan consenso y luego detectan problemas. Dusk invierte ese orden: la prueba va primero, y la finalización solo se aplica a los estados que han sido demostrados como legales. La consecuencia directa es que los estados que violan las reglas no pueden ser confirmados repetidamente y luego revertidos, porque los estados ilegales simplemente no entran en la ruta de confirmación.

Por eso, Dusk puede considerar la finalización como un requisito fundamental para transacciones conformes, y no solo como un indicador de rendimiento. El objeto del mecanismo de confirmación es muy claro: solo para transferencias de estado que ya han sido demostradas como legales según las reglas, no para respaldar la solicitud de transacción en sí. La integridad del sistema de una cadena se juzga en base a esto: ¿la finalización solo actúa sobre estados que ya han sido demostrados como legales? Si este orden no se altera, el mecanismo de confirmación deja de ser un PoS genérico y se convierte en una garantía de ejecución diseñada a medida para un volumen de transacciones reguladas.