📅8.22
Durante estos días, los mensajes no han parado: “$BTC ha superado X”, “$BNB ha superado X”… Yo no tengo ni un solo activo en mano, viéndoos ganar dinero, mientras tanto. Mejor seguiré escribiendo artículos y ganando un dinero extra.
Esta mañana, al revisar la documentación de desarrollo de Dusk, hay una contradicción que no consigo eludir: el diseño de la arquitectura técnica tiene un gran sentido, pero cuando intentas empezar a desarrollar en la práctica, los tropiezos son muchísimos más de lo que imaginaba.
✅ De hecho, hay puntos a favor. DuskVM ejecuta contratos en Rust basados en WebAssembly; no necesitas dependencias locales y puedes completar el desarrollo directamente en el navegador. El puente de Contract Drivers del SDK W3sper tiene ideas muy interesantes: construye una capa de abstracción entre la billetera y el contrato, reduciendo el trabajo repetido de desarrollo. La primera vez que vi estos diseños, realmente pensé: “¡vaya, esto es brillante!”.
⚠️ Pero cuando intenté ejecutar de verdad una transacción de privacidad, los problemas empezaron a aparecer.
Moonlight (cuenta pública) y Phoenix (dirección enmascarada) tienen lógicas de transacción completamente distintas corriendo en la misma cadena. Al pasar de Moonlight a Phoenix, el contrato deduce el saldo público y genera un note que se envía a la dirección oculta; en sentido inverso, primero consume el note y luego acredita el saldo público. A nivel lógico tiene sentido, pero en el desarrollo real el modelo de estado, el set de instrucciones y la medición de Gas están diseñados alrededor de una ejecución transparente. Probé a reutilizar directamente la lógica de Gas de una transacción pública para estimar una transacción enmascarada, y el resultado fue que la transacción falló directamente.
Lo que más me da dolor de cabeza es la documentación. En la promoción oficial dicen “puedes desarrollarlo solo con el navegador”, pero al recorrerla encontré que faltan descripciones de muchos escenarios límite. Hay una función clave que no aparece con una guía clara en la documentación; solo pude revisar el código fuente del contrato. Para el desarrollo de un proyecto real, este coste de tiempo está muy por encima de lo que inicialmente esperaba.
La innovación en la arquitectura técnica merece reconocimiento: los contratos WASM, el modelo de doble transacción y el enfoque abstracto de Contract Drivers son visionarios. Pero la complejidad que trae estas innovaciones, por ahora, la documentación y la cadena de herramientas aún no la cubren completamente. Para mí, la dificultad de entrar en esta arquitectura es mucho mayor que la expectativa que transmite la frase oficial de “se puede desarrollar en el navegador”.
#dusk $DUSK @Dusk
Durante estos días, los mensajes no han parado: “$BTC ha superado X”, “$BNB ha superado X”… Yo no tengo ni un solo activo en mano, viéndoos ganar dinero, mientras tanto. Mejor seguiré escribiendo artículos y ganando un dinero extra.
Esta mañana, al revisar la documentación de desarrollo de Dusk, hay una contradicción que no consigo eludir: el diseño de la arquitectura técnica tiene un gran sentido, pero cuando intentas empezar a desarrollar en la práctica, los tropiezos son muchísimos más de lo que imaginaba.
✅ De hecho, hay puntos a favor. DuskVM ejecuta contratos en Rust basados en WebAssembly; no necesitas dependencias locales y puedes completar el desarrollo directamente en el navegador. El puente de Contract Drivers del SDK W3sper tiene ideas muy interesantes: construye una capa de abstracción entre la billetera y el contrato, reduciendo el trabajo repetido de desarrollo. La primera vez que vi estos diseños, realmente pensé: “¡vaya, esto es brillante!”.
⚠️ Pero cuando intenté ejecutar de verdad una transacción de privacidad, los problemas empezaron a aparecer.
Moonlight (cuenta pública) y Phoenix (dirección enmascarada) tienen lógicas de transacción completamente distintas corriendo en la misma cadena. Al pasar de Moonlight a Phoenix, el contrato deduce el saldo público y genera un note que se envía a la dirección oculta; en sentido inverso, primero consume el note y luego acredita el saldo público. A nivel lógico tiene sentido, pero en el desarrollo real el modelo de estado, el set de instrucciones y la medición de Gas están diseñados alrededor de una ejecución transparente. Probé a reutilizar directamente la lógica de Gas de una transacción pública para estimar una transacción enmascarada, y el resultado fue que la transacción falló directamente.
Lo que más me da dolor de cabeza es la documentación. En la promoción oficial dicen “puedes desarrollarlo solo con el navegador”, pero al recorrerla encontré que faltan descripciones de muchos escenarios límite. Hay una función clave que no aparece con una guía clara en la documentación; solo pude revisar el código fuente del contrato. Para el desarrollo de un proyecto real, este coste de tiempo está muy por encima de lo que inicialmente esperaba.
La innovación en la arquitectura técnica merece reconocimiento: los contratos WASM, el modelo de doble transacción y el enfoque abstracto de Contract Drivers son visionarios. Pero la complejidad que trae estas innovaciones, por ahora, la documentación y la cadena de herramientas aún no la cubren completamente. Para mí, la dificultad de entrar en esta arquitectura es mucho mayor que la expectativa que transmite la frase oficial de “se puede desarrollar en el navegador”.
#dusk $DUSK @Dusk
