En el sistema de Dusk, la posibilidad de que se produzcan transacciones no depende de una "revisión posterior", sino de si se puede generar una prueba válida en el momento en que se inicia la transacción. Este es el punto más crucial que diferencia a Dusk de la mayoría de las cadenas públicas.
En muchas cadenas, la verificación de reglas ocurre después de la ejecución: la transacción se escribe en el estado y luego se corrige a través de gobernanza, arbitraje o intervención manual. Pero Dusk invierte completamente ese orden. Antes de que una transacción ingrese a la fase de ejecución, debe demostrar que cumple con las reglas establecidas, que pueden provenir del propio activo o de módulos de cuenta o de cumplimiento. Si la prueba no se establece, la transacción no puede entrar en la transferencia de estado.
Esto significa que la ruta de transacción de Dusk no es simplemente "iniciar - ejecutar - liquidar", sino que tiene una capa adicional de restricción estricta: las reglas se expresan como condiciones demostrables. Por ejemplo, si un activo todavía está en período de bloqueo, si una cuenta cumple con los requisitos de tenencia, si una transferencia en particular activa restricciones, estas no se evaluarán después de la ejecución, sino que se consideran parte de las restricciones de prueba desde el principio.
Este punto es muy crítico para los activos regulados. Porque lo que le preocupa al regulador no es "si puedes explicar después", sino "si el sistema permite que se escriba un estado de incumplimiento". La práctica de Dusk es bloquear el estado de incumplimiento desde el nivel del sistema, en lugar de depender de la gobernanza posterior. Esta es también la razón por la cual el diseño de reglas de Dusk debe ser combinable y actualizable: una vez que las reglas cambian, nuevas restricciones de prueba deben poder ser introducidas sin comprometer la verificabilidad del estado histórico.
Para los desarrolladores, el impacto directo de este diseño es que la lógica del contrato ya no solo se ocupa de los negocios, sino que necesita dejar en claro qué reglas deben expresarse como condiciones de prueba. Si las reglas no están claras, no se puede generar la prueba; si no se puede generar la prueba, la transacción no se puede ejecutar. Esto elevará el umbral para los desarrolladores, pero también convierte el "cumplimiento" de un eslogan en una restricción estricta.
Por lo tanto, ahora que observo el progreso de @dusk_foundation, me concentro en una sola cosa: si las reglas realmente están vinculadas a la prueba y siempre están por delante de la ejecución de la transacción. Mientras este camino no se haya eludido, Dusk realmente tendrá la capacidad de manejar activos complejos y regulados.
