Juntar las palabras “privacidad” y “cumplimiento” para construir un relato es relativamente fácil; lo verdaderamente espinoso es delimitar los límites de poder que hay detrás. Mucha gente habla de divulgación selectiva y se queda en la conclusión de “se puede mostrar los datos al regulador”, pero rara vez se pregunta algo más profundo: ¿quién tiene la autoridad para iniciar una solicitud de divulgación? ¿Quién emite las credenciales de divulgación y quién puede revocarlas? La parte que entrega el poder de decisión: ¿puede ver de forma clara y transparente qué información exactamente ha liberado?
#dusk ofrece dos modelos de transacciones, Moonlight y Phoenix, como base para la elección. El modo de cuenta de Moonlight lo publica todo de principio a fin, y se adapta a contratos y activos totalmente transparentes; Phoenix, en cambio, utiliza pruebas ZK para que las transacciones, por defecto, estén cifradas, de modo que el monto y el contrapartes no sean visibles hacia el exterior. Luego, un mecanismo de divulgación selectiva abre un canal de verificación dirigido.
El plano de la arquitectura es precioso, pero un plano no equivale a un sistema completo de responsabilidades y derechos. En la capa del protocolo solo se proporcionan herramientas criptográficas para la divulgación, sin definir de forma automática las reglas completas de autoridad en el mundo real. Si los límites de poder son ambiguos, esta serie de herramientas conlleva dos riesgos extremos: o el umbral para la verificación regulatoria es demasiado alto y la vía de cumplimiento se vuelve una formalidad vacía; o la autorización para divulgar se usa a discreción, y la llamada “privacidad” termina siendo una promesa sin sustento.
Me preocupan tres problemas prácticos. Primero: ¿el emisor de las credenciales es el propio usuario, una entidad de auditoría de terceros o un contrato en la cadena? Segundo: ¿la autorización de divulgación ya concedida puede revocarse completa y oportunamente en cualquier momento? Tercero: cada acto de divulgación, ¿deja un registro de auditoría trazable e inalterable, que facilite la rendición de cuentas a posteriori? Estos detalles, los libros blancos solo pueden ofrecer direcciones de diseño; la respuesta final debe venir de los datos con el sistema ejecutándose de verdad en la red principal.
Así que, en lugar de sentenciar ahora que este sistema es perfectamente viable, prefiero marcar varios indicadores de observación a largo plazo: la proporción real de transacciones privadas en la red, el flujo completo de revocación de las credenciales de divulgación y los registros de auditoría que corresponden a cada vez que se abre información al exterior.
La tecnología puede construir canales, pero las reglas que equilibran el poder aún requieren que los reguladores, los equipos de proyecto y todos los usuarios la ajusten y la consensuen en conjunto. Por ahora no voy a dar conclusiones de “optimismo” ni de “pesimismo”; solo sigo mirando: ¿podrá este sistema de privacidad‑cumplimiento, por encima del protocolo, establecer un mecanismo claro de balance de poder y que permita atribuir responsabilidades? @Dusk $DUSK
#dusk ofrece dos modelos de transacciones, Moonlight y Phoenix, como base para la elección. El modo de cuenta de Moonlight lo publica todo de principio a fin, y se adapta a contratos y activos totalmente transparentes; Phoenix, en cambio, utiliza pruebas ZK para que las transacciones, por defecto, estén cifradas, de modo que el monto y el contrapartes no sean visibles hacia el exterior. Luego, un mecanismo de divulgación selectiva abre un canal de verificación dirigido.
El plano de la arquitectura es precioso, pero un plano no equivale a un sistema completo de responsabilidades y derechos. En la capa del protocolo solo se proporcionan herramientas criptográficas para la divulgación, sin definir de forma automática las reglas completas de autoridad en el mundo real. Si los límites de poder son ambiguos, esta serie de herramientas conlleva dos riesgos extremos: o el umbral para la verificación regulatoria es demasiado alto y la vía de cumplimiento se vuelve una formalidad vacía; o la autorización para divulgar se usa a discreción, y la llamada “privacidad” termina siendo una promesa sin sustento.
Me preocupan tres problemas prácticos. Primero: ¿el emisor de las credenciales es el propio usuario, una entidad de auditoría de terceros o un contrato en la cadena? Segundo: ¿la autorización de divulgación ya concedida puede revocarse completa y oportunamente en cualquier momento? Tercero: cada acto de divulgación, ¿deja un registro de auditoría trazable e inalterable, que facilite la rendición de cuentas a posteriori? Estos detalles, los libros blancos solo pueden ofrecer direcciones de diseño; la respuesta final debe venir de los datos con el sistema ejecutándose de verdad en la red principal.
Así que, en lugar de sentenciar ahora que este sistema es perfectamente viable, prefiero marcar varios indicadores de observación a largo plazo: la proporción real de transacciones privadas en la red, el flujo completo de revocación de las credenciales de divulgación y los registros de auditoría que corresponden a cada vez que se abre información al exterior.
La tecnología puede construir canales, pero las reglas que equilibran el poder aún requieren que los reguladores, los equipos de proyecto y todos los usuarios la ajusten y la consensuen en conjunto. Por ahora no voy a dar conclusiones de “optimismo” ni de “pesimismo”; solo sigo mirando: ¿podrá este sistema de privacidad‑cumplimiento, por encima del protocolo, establecer un mecanismo claro de balance de poder y que permita atribuir responsabilidades? @Dusk $DUSK