#dusk $DUSK @Dusk J’ai remarqué quelque chose qui, au départ, n’avait pas vraiment de sens.
Si DUSK veut que les développeurs construisent des applications financières, pourquoi créer son propre environnement d’exécution alors qu’un EVM existe déjà ?
Imaginez ouvrir un atelier spécialisé à côté d’une énorme usine généraliste.
L’usine peut fabriquer presque tout.
Mais votre atelier est conçu autour d’un seul type de travail.
C’est la différence que j’ai trouvée entre DuskVM et DuskEVM.
DuskEVM offre aux développeurs l’environnement Ethereum familier : Solidity, Vyper, les outils standard EVM et les portefeuilles.
Mais DuskVM prend une autre voie.
Il exécute directement sur le Dusk L1 des contrats intelligents Rust/WASM, donnant aux contrats un accès direct aux modèles natifs de transactions de Dusk, aux actifs, à la confidentialité et aux capacités de preuve à connaissance nulle.
C’est là que l’architecture m’a semblé évidente.
DUSK ne force pas chaque application à entrer dans un seul modèle d’exécution.
Il conserve l’environnement familier pour assurer la compatibilité…
tout en conservant un environnement natif pour les applications qui ont besoin d’un accès plus profond au L1.
Et c’est important, car les applications financières réglementées ne sont pas toujours de simples contrats DeFi ordinaires.
Certaines ont besoin directement des primitives de règlement et de confidentialité.
Alors peut-être que la question intéressante n’est pas :
« Pourquoi DUSK a deux VMs ? »
C’est plutôt :
« Que se passe-t-il quand la compatibilité et la spécialisation sont traitées comme deux problèmes d’ingénierie différents ? »
Ce compromis m’en dit beaucoup sur ce que DUSK essaie réellement de construire.
#dusk $DUSK @Dusk
Si DUSK veut que les développeurs construisent des applications financières, pourquoi créer son propre environnement d’exécution alors qu’un EVM existe déjà ?
Imaginez ouvrir un atelier spécialisé à côté d’une énorme usine généraliste.
L’usine peut fabriquer presque tout.
Mais votre atelier est conçu autour d’un seul type de travail.
C’est la différence que j’ai trouvée entre DuskVM et DuskEVM.
DuskEVM offre aux développeurs l’environnement Ethereum familier : Solidity, Vyper, les outils standard EVM et les portefeuilles.
Mais DuskVM prend une autre voie.
Il exécute directement sur le Dusk L1 des contrats intelligents Rust/WASM, donnant aux contrats un accès direct aux modèles natifs de transactions de Dusk, aux actifs, à la confidentialité et aux capacités de preuve à connaissance nulle.
C’est là que l’architecture m’a semblé évidente.
DUSK ne force pas chaque application à entrer dans un seul modèle d’exécution.
Il conserve l’environnement familier pour assurer la compatibilité…
tout en conservant un environnement natif pour les applications qui ont besoin d’un accès plus profond au L1.
Et c’est important, car les applications financières réglementées ne sont pas toujours de simples contrats DeFi ordinaires.
Certaines ont besoin directement des primitives de règlement et de confidentialité.
Alors peut-être que la question intéressante n’est pas :
« Pourquoi DUSK a deux VMs ? »
C’est plutôt :
« Que se passe-t-il quand la compatibilité et la spécialisation sont traitées comme deux problèmes d’ingénierie différents ? »
Ce compromis m’en dit beaucoup sur ce que DUSK essaie réellement de construire.
#dusk $DUSK @Dusk
