El nivel de privacidad que no esperaba en Dusk no se trata de ocultar saldos. Se trata de lo que ocurre después de que una prueba de identidad de conocimiento cero (zero-knowledge) se realiza con éxito.
El borrador de especificación de Citadel 2 para mayo de 2026 usa un "session_id" en la cadena como un nulo (nullifier). Para la misma licencia oculta y el mismo desafío aceptado, el contrato puede rechazar una sesión duplicada. Eso suena como protección contra replays al principio.
Pero la especificación traza una frontera más precisa: el nullifier detiene la creación de sesiones duplicadas en cadena; no detiene que alguien reutilice la misma cookie de sesión divulgada fuera de la cadena.
Eso me hizo mirar dos veces.
En Citadel, la cadena verifica la validez criptográfica y registra la sesión. El Proveedor de Servicio todavía tiene que hacer cumplir sus propias reglas contra replays, la confianza del emisor, la revocación, la caducidad, el enlace a la cuenta y los límites de tasa.
Creo que esa separación es más interesante que un simple eslogan de "privacidad + cumplimiento". Evita que el protocolo base codifique la política de acceso de cada institución, a la vez que empuja la responsabilidad real de la autorización a la capa de aplicación.
El compromiso es evidente: los creadores no pueden tratar una "prueba ZK válida" como equivalente a una "credencial de acceso reutilizable y segura".
Para @Dusk and $DUSK , yo observaría cómo los perfiles de Citadel en producción estandarizan el uso único, el enlace y la revocación sin debilitar la privacidad. ¿Qué decisiones de política se vuelven valores predeterminados —y cuáles se mantienen específicas de la aplicación? #dusk
#dusk $DUSK @Dusk
El borrador de especificación de Citadel 2 para mayo de 2026 usa un "session_id" en la cadena como un nulo (nullifier). Para la misma licencia oculta y el mismo desafío aceptado, el contrato puede rechazar una sesión duplicada. Eso suena como protección contra replays al principio.
Pero la especificación traza una frontera más precisa: el nullifier detiene la creación de sesiones duplicadas en cadena; no detiene que alguien reutilice la misma cookie de sesión divulgada fuera de la cadena.
Eso me hizo mirar dos veces.
En Citadel, la cadena verifica la validez criptográfica y registra la sesión. El Proveedor de Servicio todavía tiene que hacer cumplir sus propias reglas contra replays, la confianza del emisor, la revocación, la caducidad, el enlace a la cuenta y los límites de tasa.
Creo que esa separación es más interesante que un simple eslogan de "privacidad + cumplimiento". Evita que el protocolo base codifique la política de acceso de cada institución, a la vez que empuja la responsabilidad real de la autorización a la capa de aplicación.
El compromiso es evidente: los creadores no pueden tratar una "prueba ZK válida" como equivalente a una "credencial de acceso reutilizable y segura".
Para @Dusk and $DUSK , yo observaría cómo los perfiles de Citadel en producción estandarizan el uso único, el enlace y la revocación sin debilitar la privacidad. ¿Qué decisiones de política se vuelven valores predeterminados —y cuáles se mantienen específicas de la aplicación? #dusk
#dusk $DUSK @Dusk