En el proceso de transacciones de Dusk, hay un aspecto muy crítico, pero a menudo pasado por alto: cómo maneja el sistema una transacción cuando la generación de prueba falla o la verificación no pasa. Esto no es un problema marginal, sino uno de los mecanismos centrales que determinan si Dusk realmente puede aceptar activos regulados.
En Dusk, una transacción fallida no es "ejecutada a medias y luego revertida", sino que es bloqueada antes de que se produzca la transferencia de estado. Cuando un usuario o un contrato inicia una transacción, el sistema requiere primero generar una prueba, para demostrar que esta transacción cumple con todas las restricciones actuales. Mientras la prueba no se pueda generar, o la prueba generada no pase la verificación en la cadena, esta transacción no entrará en la fase de ejecución y no cambiará ningún estado.
El punto clave aquí es: el fracaso en sí tiene estructura. La prueba fallida no es un "inválido" vago, sino que corresponde a la insatisfacción de condiciones específicas. Por ejemplo, un activo aún está en período de bloqueo, una cuenta no tiene la elegibilidad actual para poseer el activo, o una regla ha sido explícitamente prohibida tras una actualización. Estos fracasos no son aleatorios, sino que corresponden uno a uno con reglas específicas.
¿Por qué es esto especialmente importante en Dusk? Porque en un sistema de activos regulados, "la transacción es rechazada" en sí misma es un comportamiento que necesita ser explicado y auditado. El sistema debe poder responder: ¿por qué fue rechazada esta transacción, qué regla se activó, y en qué momento ocurrió el rechazo? Si la transacción simplemente falla sin un mapeo claro de reglas, la auditoría de cumplimiento posterior será casi imposible.
Lo que Dusk hace es incluir el "fracaso" en el proceso verificable. Aunque las transacciones fallidas no cambiarán el estado de activos o cuentas, la razón por la cual ocurrió el fracaso debe ser recuperable a nivel de reglas. Esto significa que la expresión de las reglas debe ser lo suficientemente clara, y las restricciones de prueba deben ser lo suficientemente detalladas, de lo contrario, tanto los desarrolladores como los usuarios no podrán distinguir entre un error lógico, un conflicto de reglas o una limitación de cumplimiento que se activó.
Este diseño obliga a que todas las reglas se conviertan en condiciones "que pueden ser probadas y también pueden ser refutadas". Si las reglas están escritas de manera vaga, la prueba no podrá generarse de manera estable; si la prueba es inestable, el camino de la transacción se interrumpirá con frecuencia.
#Dusk $DUSK
