DuskVM est probablement plus important qu’il n’y paraît au premier abord.
Je me suis penché sur la couche d’exécution de Dusk, et un détail a attiré mon attention :
Dusk n’oblige pas chaque développeur à passer par l’EVM.
DuskVM exécute directement des contrats intelligents Rust/WASM sur le Dusk L1, tandis que DuskEVM offre aux développeurs la voie SolidityEVM. Cette séparation est intéressante, car les deux environnements résolvent des problèmes différents.
Puis, le 10 août, le testnet de DuskEVM est passé en ligne, ouvrant le versant compatible EVM pour les tests basés sur Solidity et Hardhat.
Ce que je trouve particulièrement intéressant ici, c’est l’architecture :
DuskVM → exécution directe sur le L1
Rust/WASM → contrats au niveau protocole et spécialisés
Accès confidentialité/ZK → plus proche de la couche de base
DuskEVM → outils Ethereum familiers
$DUSK → actif natif de frais de gaz et de staking
Ma première réaction a été, en réalité : pourquoi construire deux chemins d’exécution ?
La réponse semble plutôt être la flexibilité que la compatibilité pour elle-même.
Mais le lancement du testnet, à lui seul, ne nous dit pas si les développeurs utiliseront réellement les deux environnements à grande échelle. C’est la partie que je surveille maintenant.
Les vrais créateurs choisiront-ils DuskVM quand l’exécution directe sur le L1 compte, ou bien la majeure partie de l’activité finira-t-elle par se concentrer sur DuskEVM ?
@Dusk $DUSK #dusk
Je me suis penché sur la couche d’exécution de Dusk, et un détail a attiré mon attention :
Dusk n’oblige pas chaque développeur à passer par l’EVM.
DuskVM exécute directement des contrats intelligents Rust/WASM sur le Dusk L1, tandis que DuskEVM offre aux développeurs la voie SolidityEVM. Cette séparation est intéressante, car les deux environnements résolvent des problèmes différents.
Puis, le 10 août, le testnet de DuskEVM est passé en ligne, ouvrant le versant compatible EVM pour les tests basés sur Solidity et Hardhat.
Ce que je trouve particulièrement intéressant ici, c’est l’architecture :
DuskVM → exécution directe sur le L1
Rust/WASM → contrats au niveau protocole et spécialisés
Accès confidentialité/ZK → plus proche de la couche de base
DuskEVM → outils Ethereum familiers
$DUSK → actif natif de frais de gaz et de staking
Ma première réaction a été, en réalité : pourquoi construire deux chemins d’exécution ?
La réponse semble plutôt être la flexibilité que la compatibilité pour elle-même.
Mais le lancement du testnet, à lui seul, ne nous dit pas si les développeurs utiliseront réellement les deux environnements à grande échelle. C’est la partie que je surveille maintenant.
Les vrais créateurs choisiront-ils DuskVM quand l’exécution directe sur le L1 compte, ou bien la majeure partie de l’activité finira-t-elle par se concentrer sur DuskEVM ?
@Dusk $DUSK #dusk
