Tratar la implementación del contrato como si estuviera listo el desarrollo puede llevar a errores de interpretación en Dusk. Siguiendo la documentación de DuskVM de @Dusk , me detengo en el paso de Forge: genera ABI, schema y data driver a partir del código Rust con anotaciones; las dos últimas no son archivos “incluidos”, sino la puerta de entrada para que la aplicación lea el estado en la cadena. Ese detalle me hizo recalcular el progreso: que WASM pueda ejecutarse solo significa que la lógica se escribió en regla; si la descripción de la interfaz y el driver de lectura no se entregan con la misma versión, el front-end, los scripts y el indexador solo pueden “adivinar” cómo es el estado.
Lo que más fácil falla es la actualización. El equipo despliega un contrato nuevo, pero el data driver sigue siendo el de la versión anterior. Las transacciones siguen teniendo éxito, aunque el saldo, los campos o los eventos que muestra la página pueden haber quedado desfasados. Los usuarios se ven obligados a refrescar repetidamente; el ingeniero primero revisa el nodo y el soporte luego explica “que en la cadena no hay ningún problema”. Pero lo realmente desalineado es el estado del contrato con el contrato de lectura. Reiniciar el servicio no arregla la inconsistencia de versiones; normalmente hay que reconstruir, verificar y hacer que la aplicación cambie al driver correspondiente.
Por eso no considero que Forge sea solo una herramienta para ahorrar tiempo de andamiaje. Une en una misma cadena de entrega el hecho de que “el contrato puede ejecutarse” y el hecho de que “la aplicación puede interpretar correctamente el contrato”; lo que reduce no es solo el costo de integración, sino la incertidumbre entre roles. Para el ecosistema $DUSK , lo más valioso a mirar a partir de ahora es si los proyectos de ejemplo y el flujo de publicación dejan claro la relación de versiones entre ABI, schema y data driver. Si este paso se trata como opcional, los desarrolladores podrían seguir obteniendo contratos que se ejecutan, pero que difícilmente podrán usarse de forma confiable.#dusk 👻👻👻
Lo que más fácil falla es la actualización. El equipo despliega un contrato nuevo, pero el data driver sigue siendo el de la versión anterior. Las transacciones siguen teniendo éxito, aunque el saldo, los campos o los eventos que muestra la página pueden haber quedado desfasados. Los usuarios se ven obligados a refrescar repetidamente; el ingeniero primero revisa el nodo y el soporte luego explica “que en la cadena no hay ningún problema”. Pero lo realmente desalineado es el estado del contrato con el contrato de lectura. Reiniciar el servicio no arregla la inconsistencia de versiones; normalmente hay que reconstruir, verificar y hacer que la aplicación cambie al driver correspondiente.
Por eso no considero que Forge sea solo una herramienta para ahorrar tiempo de andamiaje. Une en una misma cadena de entrega el hecho de que “el contrato puede ejecutarse” y el hecho de que “la aplicación puede interpretar correctamente el contrato”; lo que reduce no es solo el costo de integración, sino la incertidumbre entre roles. Para el ecosistema $DUSK , lo más valioso a mirar a partir de ahora es si los proyectos de ejemplo y el flujo de publicación dejan claro la relación de versiones entre ABI, schema y data driver. Si este paso se trata como opcional, los desarrolladores podrían seguir obteniendo contratos que se ejecutan, pero que difícilmente podrán usarse de forma confiable.#dusk 👻👻👻
