#dusk $DUSK @Dusk Llevé casi cuarenta minutos mirando el documento de Dusk y dándole vueltas a una pregunta: ¿cómo se resuelve realmente el flujo de Moonlight y Phoenix?
Moonlight sigue la ruta de cuentas públicas. El saldo, el remitente y el destinatario de las transferencias, y el importe, todo está escrito en la cadena; cualquiera lo puede ver. Esto encaja bien en escenarios como recargas de exchange o conciliaciones institucionales donde se necesita transparencia. Phoenix, en cambio, responde a otra lógica: los activos se convierten en un note cifrado, escondido dentro de un árbol de Merkle. Cuando gastas un dinero, no se expone cuál note exacta es; en lugar de eso, envías un nullifier y una prueba ZKP. La red puede verificar que tienes fondos y que no hay doble gasto, pero no ve el importe ni el remitente. Cuando necesitas auditoría, puedes hacer divulgación selectiva mediante una viewing key.
A principios de mes, cuando escribí una nota sobre transferencias SEPA, me topé con un problema parecido: entre dos sistemas bancarios diferentes, la conciliación se vuelve un dolor de cabeza cuando los estados no coinciden; aquella vez me estuvieron dando guerra hasta las dos de la madrugada. Si la blockchain también se inventara dos libros contables aislados, entonces mejor sería la banca tradicional.
En ese momento estaba un poco molesto y sentía que en el documento no se explicaba este punto con suficiente claridad. Me fui a la sección de arquitectura de contratos del módulo Rusk; las dos primeras partes no me dijeron mucho, solo describían las estructuras de datos de Moonlight y Phoenix por separado. Hasta que llegué a la cuarta sección y vi que en la definición de la interfaz de Transfer Contract se usaba un tipo enum para el payload; ahí fue cuando entendí la intención de su diseño.
Transfer Contract es un punto de coordinación. Recibe payloads en distintos formatos: algunos en formato Moonlight, otros en formato Phoenix. El contrato no le importa de dónde viene, solo qué campos trae el payload; después lo enruta a la lógica de verificación correspondiente. La verificación de Moonlight lee directamente el estado de la cuenta pública; la de Phoenix ejecuta la prueba ZK. Cuando ambas verificaciones se completan, los resultados se escriben en el mismo árbol global de estado. Tardé un buen rato en darme cuenta de la clave de este paso: si combinas los árboles de estado de los dos sistemas en uno solo, entonces pasar un dinero desde la cuenta pública hasta un note de privacidad, en esencia, es solo una conversión de payload; no necesitas un puente entre cadenas ni protocolos complejos de sincronización. La actualización del estado es atómica: o funciona todo o se revierte todo.
Moonlight sigue la ruta de cuentas públicas. El saldo, el remitente y el destinatario de las transferencias, y el importe, todo está escrito en la cadena; cualquiera lo puede ver. Esto encaja bien en escenarios como recargas de exchange o conciliaciones institucionales donde se necesita transparencia. Phoenix, en cambio, responde a otra lógica: los activos se convierten en un note cifrado, escondido dentro de un árbol de Merkle. Cuando gastas un dinero, no se expone cuál note exacta es; en lugar de eso, envías un nullifier y una prueba ZKP. La red puede verificar que tienes fondos y que no hay doble gasto, pero no ve el importe ni el remitente. Cuando necesitas auditoría, puedes hacer divulgación selectiva mediante una viewing key.
A principios de mes, cuando escribí una nota sobre transferencias SEPA, me topé con un problema parecido: entre dos sistemas bancarios diferentes, la conciliación se vuelve un dolor de cabeza cuando los estados no coinciden; aquella vez me estuvieron dando guerra hasta las dos de la madrugada. Si la blockchain también se inventara dos libros contables aislados, entonces mejor sería la banca tradicional.
En ese momento estaba un poco molesto y sentía que en el documento no se explicaba este punto con suficiente claridad. Me fui a la sección de arquitectura de contratos del módulo Rusk; las dos primeras partes no me dijeron mucho, solo describían las estructuras de datos de Moonlight y Phoenix por separado. Hasta que llegué a la cuarta sección y vi que en la definición de la interfaz de Transfer Contract se usaba un tipo enum para el payload; ahí fue cuando entendí la intención de su diseño.
Transfer Contract es un punto de coordinación. Recibe payloads en distintos formatos: algunos en formato Moonlight, otros en formato Phoenix. El contrato no le importa de dónde viene, solo qué campos trae el payload; después lo enruta a la lógica de verificación correspondiente. La verificación de Moonlight lee directamente el estado de la cuenta pública; la de Phoenix ejecuta la prueba ZK. Cuando ambas verificaciones se completan, los resultados se escriben en el mismo árbol global de estado. Tardé un buen rato en darme cuenta de la clave de este paso: si combinas los árboles de estado de los dos sistemas en uno solo, entonces pasar un dinero desde la cuenta pública hasta un note de privacidad, en esencia, es solo una conversión de payload; no necesitas un puente entre cadenas ni protocolos complejos de sincronización. La actualización del estado es atómica: o funciona todo o se revierte todo.
