Dicho sin rodeos: el flujo de contratos WASM de Dusk, lo abrí en Chrome con el editor, conecté la wallet y le di a compilar; no instalé dependencias locales en absoluto. La experiencia, de verdad, es bastante fluida. El macro #[contract] se encarga de exportar y serializar por completo, y esa capa puente de Contract Drivers también me ahorró bastante trabajo de consultar ABI. Si solo vas a ejecutar las transferencias públicas de Moonlight, de cero a subir a producción, quizá sea más rápido que prepararte una taza de café de goteo.
La gran noticia es que el FOMO vuelve a dispararse; el BTC sigue muy fuerte
Pero lo que de verdad me sentó a pensar durante media hora fue cuando depuré el hecho de meter una transferencia de Phoenix blindada en la lógica de consulta de Moonlight.
El juego de Dusk se basa en dos “piernas”: Moonlight es un libro contable transparente, y el saldo se actualiza directamente en la cuenta; Phoenix es un UTXO con una capa de direcciones invisibles, y el saldo queda oculto en el note. El traspaso de fondos entre ambas cosas depende del Transfer Contract como intérprete: transferir blindado a público, primero se descuenta el saldo y luego se acuña el note; transferir público a blindado, primero se quema el note y luego se incrementa el saldo. ¿Suena lógico, verdad? Pero en cuanto escribes una interfaz de consulta y quieres mostrar en una sola vista la suma de saldos de ambos lados, tienes que manejar a la vez dos grupos de datos con formatos totalmente distintos: el estado de la cuenta y el cifrado del note. El primer impulso de los nuevos en mi equipo fue sumar directamente el value del note como si fuera el saldo: la transacción, al emitirse, quedó inutilizable, porque en Phoenix el note necesita que se verifiquen pruebas de propiedad antes de poder descifrar el valor; eso no coincide en absoluto con el momento/tiempo de lectura del saldo de Moonlight.
En cuanto a Gas, ni hablar: es una trampa “invisible”. En las transacciones públicas estimas con la lógica habitual y casi siempre aciertas; pero las transacciones blindadas requieren generar y verificar pruebas ZK, y la complejidad del circuito de la prueba se engancha directamente con la cantidad de notes y las condiciones del propio intercambio. Probé una transferencia Phoenix con 2 inputs note y 3 outputs note: el consumo de Gas fue casi dos órdenes de magnitud mayor que el de una transacción pública del mismo nivel. Las constantes de Gas que aparecen en la documentación solo te sirven como referencia de precio base; antes de lanzarlo de verdad, si no corres varias simulaciones en la testnet con parámetros reales, de verdad no te atreves a rellenar el límite de Gas: si pones menos, la transacción revierte; si pones más, solo quemas dinero sin más.
Lo que no termino de entender es que, en el tutorial oficial de Dusk, para ese tipo de escenarios “de borde” de “consulta híbrida + llamadas entre modelos”, la explicación de los límites es bastante escasa. @Dusk $DUSK #dusk
La gran noticia es que el FOMO vuelve a dispararse; el BTC sigue muy fuerte
Pero lo que de verdad me sentó a pensar durante media hora fue cuando depuré el hecho de meter una transferencia de Phoenix blindada en la lógica de consulta de Moonlight.
El juego de Dusk se basa en dos “piernas”: Moonlight es un libro contable transparente, y el saldo se actualiza directamente en la cuenta; Phoenix es un UTXO con una capa de direcciones invisibles, y el saldo queda oculto en el note. El traspaso de fondos entre ambas cosas depende del Transfer Contract como intérprete: transferir blindado a público, primero se descuenta el saldo y luego se acuña el note; transferir público a blindado, primero se quema el note y luego se incrementa el saldo. ¿Suena lógico, verdad? Pero en cuanto escribes una interfaz de consulta y quieres mostrar en una sola vista la suma de saldos de ambos lados, tienes que manejar a la vez dos grupos de datos con formatos totalmente distintos: el estado de la cuenta y el cifrado del note. El primer impulso de los nuevos en mi equipo fue sumar directamente el value del note como si fuera el saldo: la transacción, al emitirse, quedó inutilizable, porque en Phoenix el note necesita que se verifiquen pruebas de propiedad antes de poder descifrar el valor; eso no coincide en absoluto con el momento/tiempo de lectura del saldo de Moonlight.
En cuanto a Gas, ni hablar: es una trampa “invisible”. En las transacciones públicas estimas con la lógica habitual y casi siempre aciertas; pero las transacciones blindadas requieren generar y verificar pruebas ZK, y la complejidad del circuito de la prueba se engancha directamente con la cantidad de notes y las condiciones del propio intercambio. Probé una transferencia Phoenix con 2 inputs note y 3 outputs note: el consumo de Gas fue casi dos órdenes de magnitud mayor que el de una transacción pública del mismo nivel. Las constantes de Gas que aparecen en la documentación solo te sirven como referencia de precio base; antes de lanzarlo de verdad, si no corres varias simulaciones en la testnet con parámetros reales, de verdad no te atreves a rellenar el límite de Gas: si pones menos, la transacción revierte; si pones más, solo quemas dinero sin más.
Lo que no termino de entender es que, en el tutorial oficial de Dusk, para ese tipo de escenarios “de borde” de “consulta híbrida + llamadas entre modelos”, la explicación de los límites es bastante escasa. @Dusk $DUSK #dusk