Je n’ai séparé cette confusion fréquente que lorsque j’ai consulté la toute dernière documentation de développement, @Dusk : DuskEVM et DuskVM ne sont pas la même machine virtuelle avec deux noms, et ce n’est pas non plus “un nouvel EVM qui rend la chaîne native obsolète”. La documentation propose aux développeurs deux parcours d’exécution : ceux qui maîtrisent Solidity, Foundry et Hardhat passent par DuskEVM ; ceux qui doivent toucher directement des actifs de niveau L1, la logique Phoenix/Moonlight, Rust/WASM ou des capacités de preuve à connaissance nulle passent par DuskVM.
DuskEVM suit la feuille de route OP Stack : l’exécution et les outils sont aussi proches que possible de l’écosystème Ethereum, puis le règlement et la publication des données sont confiés à DuskDS, $DUSK jouant le rôle de gas. DuskVM, lui, exécute directement des contrats WASM sur L1, ce qui le rapproche davantage du modèle de transaction natif et des capacités du protocole. Le premier réduit le coût de migration ; le second préserve les capacités différenciantes. L’un répond à la question “les développeurs vont-ils venir ?”, l’autre à “une fois qu’ils sont venus, peuvent-ils faire des choses que l’EVM standard ne fait pas proprement ?”.
Mais ces deux voies créent aussi de nouveaux coûts. Le passage des actifs d’une couche à l’autre, où placer l’état pour une même activité, et comment une application EVM s’intègre au processus confidentiel de Hedger : rien de tout cela ne s’accomplit automatiquement juste parce qu’on écrit “modulaire”. Le guide officiel DuskEVM sur les ponts inter-couches montre actuellement clairement le flux de testnet ; pour les retraits, il faut encore passer par trois actions on-chain — initiation, preuve, puis confirmation finale — et on ne peut pas décrire l’architecture comme une expérience monolithique sans friction, dès le départ, pour le mainnet.
Si je note la route multi-couches de #dusk , je ne compterai pas seulement le nombre de langages pris en charge : je regarderai où l’application aboutit réellement, comment récupérer en cas d’échec lors des transferts inter-couches, et si les fonctions de confidentialité sont appelables directement par des développeurs. Une nouvelle chaîne devrait-elle d’abord utiliser EVM pour gagner en vitesse d’adoption de l’écosystème, ou d’abord préserver l’intégrité des technologies natives ?
DuskEVM suit la feuille de route OP Stack : l’exécution et les outils sont aussi proches que possible de l’écosystème Ethereum, puis le règlement et la publication des données sont confiés à DuskDS, $DUSK jouant le rôle de gas. DuskVM, lui, exécute directement des contrats WASM sur L1, ce qui le rapproche davantage du modèle de transaction natif et des capacités du protocole. Le premier réduit le coût de migration ; le second préserve les capacités différenciantes. L’un répond à la question “les développeurs vont-ils venir ?”, l’autre à “une fois qu’ils sont venus, peuvent-ils faire des choses que l’EVM standard ne fait pas proprement ?”.
Mais ces deux voies créent aussi de nouveaux coûts. Le passage des actifs d’une couche à l’autre, où placer l’état pour une même activité, et comment une application EVM s’intègre au processus confidentiel de Hedger : rien de tout cela ne s’accomplit automatiquement juste parce qu’on écrit “modulaire”. Le guide officiel DuskEVM sur les ponts inter-couches montre actuellement clairement le flux de testnet ; pour les retraits, il faut encore passer par trois actions on-chain — initiation, preuve, puis confirmation finale — et on ne peut pas décrire l’architecture comme une expérience monolithique sans friction, dès le départ, pour le mainnet.
Si je note la route multi-couches de #dusk , je ne compterai pas seulement le nombre de langages pris en charge : je regarderai où l’application aboutit réellement, comment récupérer en cas d’échec lors des transferts inter-couches, et si les fonctions de confidentialité sont appelables directement par des développeurs. Une nouvelle chaîne devrait-elle d’abord utiliser EVM pour gagner en vitesse d’adoption de l’écosystème, ou d’abord préserver l’intégrité des technologies natives ?
