Quand j’ai parcouru la documentation Dusk hier soir, j’ai seulement alors réalisé que je comprenais « supporter l’EVM » de façon trop simpliste. Dusk ne met pas tous les contrats dans une seule machine virtuelle : pour les applications familières à Solidity et Foundry, on peut passer par DuskEVM, payer le Gas avec DUSK, puis confier les données par lots ainsi que les engagements d’état au DuskDS pour le règlement ; pour des contrats nécessitant une confidentialité native et des capacités de preuves à connaissance zéro, ou un contrôle des actifs au niveau du protocole, on utilise Rust/WASM exécuté directement sur DuskVM.

Je l’ai assimilé à deux pupitres d’opération ouverts par une même institution de transactions. L’un conserve des boutons familiers, permettant une migration plus rapide ; l’autre est plus proche du coffre-fort de bas niveau, et peut invoquer des règles plus natives, et, au final, tout revient à la même base de compensation pour valider le grand livre. Ce compromis est plus crucial que les seuls quatre mots « compatibilité EVM », car il sépare l’efficacité de développement des capacités natives.

Mais ces deux parcours augmentent aussi la complexité du pontage et des interactions inter-couches, et il faut en plus évaluer correctement l’état. La documentation officielle le rappelle clairement : le packaging rapide de DuskEVM ne signifie pas que le règlement a déjà été effectué dans DuskDS. Je ne me contenterai pas de voir « réussi » à l’écran pour considérer que c’est définitivement terminé. Par la suite, il faudra vérifier si l’expérience inter-couches est fluide, si les outils sont mûrs, et si le volume de contrats réels augmente. L’architecture offre des choix ; en les adoptant, on obtient la réponse.

@Dusk $DUSK #dusk