Hoy hagamos primero un experimento de arquitectura: para una misma transferencia de valores, hay que comprobar la elegibilidad del inversor, completar la entrega de activos y, al mismo tiempo, no podemos difundir la identidad, el saldo y las condiciones de la operación a todo el mundo. Si la privacidad es solo una función añadida por una aplicación concreta, las demás aplicaciones no necesariamente reconocen el mismo conjunto de pruebas, y las reglas de cumplimiento también pueden quedar escritas de forma distinta según cada una.
Lo más complicado es que, cuando el mismo activo se transfiere entre distintos contratos, la elegibilidad que probó la aplicación anterior quizá no pueda reutilizarse directamente por la aplicación siguiente; al final, hay que depender de una capa intermedia adicional para reinterpretarlo de nuevo.
En lo que respecta a Dusk, el punto que más me interesa es precisamente este: no separa la privacidad metiéndola solo en una wallet o en un mezclador de monedas, sino que la descompone en distintos componentes de L1. La documentación oficial define DuskDS como la capa de liquidación responsable del consenso, la finalidad y la disponibilidad de datos; Moonlight gestiona cuentas transparentes y Phoenix gestiona transferencias shielded (con confidencialidad). Ambas pueden transferir DUSK, pagar gas y actuar como punto de entrada para la ejecución de contratos.
Pero Dusk tampoco obliga a meter todos los activos en un único modo de privacidad. DuskVM ejecuta directamente contratos Rust/WASM en L1, lo que resulta adecuado para aplicaciones que necesitan activos nativos, privacidad o capacidades de conocimiento cero. DuskEVM, en cambio, ofrece un entorno compatible con OP Stack para EVM, y utiliza DuskDS para la liquidación y la disponibilidad de datos.
Esta es una decisión de diseño: cuanto más cerca esté la regla de privacidad de la capa de transformación del estado, más fácil será mantener la coherencia entre aplicaciones, pero también aumentará la complejidad del protocolo y el coste de verificación. Los nodos no solo deben procesar firmas normales, sino también verificar pruebas, actualizar estados ocultos y garantizar que distintas aplicaciones no se salten el mismo conjunto de reglas de activos. En otras palabras, la capa base no es simplemente un “interruptor de privacidad”, sino un conjunto de restricciones que se ejecutan continuamente.
@Dusk $DUSK #dusk
Por eso, conviene entender la ruta de Dusk así: los invariantes de privacidad los mantiene la infraestructura, y el alcance concreto se deja al control de las capas de aplicación y de identidad. En la web oficial se recalca confidential by default, las pruebas de conocimiento cero y la controlled visibility; el whitepaper, por su parte, diseña conjuntamente cuentas transparentes y UTXO de privacidad. Esto es mucho más preciso que decir simplemente “privacidad en la cadena”.
Lo más complicado es que, cuando el mismo activo se transfiere entre distintos contratos, la elegibilidad que probó la aplicación anterior quizá no pueda reutilizarse directamente por la aplicación siguiente; al final, hay que depender de una capa intermedia adicional para reinterpretarlo de nuevo.
En lo que respecta a Dusk, el punto que más me interesa es precisamente este: no separa la privacidad metiéndola solo en una wallet o en un mezclador de monedas, sino que la descompone en distintos componentes de L1. La documentación oficial define DuskDS como la capa de liquidación responsable del consenso, la finalidad y la disponibilidad de datos; Moonlight gestiona cuentas transparentes y Phoenix gestiona transferencias shielded (con confidencialidad). Ambas pueden transferir DUSK, pagar gas y actuar como punto de entrada para la ejecución de contratos.
Pero Dusk tampoco obliga a meter todos los activos en un único modo de privacidad. DuskVM ejecuta directamente contratos Rust/WASM en L1, lo que resulta adecuado para aplicaciones que necesitan activos nativos, privacidad o capacidades de conocimiento cero. DuskEVM, en cambio, ofrece un entorno compatible con OP Stack para EVM, y utiliza DuskDS para la liquidación y la disponibilidad de datos.
Esta es una decisión de diseño: cuanto más cerca esté la regla de privacidad de la capa de transformación del estado, más fácil será mantener la coherencia entre aplicaciones, pero también aumentará la complejidad del protocolo y el coste de verificación. Los nodos no solo deben procesar firmas normales, sino también verificar pruebas, actualizar estados ocultos y garantizar que distintas aplicaciones no se salten el mismo conjunto de reglas de activos. En otras palabras, la capa base no es simplemente un “interruptor de privacidad”, sino un conjunto de restricciones que se ejecutan continuamente.
@Dusk $DUSK #dusk
Por eso, conviene entender la ruta de Dusk así: los invariantes de privacidad los mantiene la infraestructura, y el alcance concreto se deja al control de las capas de aplicación y de identidad. En la web oficial se recalca confidential by default, las pruebas de conocimiento cero y la controlled visibility; el whitepaper, por su parte, diseña conjuntamente cuentas transparentes y UTXO de privacidad. Esto es mucho más preciso que decir simplemente “privacidad en la cadena”.