#dusk $DUSK @Dusk
J’ai analysé comment DuskVM et DuskEVM se répartissent concrètement le travail sur Dusk : tous deux exécutent des contrats, mais ils ne sont clairement pas interchangeables.
DuskVM exécute des contrats Rust/WASM, construits sur Wasmtime, directement sur le L1 de Dusk. c’est la voie conçue pour les contrats qui ont besoin d’un accès direct aux modèles de transactions de Dusk, aux fonctionnalités de confidentialité, ou à des capacités de preuve à divulgation nulle — les fonctions d’accueil compatibles ZK de Piecrust (PLONK, Groth16, BLS) résident ici précisément.
DuskEVM s’exécute ailleurs. c’est un environnement équivalent EVM basé sur OP Stack — l’ID de chaîne du testnet est confirmé à 745 dans la documentation officielle de Dusk — permettant aux développeurs de déployer des contrats Solidity standard via MetaMask, Hardhat ou Foundry, tout en réglant et publiant les données en retour via DuskDS sous forme de blobs, grâce à un sequencer et un batcher, plutôt qu’en s’exécutant indépendamment.
J’ai isolé ce qui les différencie au-delà du simple langage. les contrats DuskVM obtiennent nativement la confidentialité et des primitives ZK, au niveau d’exécution. les contrats DuskEVM obtiennent une compatibilité complète avec l’outillage, et les utilisateurs y paient aussi le gaz en DUSK, mais en passant par une couche qui règle ailleurs plutôt qu’en s’exécutant nativement aux côtés des modèles de transactions propres à Dusk.
les deux règlent via la même base — DuskDS — et, au final, paient tous deux le gaz en DUSK. aucun ne remplace l’autre ; chacun existe parce que l’autre ne peut pas couvrir correctement sa mission spécifique.
Ainsi, le vrai choix pour un développeur n’est pas « lequel est le meilleur ». c’est de savoir si le contrat a besoin d’une exécution native orientée confidentialité ou d’un outillage EVM familier, vérifiable par l’ID de chaîne — et Dusk a créé deux voies distinctes au lieu de forcer un seul environnement à faire les deux.
Maintenir deux environnements d’exécution réellement séparés aide-t-il davantage les développeurs que d’en choisir un seul et de l’optimiser pleinement ?
J’ai analysé comment DuskVM et DuskEVM se répartissent concrètement le travail sur Dusk : tous deux exécutent des contrats, mais ils ne sont clairement pas interchangeables.
DuskVM exécute des contrats Rust/WASM, construits sur Wasmtime, directement sur le L1 de Dusk. c’est la voie conçue pour les contrats qui ont besoin d’un accès direct aux modèles de transactions de Dusk, aux fonctionnalités de confidentialité, ou à des capacités de preuve à divulgation nulle — les fonctions d’accueil compatibles ZK de Piecrust (PLONK, Groth16, BLS) résident ici précisément.
DuskEVM s’exécute ailleurs. c’est un environnement équivalent EVM basé sur OP Stack — l’ID de chaîne du testnet est confirmé à 745 dans la documentation officielle de Dusk — permettant aux développeurs de déployer des contrats Solidity standard via MetaMask, Hardhat ou Foundry, tout en réglant et publiant les données en retour via DuskDS sous forme de blobs, grâce à un sequencer et un batcher, plutôt qu’en s’exécutant indépendamment.
J’ai isolé ce qui les différencie au-delà du simple langage. les contrats DuskVM obtiennent nativement la confidentialité et des primitives ZK, au niveau d’exécution. les contrats DuskEVM obtiennent une compatibilité complète avec l’outillage, et les utilisateurs y paient aussi le gaz en DUSK, mais en passant par une couche qui règle ailleurs plutôt qu’en s’exécutant nativement aux côtés des modèles de transactions propres à Dusk.
les deux règlent via la même base — DuskDS — et, au final, paient tous deux le gaz en DUSK. aucun ne remplace l’autre ; chacun existe parce que l’autre ne peut pas couvrir correctement sa mission spécifique.
Ainsi, le vrai choix pour un développeur n’est pas « lequel est le meilleur ». c’est de savoir si le contrat a besoin d’une exécution native orientée confidentialité ou d’un outillage EVM familier, vérifiable par l’ID de chaîne — et Dusk a créé deux voies distinctes au lieu de forcer un seul environnement à faire les deux.
Maintenir deux environnements d’exécution réellement séparés aide-t-il davantage les développeurs que d’en choisir un seul et de l’optimiser pleinement ?
