Recientemente leí otra vez, cotejando, el modelo de transacciones Phoenix de @Dusk y las explicaciones oficiales sobre selective disclosure.
La intención de diseño de Dusk aquí es bastante clara: Phoenix usa pruebas de conocimiento cero para ocultar el monto, el remitente y el destinatario, pero deja abierta la vía de un Viewing Key, para que los usuarios puedan revelar información de forma selectiva cuando la regulación o la auditoría lo requieran. La documentación oficial de Dusk y los tuits recientes recalcan una y otra vez: la privacidad es por defecto y la divulgación es bajo demanda. Para los mercados financieros regulados, esto es prácticamente imprescindible.
Pero un problema con el que empiezo a preocuparme es: ¿hasta qué punto se ha publicado actualmente la gobernanza de permisos de esta vía? No tanto si #dusk tiene o no esa ruta tecnológica.
Al fin y al cabo, el Viewing Key en sí mismo es solo una herramienta criptográfica. Lo que realmente determina la base de confianza del sistema de Dusk es:
➤ ❶ Quién tiene el derecho de ser asignado con permisos de visualización a largo o corto plazo.
➤ ❷ El proceso de concesión: ¿es unilateral, con múltiples firmas, o existen reglas claras de jurisdicción y de revocación?
➤ ❸ Si la propia acción de visualización deja trazas auditables.
➤ ❹ Si la identidad de la entidad a la que corresponde la clave cambia o si es sancionada, cómo se invalidan los permisos ya otorgados.
Y lo que yo vi en la documentación pública existente de $DUSK es, en su mayor parte, descripciones de capacidades como “soportar selective disclosure”. Normas más tempranas mencionaron roles View Only y claves de visualización multiusuario, pero eso estaba definido a nivel de contratos. Está todavía a cierta distancia de cómo se gestionan y restringen de forma real los derechos de acceso regulatorio una vez que los activos regulados se pongan en producción en Dusk.
De verdad que no es por quisquillosidad. Para las instituciones, la privacidad matemática es importante, pero al final lo que tienen que evaluar es: ¿quién controla en Dusk la llave que puede abrir parte de la privacidad, y cómo se le pone freno y contrapeso? Si estas reglas permanecen durante mucho tiempo en formulaciones de alto nivel, la narrativa de “privacidad conforme y auditables en Dusk” dejará un hueco real de confianza.
No estoy negando esta ruta. El mercado regulado sí necesita la capacidad de Dusk de “privacidad por defecto + divulgación bajo demanda”. Pero antes de que haya realmente activos a gran escala ejecutándose en Dusk, prefiero ver primero los detalles públicos de la propia gobernanza de permisos.
Cuando estas reglas se divulguen con más especificidad y puedan observarse en flujos de trabajo reales, entonces volveré a valorar si el sistema de control de acceso de Dusk ya alcanza un nivel de confianza apto para instituciones.
La intención de diseño de Dusk aquí es bastante clara: Phoenix usa pruebas de conocimiento cero para ocultar el monto, el remitente y el destinatario, pero deja abierta la vía de un Viewing Key, para que los usuarios puedan revelar información de forma selectiva cuando la regulación o la auditoría lo requieran. La documentación oficial de Dusk y los tuits recientes recalcan una y otra vez: la privacidad es por defecto y la divulgación es bajo demanda. Para los mercados financieros regulados, esto es prácticamente imprescindible.
Pero un problema con el que empiezo a preocuparme es: ¿hasta qué punto se ha publicado actualmente la gobernanza de permisos de esta vía? No tanto si #dusk tiene o no esa ruta tecnológica.
Al fin y al cabo, el Viewing Key en sí mismo es solo una herramienta criptográfica. Lo que realmente determina la base de confianza del sistema de Dusk es:
➤ ❶ Quién tiene el derecho de ser asignado con permisos de visualización a largo o corto plazo.
➤ ❷ El proceso de concesión: ¿es unilateral, con múltiples firmas, o existen reglas claras de jurisdicción y de revocación?
➤ ❸ Si la propia acción de visualización deja trazas auditables.
➤ ❹ Si la identidad de la entidad a la que corresponde la clave cambia o si es sancionada, cómo se invalidan los permisos ya otorgados.
Y lo que yo vi en la documentación pública existente de $DUSK es, en su mayor parte, descripciones de capacidades como “soportar selective disclosure”. Normas más tempranas mencionaron roles View Only y claves de visualización multiusuario, pero eso estaba definido a nivel de contratos. Está todavía a cierta distancia de cómo se gestionan y restringen de forma real los derechos de acceso regulatorio una vez que los activos regulados se pongan en producción en Dusk.
De verdad que no es por quisquillosidad. Para las instituciones, la privacidad matemática es importante, pero al final lo que tienen que evaluar es: ¿quién controla en Dusk la llave que puede abrir parte de la privacidad, y cómo se le pone freno y contrapeso? Si estas reglas permanecen durante mucho tiempo en formulaciones de alto nivel, la narrativa de “privacidad conforme y auditables en Dusk” dejará un hueco real de confianza.
No estoy negando esta ruta. El mercado regulado sí necesita la capacidad de Dusk de “privacidad por defecto + divulgación bajo demanda”. Pero antes de que haya realmente activos a gran escala ejecutándose en Dusk, prefiero ver primero los detalles públicos de la propia gobernanza de permisos.
Cuando estas reglas se divulguen con más especificidad y puedan observarse en flujos de trabajo reales, entonces volveré a valorar si el sistema de control de acceso de Dusk ya alcanza un nivel de confianza apto para instituciones.
