Pasé toda la noche discutiendo con alguien sobre si “la cadena de privacidad puede o no pasar la supervisión”, y esta mañana, al revisar el código, descubrí que Dusk ya había metido la respuesta.
¡Muy bien el plan! ¡BTC está subiendo muy bien!
Anoche me enredé hasta las dos con un amigo que trabaja en cumplimiento normativo. Él defendía con firmeza una idea: “La combinación de ZK y UTXO hace que las entidades de auditoría no puedan hacer su trabajo; la regulación no lo aceptará”. Yo le repliqué usando la divulgación selectiva de Phoenix. Él me soltó: “¿El código puede exportar Excel con un solo clic?” y colgó.
Me quedé atascado con esa frase durante un buen rato.
Pero esta mañana, al revisar la documentación, vi un detalle que antes no había prestado mucha atención: el mecanismo de View Key de Phoenix. La clave se divide en dos partes: una para ver y otra para gastar. La primera puede entregarse a un tercero para escanear e identificar tus transacciones; la segunda siempre la guardas tú. ¿Qué significa esto? La parte de auditoría puede obtener el View Key para verificar si hiciste alguna operación indebida o si realizaste transferencias en exceso, pero no puede tocar ni un solo centavo. La “verificabilidad” que necesita el cumplimiento y la “inalcanzabilidad” que requiere la seguridad de los activos se resuelven separando la clave en dos.
Lo de “exportar Excel con un solo clic” que mencionó mi amigo también es una necesidad real. La regulación no entra a discutir tus ideales criptográficos; lo que quieren es que puedas imprimir y archivar lo que corresponde. Lo interesante del diseño de Phoenix es que no trata “privacidad” y “auditoría” como si fueran opuestos. En medio coloca un puente con el View Key: lo que debe verse, se ve; lo que no se debe tomar, no se puede llevar. También vale la pena mencionar el mecanismo Nullifier: en cada transacción privada se publica un identificador de destrucción único, en vez de exponer directamente qué note fue gastada. La auditoría puede verificar que “esta transacción ocurrió y no hubo doble gasto”, pero no puede saber quién envió cuánto a quién.
Por supuesto, esta contabilidad no puede considerarse demasiado perfecta: una vez que delegas el View Key, el tercero puede ver tus registros de cobro. Eso ya es, por sí mismo, un costo de confianza. A quién se le muestra, cómo se guarda después y si puede filtrarse: el protocolo no puede controlar eso.
Pero al menos la dirección es correcta: la privacidad no tiene por qué estar necesariamente en contra de la supervisión. El problema nunca ha sido “si se puede cumplir o no”, sino “cuál es el precio del cumplimiento”. La respuesta que da Phoenix es: el precio puede ser una llave de solo lectura que no permite escribir, en lugar de dejar la cuenta totalmente expuesta.
@Dusk $DUSK #dusk
¡Muy bien el plan! ¡BTC está subiendo muy bien!
Anoche me enredé hasta las dos con un amigo que trabaja en cumplimiento normativo. Él defendía con firmeza una idea: “La combinación de ZK y UTXO hace que las entidades de auditoría no puedan hacer su trabajo; la regulación no lo aceptará”. Yo le repliqué usando la divulgación selectiva de Phoenix. Él me soltó: “¿El código puede exportar Excel con un solo clic?” y colgó.
Me quedé atascado con esa frase durante un buen rato.
Pero esta mañana, al revisar la documentación, vi un detalle que antes no había prestado mucha atención: el mecanismo de View Key de Phoenix. La clave se divide en dos partes: una para ver y otra para gastar. La primera puede entregarse a un tercero para escanear e identificar tus transacciones; la segunda siempre la guardas tú. ¿Qué significa esto? La parte de auditoría puede obtener el View Key para verificar si hiciste alguna operación indebida o si realizaste transferencias en exceso, pero no puede tocar ni un solo centavo. La “verificabilidad” que necesita el cumplimiento y la “inalcanzabilidad” que requiere la seguridad de los activos se resuelven separando la clave en dos.
Lo de “exportar Excel con un solo clic” que mencionó mi amigo también es una necesidad real. La regulación no entra a discutir tus ideales criptográficos; lo que quieren es que puedas imprimir y archivar lo que corresponde. Lo interesante del diseño de Phoenix es que no trata “privacidad” y “auditoría” como si fueran opuestos. En medio coloca un puente con el View Key: lo que debe verse, se ve; lo que no se debe tomar, no se puede llevar. También vale la pena mencionar el mecanismo Nullifier: en cada transacción privada se publica un identificador de destrucción único, en vez de exponer directamente qué note fue gastada. La auditoría puede verificar que “esta transacción ocurrió y no hubo doble gasto”, pero no puede saber quién envió cuánto a quién.
Por supuesto, esta contabilidad no puede considerarse demasiado perfecta: una vez que delegas el View Key, el tercero puede ver tus registros de cobro. Eso ya es, por sí mismo, un costo de confianza. A quién se le muestra, cómo se guarda después y si puede filtrarse: el protocolo no puede controlar eso.
Pero al menos la dirección es correcta: la privacidad no tiene por qué estar necesariamente en contra de la supervisión. El problema nunca ha sido “si se puede cumplir o no”, sino “cuál es el precio del cumplimiento”. La respuesta que da Phoenix es: el precio puede ser una llave de solo lectura que no permite escribir, en lugar de dejar la cuenta totalmente expuesta.
@Dusk $DUSK #dusk