Considérer qu’un contrat déployé avec succès équivaut à un développement terminé est facile à faire par erreur sur Dusk. En suivant la documentation DuskVM depuis @Dusk , je m’arrête à l’étape Forge : elle génère l’ABI, le schéma et le data driver à partir de code Rust annoté. Les deux derniers ne sont pas de simples fichiers fournis avec ; ce sont des entrées que l’application utilise pour lire l’état on-chain. Ce détail m’a fait réévaluer l’avancement : le fait que le WASM s’exécute signifie seulement que les règles ont été écrites ; si la description des interfaces et le driver de lecture ne sont pas livrés avec la même version, alors le front-end, les scripts et l’indexeur ne peuvent toujours que « deviner » à quoi ressemble l’état.
Le problème le plus facile à faire survient lors d’une mise à niveau. L’équipe déploie un nouveau contrat, mais le data driver reste celui de l’ancienne version. Les transactions réussissent normalement, tandis que le solde, les champs ou les événements affichés par la page peuvent déjà être en retard. Les utilisateurs rafraîchissent sans cesse ; les ingénieurs vérifient d’abord le nœud, puis le support explique « qu’il n’y a aucun problème on-chain ». Mais l’inadéquation réelle se situe entre l’état du contrat et le contrat de lecture. Redémarrer le service ne résout pas l’incohérence de version ; il faut généralement reconstruire, revalider, puis faire basculer l’application sur un driver correspondant.
C’est pourquoi je ne réduis pas Forge à un outil qui fait gagner du temps de scaffolding. Il place « le contrat peut s’exécuter » et « l’application peut interpréter correctement le contrat » dans la même chaîne de livraison. Ce que l’on réduit, ce n’est pas tout le coût d’intégration, mais les conjectures entre rôles. Pour l’écosystème $DUSK , ce qu’il vaut davantage surveiller ensuite, c’est si les projets d’exemple et le processus de publication indiquent clairement les relations de version entre ABI, schéma et data driver ; si cette étape est considérée comme optionnelle, les développeurs risquent encore d’obtenir un contrat certes exécutable, mais difficile à utiliser de manière fiable.#dusk 👻👻👻
Le problème le plus facile à faire survient lors d’une mise à niveau. L’équipe déploie un nouveau contrat, mais le data driver reste celui de l’ancienne version. Les transactions réussissent normalement, tandis que le solde, les champs ou les événements affichés par la page peuvent déjà être en retard. Les utilisateurs rafraîchissent sans cesse ; les ingénieurs vérifient d’abord le nœud, puis le support explique « qu’il n’y a aucun problème on-chain ». Mais l’inadéquation réelle se situe entre l’état du contrat et le contrat de lecture. Redémarrer le service ne résout pas l’incohérence de version ; il faut généralement reconstruire, revalider, puis faire basculer l’application sur un driver correspondant.
C’est pourquoi je ne réduis pas Forge à un outil qui fait gagner du temps de scaffolding. Il place « le contrat peut s’exécuter » et « l’application peut interpréter correctement le contrat » dans la même chaîne de livraison. Ce que l’on réduit, ce n’est pas tout le coût d’intégration, mais les conjectures entre rôles. Pour l’écosystème $DUSK , ce qu’il vaut davantage surveiller ensuite, c’est si les projets d’exemple et le processus de publication indiquent clairement les relations de version entre ABI, schéma et data driver ; si cette étape est considérée comme optionnelle, les développeurs risquent encore d’obtenir un contrat certes exécutable, mais difficile à utiliser de manière fiable.#dusk 👻👻👻
