#dusk $DUSK @Dusk Antes creía que, una vez que un contrato se despliega en la cadena, lo único que quedaba era conectar la aplicación para llamar funciones. Pero cuando seguí la guía de inicio rápido de <DuskVM> de @Dusk, descubrí un detalle que es muy fácil pasar por alto: a partir del mismo código fuente en Rust hay que generar dos WASM. Una es el contrato que realmente se ejecuta en la cadena; la otra es un “controlador” de datos para que el lado de la aplicación codifique y decodifique. Esto no es simplemente compilar el archivo una segunda vez. La versión en la cadena es la que determina cómo cambia el estado; la versión en la parte fuera de la cadena es la que determina cómo el frontend traduce “cambiar el número a 42” a parámetros que el protocolo pueda leer, y también determina si el resultado devuelto puede reconstruirse en datos comprensibles para humanos. @Dusk Además, coloca estos dos productos en rutas diferentes y proporciona una verificación (verify) para comprobar que ambos coinciden y que el hash del contrato es el mismo. En realidad, lo que el desarrollador debe mantener es un par de interfaces que necesariamente deben estar sincronizadas.
El caso más problemático es cuando el contrato ya está desplegado y las transacciones se ejecutan, pero la aplicación envía la solicitud usando un controlador de datos antiguo. Entonces el usuario puede ver errores de codificación de parámetros, o bien que la llamada tenga éxito pero la página interprete mal el resultado. Cuando en la cadena no aparece un error evidente, el desarrollador termina teniendo que volver a rastrear el código fuente, la versión del build y los registros de despliegue. Ese tiempo que se ahorra al principio acaba convirtiéndose en un costo de localización que asumen por igual el integrador y el usuario. Por eso, al evaluar la experiencia de desarrollo de DUSK, no solo me pregunto “¿pueden ejecutar el contrato Rust?”. El diseño de doble producto de DuskVM hace más claras las fronteras entre la ejecución en cadena y la comprensión por parte de la aplicación, y también recuerda al equipo que “despliegue exitoso” no significa necesariamente “integración completada”. Más adelante revisaré si el proyecto deja juntos para poder verificarlos: la versión del controlador de datos, el hash del contrato y el flujo de publicación. Ese es el paso clave para que Dusk pase de “funciona” a “es mantenible”.
El caso más problemático es cuando el contrato ya está desplegado y las transacciones se ejecutan, pero la aplicación envía la solicitud usando un controlador de datos antiguo. Entonces el usuario puede ver errores de codificación de parámetros, o bien que la llamada tenga éxito pero la página interprete mal el resultado. Cuando en la cadena no aparece un error evidente, el desarrollador termina teniendo que volver a rastrear el código fuente, la versión del build y los registros de despliegue. Ese tiempo que se ahorra al principio acaba convirtiéndose en un costo de localización que asumen por igual el integrador y el usuario. Por eso, al evaluar la experiencia de desarrollo de DUSK, no solo me pregunto “¿pueden ejecutar el contrato Rust?”. El diseño de doble producto de DuskVM hace más claras las fronteras entre la ejecución en cadena y la comprensión por parte de la aplicación, y también recuerda al equipo que “despliegue exitoso” no significa necesariamente “integración completada”. Más adelante revisaré si el proyecto deja juntos para poder verificarlos: la versión del controlador de datos, el hash del contrato y el flujo de publicación. Ese es el paso clave para que Dusk pase de “funciona” a “es mantenible”.
