Je pensais à l’origine que le fait qu’un contrat puisse ou non s’exécuter dans DuskVM dépendait surtout de savoir si le code Rust compile, mais en lisant la documentation de DuskVM de @Dusk , j’ai réalisé que les endroits où ça se bloque vraiment sont plus proches de la frontière d’appel : le contrat doit exposer une zone argbuf de 64 KB, et la fonction d’entrée doit recevoir la longueur de l’entrée au format fn foo(u32) -\u003e u32, traiter les données puis renvoyer la longueur de la sortie. Le fait que la logique du code soit correcte ne garantit pas que l’appel externe puisse lui fournir correctement des données. Cette conception m’a amené à reconsidérer le coût de développement : DuskVM ne dicte pas au développeur la logique métier, mais confie au contrat la responsabilité des limites mémoire pour l’entrée et la sortie. Les données transmises par l’appelant ne sont pas une simple “série de paramètres qu’on peut lire au hasard”, mais des données déjà placées dans un tampon et dont la portée de lecture est déterminée par la longueur. Si une seule étape ne correspond pas — sérialisation, vérification de la longueur ou écriture du retour — le problème peut ne pas se manifester comme une erreur métier évidente : le front-end ne recevra qu’un échec d’appel du contrat. Les scénarios de contrainte sont en réalité très concrets : dans les tests locaux, l’application d’actifs ne transmet qu’un simple nombre, tout fonctionne ; une fois en production, quand on remplace par des données de justificatifs plus longues, des commandes ou des informations de permission, le contrat est toujours appelable, mais il lit de façon incomplète ou renvoie un résultat tronqué. Ce que l’utilisateur voit, c’est que l’état ne se met pas à jour ; le développeur doit ensuite revenir en arrière pour vérifier l’ABI, le tampon et l’unité de données. Le coût n’est donc pas porté par une machine virtuelle abstraite, mais par l’utilisateur qui attend le résultat et par l’équipe qui maintient l’intégration. C’est pourquoi, quand je regarde la DuskVM de $DUSK , je ne me demande pas seulement si elle peut exécuter du Rust ou du WASM : je vérifie d’abord si les tests de contrat couvrent la longueur des paramètres, la longueur de la sortie et les entrées aux limites. @Dusk décrit très clairement la convention d’appel : derrière les performances et la maîtrise, il y a aussi une responsabilité mémoire. Pour les développeurs Dusk, ce qu’il faut vraiment valider, c’est que les données métier complexes entrant dans le contrat restent prévisibles aux frontières. #dusk