En étudiant récemment l’architecture de Dusk, un choix de conception m’a vraiment surpris. Pourquoi un même projet devrait-il faire fonctionner deux ensembles de machines virtuelles ?
DuskEVM s’inscrit dans l’écosystème Solidity : les développeurs peuvent déployer directement avec des outils familiers comme Hardhat et Foundry. DuskVM, lui, vise la pile technologique Rust et WASM : il héberge des contrats intelligents ZK ainsi que des flux d’actifs privés natifs. À court terme, c’est une répartition plutôt intelligente. D’un côté, EVM résout le problème de l’entrée pour les développeurs ; de l’autre, DuskVM préserve la forteresse de la finance de confidentialité — sans renoncer à l’un ni à l’autre.
Mais en regardant plus loin, je réalise que le coût caché n’est pas négligeable.
Le vrai problème n’est pas de savoir si les deux VM peuvent tourner, mais comment aligner leurs états sur la durée. Les développeurs Solidity sont habitués à une logique de registre transparent, tandis que le scénario central de DuskVM concerne précisément des actifs confidentiels et une divulgation conforme. Lorsque les applications sur DuskEVM doivent appeler les capacités de confidentialité sous-jacentes via des modules comme Hedger, deux logiques d’exécution totalement différentes s’intercalent. Une mise à niveau d’un côté peut entraîner un décalage discret des hypothèses d’interface de l’autre. Ce n’est pas un problème de qualité de code : c’est l’une des dettes de coordination les plus sournoises dans un système modulaire. Elle ne se voit pas au début, mais elle devient d’autant plus coûteuse que l’écosystème s’étoffe.
La couche plus concrète encore : les ressources de développement sont limitées. La conclusion la plus fréquente des projets à double pile, c’est que tout le flux de l’écosystème finit par se concentrer du côté dont la porte d’entrée est la plus basse. Tout le monde écrit sur DuskEVM en Solidity, et la voie de DuskVM — la plus profonde de sa forteresse — n’est plus cultivée. Alors, ce double VM passe de la répartition des rôles à une configuration de terrain principal/secondaire : le récit de confidentialité se dilue et devient un simple ajout à une chaîne EVM classique.
Bien sûr, je ne cherche pas à rejeter ce choix. Dans l’angle « finance réglementée », on ne peut pas faire fonctionner l’un sans l’autre : la taille de l’équipe de développement et les capacités de confidentialité sous-jacentes. Pour tout tenir en même temps, le double VM est pratiquement incontournable.
Mais les indicateurs à surveiller ensuite sont très clairs. Sur DuskEVM, quelle proportion des applications déployées appelle réellement les capacités de confidentialité et ZK côté DuskVM ? Si tout le monde n’utilise Dusk qu’avec l’idée d’une chaîne EVM « classique » proposant plusieurs arguments de confidentialité, alors la signification stratégique de l’architecture à double VM devra être sérieusement remise en question.
Une belle architecture ne garantit pas que l’écosystème suivra le scénario prévu. La question de savoir si les deux machines virtuelles s’emboîtent réellement dépend, au final, des données réelles des appels entre couches. Dans la suite, je continuerai à suivre les performances on-chain de DUSK. Pour vous, le double VM est-il complémentaire, ou va-t-il évoluer vers une consommation de ressources inutile ? #dusk $DUSK @Dusk
DuskEVM s’inscrit dans l’écosystème Solidity : les développeurs peuvent déployer directement avec des outils familiers comme Hardhat et Foundry. DuskVM, lui, vise la pile technologique Rust et WASM : il héberge des contrats intelligents ZK ainsi que des flux d’actifs privés natifs. À court terme, c’est une répartition plutôt intelligente. D’un côté, EVM résout le problème de l’entrée pour les développeurs ; de l’autre, DuskVM préserve la forteresse de la finance de confidentialité — sans renoncer à l’un ni à l’autre.
Mais en regardant plus loin, je réalise que le coût caché n’est pas négligeable.
Le vrai problème n’est pas de savoir si les deux VM peuvent tourner, mais comment aligner leurs états sur la durée. Les développeurs Solidity sont habitués à une logique de registre transparent, tandis que le scénario central de DuskVM concerne précisément des actifs confidentiels et une divulgation conforme. Lorsque les applications sur DuskEVM doivent appeler les capacités de confidentialité sous-jacentes via des modules comme Hedger, deux logiques d’exécution totalement différentes s’intercalent. Une mise à niveau d’un côté peut entraîner un décalage discret des hypothèses d’interface de l’autre. Ce n’est pas un problème de qualité de code : c’est l’une des dettes de coordination les plus sournoises dans un système modulaire. Elle ne se voit pas au début, mais elle devient d’autant plus coûteuse que l’écosystème s’étoffe.
La couche plus concrète encore : les ressources de développement sont limitées. La conclusion la plus fréquente des projets à double pile, c’est que tout le flux de l’écosystème finit par se concentrer du côté dont la porte d’entrée est la plus basse. Tout le monde écrit sur DuskEVM en Solidity, et la voie de DuskVM — la plus profonde de sa forteresse — n’est plus cultivée. Alors, ce double VM passe de la répartition des rôles à une configuration de terrain principal/secondaire : le récit de confidentialité se dilue et devient un simple ajout à une chaîne EVM classique.
Bien sûr, je ne cherche pas à rejeter ce choix. Dans l’angle « finance réglementée », on ne peut pas faire fonctionner l’un sans l’autre : la taille de l’équipe de développement et les capacités de confidentialité sous-jacentes. Pour tout tenir en même temps, le double VM est pratiquement incontournable.
Mais les indicateurs à surveiller ensuite sont très clairs. Sur DuskEVM, quelle proportion des applications déployées appelle réellement les capacités de confidentialité et ZK côté DuskVM ? Si tout le monde n’utilise Dusk qu’avec l’idée d’une chaîne EVM « classique » proposant plusieurs arguments de confidentialité, alors la signification stratégique de l’architecture à double VM devra être sérieusement remise en question.
Une belle architecture ne garantit pas que l’écosystème suivra le scénario prévu. La question de savoir si les deux machines virtuelles s’emboîtent réellement dépend, au final, des données réelles des appels entre couches. Dans la suite, je continuerai à suivre les performances on-chain de DUSK. Pour vous, le double VM est-il complémentaire, ou va-t-il évoluer vers une consommation de ressources inutile ? #dusk $DUSK @Dusk