Quand je lisais la documentation de W3sper de @Dusk Dusk, j’ai déjà pris la requête de DuskVM pour une interface JSON ordinaire. La compilation Forge d’un contrat produit aussi un WASM data-driver ; l’application s’enregistre auprès de W3sper via l’ID de contrat. Le driver encode l’entrée en octets ABI, puis décode la valeur de retour renvoyée par le nœud.

Je l’ai traité comme un comptoir de traduction pour le personnel de tarmac. Les passagers disent « JSON », et la piste ne reconnaît qu’un format de chargement fixe ; au comptoir, on conditionne selon le schema, puis on détache à nouveau les sorties et les événements au retour. Quand on envoie des raw bytes via HTTP, on les transmet directement au contrat ; quand on envoie du JSON, seule l’utilisation par le driver permet la conversion automatique. get_version permet de consulter la version.

Il faut surtout cacher ça après la mise à niveau. L’ancien driver peut renvoyer un succès, mais interpréter les données avec un ABI obsolète. Dans les métadonnées, driver_available et driver_signature ne me servent qu’à vérifier l’identité du driver. Je vais fixer un hash de fichier, puis sur le testnet comparer la même entrée : bytes bruts et résultat décodé. Le fait que la page soit lisible ne prouve qu’un chaînage de traduction ; l’état des assets doit encore être vérifié de manière indépendante.

#dusk $DUSK