Lo que captó mi atención es que el modelo de privacidad de Dusk puede dejar un evento de autorización visible mientras mantiene ocultos los datos de identidad que lo respaldan.
En Citadel 2, un usuario demuestra con conocimiento cero que posee una credencial registrada y firmada por el proveedor. El contrato verifica esa prueba y registra una sesión pública. Pero la documentación de Dusk indica que esa sesión no expone la clave de la wallet, la licencia específica utilizada, la clave del proveedor de la licencia, la clave del proveedor del servicio, los atributos firmados ni la ruta de la prueba de Merkle.
Esa es una elección de diseño más interesante que simplemente decir “KYC privado”.
Yo esperaba que la propia blockchain decidiera si un usuario cumple. No lo hace. Citadel demuestra que la credencial/sesión es válida criptográficamente; el proveedor de servicios sigue decidiendo qué emisores de credenciales confía, qué atributos cumplen su política, si una sesión está vencida o revocada, y si una cookie de sesión puede reutilizarse.
Para mí, esa separación es importante para aplicaciones financieras. La privacidad se gestiona mediante el sistema de pruebas, mientras que la política comercial y regulatoria se mantiene configurable en la capa de la aplicación en lugar de quedar congelada en una única regla universal.
Eso también crea un compromiso real: la flexibilidad es útil, pero la seguridad depende de que los proveedores de servicios definan esas políticas correctamente.
Para dusk_foundation y DUSK, la parte que estoy observando no es solo si las credenciales permanecen privadas, sino qué tan consistentemente las aplicaciones reales implementan la capa de políticas a su alrededor.
@Dusk $DUSK #dusk
En Citadel 2, un usuario demuestra con conocimiento cero que posee una credencial registrada y firmada por el proveedor. El contrato verifica esa prueba y registra una sesión pública. Pero la documentación de Dusk indica que esa sesión no expone la clave de la wallet, la licencia específica utilizada, la clave del proveedor de la licencia, la clave del proveedor del servicio, los atributos firmados ni la ruta de la prueba de Merkle.
Esa es una elección de diseño más interesante que simplemente decir “KYC privado”.
Yo esperaba que la propia blockchain decidiera si un usuario cumple. No lo hace. Citadel demuestra que la credencial/sesión es válida criptográficamente; el proveedor de servicios sigue decidiendo qué emisores de credenciales confía, qué atributos cumplen su política, si una sesión está vencida o revocada, y si una cookie de sesión puede reutilizarse.
Para mí, esa separación es importante para aplicaciones financieras. La privacidad se gestiona mediante el sistema de pruebas, mientras que la política comercial y regulatoria se mantiene configurable en la capa de la aplicación en lugar de quedar congelada en una única regla universal.
Eso también crea un compromiso real: la flexibilidad es útil, pero la seguridad depende de que los proveedores de servicios definan esas políticas correctamente.
Para dusk_foundation y DUSK, la parte que estoy observando no es solo si las credenciales permanecen privadas, sino qué tan consistentemente las aplicaciones reales implementan la capa de políticas a su alrededor.
@Dusk $DUSK #dusk
