#dusk $DUSK @Dusk Esta semana me leí a fondo el paper de Dusk sobre el modelo de transacciones de Phoenix (el de Citadel tiene una sección dedicada a Phoenix). Antes pensaba que no era muy diferente, en lo esencial, de otros esquemas de privacidad basados en UTXO; al terminar de leerlo, descubrí que el diseño detallado es mucho más elaborado de lo que imaginaba.
En Phoenix, cada “activo” de una transacción no se llama UTXO, sino note (nota). La red no almacena directamente las notes, sino que guarda el hash de cada note en las hojas de un árbol Merkle. Cuando quieres gastar una note, el usuario debe presentar una prueba de conocimiento cero llamada tx_proof. Esta prueba hace dos cosas a la vez: primero, “anula” la note que se va a gastar (genera un nullifier único para evitar que el mismo dinero se gaste dos veces); segundo, demuestra que el monto total de las nuevas notes generadas coincide con el de las notes anuladas, y que no se ha creado dinero de la nada. Desde el exterior, lo único visible es: “una note antigua es anulada” y “se crea una note nueva”; los montos concretos y las partes involucradas no son visibles.
Lo que de verdad me parece especialmente ingenioso del diseño es la división de claves: para gastar una note necesitas una Secret Key, que solo conoce el dueño de la note; pero si lo único que quieres es que un auditor o un regulador vea qué notes tienes y cuál es el monto cifrado dentro, no necesitas entregar la clave que permite gastar el dinero. En su lugar, puedes compartir por separado una View Key. Es decir, “ver” y “poder gastar” son dos claves totalmente independientes: esta separación en sí misma sirve como base criptográfica para la implementación de “divulgación selectiva”, y no es solo un eslogan de marketing.
Además, el contrato Transfer tiene un detalle fácil de pasar por alto: combina (combine) de manera activa varias notes pequeñas en lugar de una por una, evitando que las hojas del árbol Merkle crezcan sin límite y arrastren el rendimiento de la red. Este diseño de “el libro mayor en el nivel de base de datos hace su propio garbage collection” muestra que el equipo ya, en las fases tempranas, anticipó el coste de ejecución a largo plazo para almacenamiento y pruebas, en vez de esperar a que el árbol creciera hasta volverse intratable para recién remediarlo.
Para desarrolladores, este mecanismo implica que si quieres construir una aplicación sobre Phoenix, la distribución y gestión de la View Key será un problema de diseño de producto que no puedes evitar: determina quién puede ver la posición del usuario bajo qué condiciones. Si esa parte no se diseña bien, la palabra “privacidad” se vuelve solo un interruptor en la interfaz de la wallet, sin efecto real ni restricciones concretas.
En Phoenix, cada “activo” de una transacción no se llama UTXO, sino note (nota). La red no almacena directamente las notes, sino que guarda el hash de cada note en las hojas de un árbol Merkle. Cuando quieres gastar una note, el usuario debe presentar una prueba de conocimiento cero llamada tx_proof. Esta prueba hace dos cosas a la vez: primero, “anula” la note que se va a gastar (genera un nullifier único para evitar que el mismo dinero se gaste dos veces); segundo, demuestra que el monto total de las nuevas notes generadas coincide con el de las notes anuladas, y que no se ha creado dinero de la nada. Desde el exterior, lo único visible es: “una note antigua es anulada” y “se crea una note nueva”; los montos concretos y las partes involucradas no son visibles.
Lo que de verdad me parece especialmente ingenioso del diseño es la división de claves: para gastar una note necesitas una Secret Key, que solo conoce el dueño de la note; pero si lo único que quieres es que un auditor o un regulador vea qué notes tienes y cuál es el monto cifrado dentro, no necesitas entregar la clave que permite gastar el dinero. En su lugar, puedes compartir por separado una View Key. Es decir, “ver” y “poder gastar” son dos claves totalmente independientes: esta separación en sí misma sirve como base criptográfica para la implementación de “divulgación selectiva”, y no es solo un eslogan de marketing.
Además, el contrato Transfer tiene un detalle fácil de pasar por alto: combina (combine) de manera activa varias notes pequeñas en lugar de una por una, evitando que las hojas del árbol Merkle crezcan sin límite y arrastren el rendimiento de la red. Este diseño de “el libro mayor en el nivel de base de datos hace su propio garbage collection” muestra que el equipo ya, en las fases tempranas, anticipó el coste de ejecución a largo plazo para almacenamiento y pruebas, en vez de esperar a que el árbol creciera hasta volverse intratable para recién remediarlo.
Para desarrolladores, este mecanismo implica que si quieres construir una aplicación sobre Phoenix, la distribución y gestión de la View Key será un problema de diseño de producto que no puedes evitar: determina quién puede ver la posición del usuario bajo qué condiciones. Si esa parte no se diseña bien, la palabra “privacidad” se vuelve solo un interruptor en la interfaz de la wallet, sin efecto real ni restricciones concretas.