La red se puso a cavar en "auditor access" porque suele ser la parte más vaga de cualquier discurso de privacidad-coin. Quería el mecanismo real, no la frase.
Dusk ejecuta dos modelos de transacción en paralelo: Moonlight (totalmente público, como un modelo de cuenta normal) y Phoenix (blindado, saldos/transferencias confidenciales). Eliges por transacción. Esa parte es sencilla.
Lo que no esperaba: la divulgación a un auditor no es "el auditor obtiene una master key para todo". Según el propio escrito de Dusk, el usuario cifra la carga útil de la transacción con una clave de usuario y luego cifra esa clave de usuario con la clave del auditor; así, solo el auditor específico puede desbloquearla. A continuación, una prueba de conocimiento cero confirma que la clave del auditor se usó correctamente, sin revelar la carga útil a nadie que verifique la cadena.
Así que es una divulgación específica por transacción, basada en claves, y no un backdoor que esté sentado en todo el sistema. No existe clave de auditor = no hay acceso, punto y final, incluso para los validadores propios de la red.
La brecha que no pude cerrar del todo: la documentación describe esto en la capa de identidad de Citadel, pero no encontré un caso público de que un regulador realmente tire de datos a través de este flujo en mainnet todavía. Está sólido en el papel, pero "el auditor descifra una transacción mediante cifrado demostrable" y "el flujo real de trabajo de un regulador durante una auditoría en vivo" son dos pruebas distintas.
¿Alguien ha visto que esto se active en un escenario de cumplimiento real, no solo documentado como una capacidad
#dusk $DUSK #dusk $DUSK
Dusk ejecuta dos modelos de transacción en paralelo: Moonlight (totalmente público, como un modelo de cuenta normal) y Phoenix (blindado, saldos/transferencias confidenciales). Eliges por transacción. Esa parte es sencilla.
Lo que no esperaba: la divulgación a un auditor no es "el auditor obtiene una master key para todo". Según el propio escrito de Dusk, el usuario cifra la carga útil de la transacción con una clave de usuario y luego cifra esa clave de usuario con la clave del auditor; así, solo el auditor específico puede desbloquearla. A continuación, una prueba de conocimiento cero confirma que la clave del auditor se usó correctamente, sin revelar la carga útil a nadie que verifique la cadena.
Así que es una divulgación específica por transacción, basada en claves, y no un backdoor que esté sentado en todo el sistema. No existe clave de auditor = no hay acceso, punto y final, incluso para los validadores propios de la red.
La brecha que no pude cerrar del todo: la documentación describe esto en la capa de identidad de Citadel, pero no encontré un caso público de que un regulador realmente tire de datos a través de este flujo en mainnet todavía. Está sólido en el papel, pero "el auditor descifra una transacción mediante cifrado demostrable" y "el flujo real de trabajo de un regulador durante una auditoría en vivo" son dos pruebas distintas.
¿Alguien ha visto que esto se active en un escenario de cumplimiento real, no solo documentado como una capacidad
#dusk $DUSK #dusk $DUSK