#dusk Quand j’ai d’abord examiné l’architecture de développement de Dusk, je me suis honnêtement demandé pourquoi elle nécessitait deux environnements de smart contracts. Ma première pensée était simple : n’en faudrait-il pas un seul ?
En regardant de plus près, j’ai réalisé qu’ils résolvent deux problèmes de développement différents.
DuskEVM est la voie familière. La compatibilité avec Solidity et les outils EVM facilite la tâche des développeurs qui comprennent déjà l’écosystème Ethereum.
DuskVM, c’est là où l’architecture commence à faire davantage sens pour moi. Les contrats Rust/WASM s’exécutent directement sur Dusk L1, ce qui offre aux développeurs une manière plus native de travailler avec les capacités spécifiques de Dusk, y compris son modèle de transaction, ses fonctions de confidentialité et de connaissance zéro.
Ainsi, je ne vois pas DuskEVM et DuskVM comme des environnements en concurrence.
Je les vois comme deux points d’entrée différents.
Si je veux de la compatibilité et des outils familiers, l’EVM a du sens. Si une application a besoin d’un accès plus approfondi à ce que le propre L1 de Dusk peut fournir, DuskVM semble être le choix le plus naturel.
Cela a changé la façon dont je perçois l’architecture.
Dusk ne dit pas simplement : « nous prenons en charge l’EVM ». Elle donne aux développeurs de la flexibilité au niveau d’exécution, tandis que DuskDS reste en dessous, comme fondation pour le règlement et la disponibilité des données.
Pour moi, c’est la partie la plus intéressante de la conception : des façons différentes de construire, sans forcer chaque application à adopter le même modèle d’exécution.
$DUSK @Dusk
En regardant de plus près, j’ai réalisé qu’ils résolvent deux problèmes de développement différents.
DuskEVM est la voie familière. La compatibilité avec Solidity et les outils EVM facilite la tâche des développeurs qui comprennent déjà l’écosystème Ethereum.
DuskVM, c’est là où l’architecture commence à faire davantage sens pour moi. Les contrats Rust/WASM s’exécutent directement sur Dusk L1, ce qui offre aux développeurs une manière plus native de travailler avec les capacités spécifiques de Dusk, y compris son modèle de transaction, ses fonctions de confidentialité et de connaissance zéro.
Ainsi, je ne vois pas DuskEVM et DuskVM comme des environnements en concurrence.
Je les vois comme deux points d’entrée différents.
Si je veux de la compatibilité et des outils familiers, l’EVM a du sens. Si une application a besoin d’un accès plus approfondi à ce que le propre L1 de Dusk peut fournir, DuskVM semble être le choix le plus naturel.
Cela a changé la façon dont je perçois l’architecture.
Dusk ne dit pas simplement : « nous prenons en charge l’EVM ». Elle donne aux développeurs de la flexibilité au niveau d’exécution, tandis que DuskDS reste en dessous, comme fondation pour le règlement et la disponibilité des données.
Pour moi, c’est la partie la plus intéressante de la conception : des façons différentes de construire, sans forcer chaque application à adopter le même modèle d’exécution.
$DUSK @Dusk