En consultant la documentation de Dusk hier soir, j’ai finalement réalisé que j’avais compris « prendre en charge EVM » de manière trop simplifiée. Dusk ne met pas tous les contrats dans une seule machine virtuelle : pour les développeurs familiers de Solidity et Foundry, il y a DuskEVM, on paie le Gas avec @Dusk DUSK, puis les données par lots et les engagements d’état sont traités via DuskDS ; pour les contrats nécessitant une confidentialité native et des capacités de preuve à divulgation nulle, ou encore un contrôle des actifs au niveau du protocole, on exécute directement le code en Rust/WASM sur DuskVM.

Je l’ai compris comme deux pupitres d’opération ouverts par la même société de transaction. L’un conserve des boutons familiers, ce qui permet d’aller plus vite à la migration ; l’autre se rapproche du coffre-fort de bas niveau, peut appeler des règles plus natives, et à la fin, tout revient à la même base de compensation pour confirmer le grand livre. Ce compromis est plus important que les seuls quatre mots « compatible EVM », car il sépare l’efficacité de développement et les capacités natives.

Mais ces deux parcours ajoutent aussi de la complexité en matière de pontage et d’interactions entre couches, et il faut évaluer correctement l’état. La documentation officielle le rappelle clairement : le « quick packing » de DuskEVM ne signifie pas que le règlement a déjà été finalisé dans DuskDS ; je ne me contenterai pas de voir « réussi » à l’écran pour conclure que c’est terminé. Par la suite, il faudra vérifier si l’expérience inter-couches est fluide, si les outils sont suffisamment mûrs, et si le volume de contrats réels augmente. L’architecture propose des choix ; en l’adoptant, on obtient la réponse.

#dusk $DUSK