Quand une blockchain publique ajoute la compatibilité EVM, j’ai généralement tendance à supposer que l’environnement d’exécution natif perd progressivement en priorité. Les outils EVM attirent davantage de développeurs, Solidity devient la norme, et un runtime natif séparé finit par ressembler à une charge de maintenance qu’on dépriorise discrètement.
Mais l’architecture mise à jour de @Dusk évite délibérément ce schéma.
Désormais, DuskDS gère le règlement et la disponibilité des données à la base, DuskEVM exécute des applications compatibles EVM, et DuskVM reste sur la couche L1 spécifiquement pour les contrats Rust et WASM qui nécessitent un accès direct à la confidentialité native et aux fonctionnalités ZK.
Au début, je l’ai perçu comme une duplication inutile, mais je pense que c’est l’inverse : cela traite l’onboarding des développeurs et les capacités du protocole comme deux problèmes distincts qu’on ne devrait pas forcer à cohabiter au même endroit.
DuskEVM gère la partie onboarding. Les contrats Solidity, les portefeuilles existants et les outils Ethereum fonctionnent ici sans modification. DuskVM gère autre chose : lorsqu’une application a besoin du modèle de transaction natif de Dusk, de fonctionnalités de confidentialité ou de preuves ZK, elle n’a pas besoin de tout traduire via du code compatible EVM. La documentation officielle présente DuskVM comme un environnement d’exécution WASM s’exécutant nativement sur la L1 de Dusk.
Cela m’a aidé à reconsidérer ce que #dusk est réellement en train de construire.
Ce n’est pas seulement une façon de découper la chaîne en couches. C’est la reconnaissance de quelque chose de plus précis : l’EVM est un point d’entrée efficace pour l’adoption par les développeurs, mais ce n’est peut-être pas le bon endroit pour porter des capacités qui doivent rester natives au protocole lui-même.
Ce qui vaut vraiment la peine d’être surveillé, ce n’est pas de savoir si $DUSK peut faire fonctionner deux environnements d’exécution en même temps, mais plutôt si les développeurs choisiront effectivement des chemins différents selon leurs besoins.
Si la plupart du développement reste dans l’EVM, DuskVM devient une capacité qui existe, mais qui sert peu. En revanche, si des applications natives en confidentialité et des protocoles financiers commencent à passer par le chemin d’exécution natif parce que l’EVM ne peut pas satisfaire ces exigences, alors la complexité de maintenir deux environnements aura un certain intérêt.
Mais l’architecture mise à jour de @Dusk évite délibérément ce schéma.
Désormais, DuskDS gère le règlement et la disponibilité des données à la base, DuskEVM exécute des applications compatibles EVM, et DuskVM reste sur la couche L1 spécifiquement pour les contrats Rust et WASM qui nécessitent un accès direct à la confidentialité native et aux fonctionnalités ZK.
Au début, je l’ai perçu comme une duplication inutile, mais je pense que c’est l’inverse : cela traite l’onboarding des développeurs et les capacités du protocole comme deux problèmes distincts qu’on ne devrait pas forcer à cohabiter au même endroit.
DuskEVM gère la partie onboarding. Les contrats Solidity, les portefeuilles existants et les outils Ethereum fonctionnent ici sans modification. DuskVM gère autre chose : lorsqu’une application a besoin du modèle de transaction natif de Dusk, de fonctionnalités de confidentialité ou de preuves ZK, elle n’a pas besoin de tout traduire via du code compatible EVM. La documentation officielle présente DuskVM comme un environnement d’exécution WASM s’exécutant nativement sur la L1 de Dusk.
Cela m’a aidé à reconsidérer ce que #dusk est réellement en train de construire.
Ce n’est pas seulement une façon de découper la chaîne en couches. C’est la reconnaissance de quelque chose de plus précis : l’EVM est un point d’entrée efficace pour l’adoption par les développeurs, mais ce n’est peut-être pas le bon endroit pour porter des capacités qui doivent rester natives au protocole lui-même.
Ce qui vaut vraiment la peine d’être surveillé, ce n’est pas de savoir si $DUSK peut faire fonctionner deux environnements d’exécution en même temps, mais plutôt si les développeurs choisiront effectivement des chemins différents selon leurs besoins.
Si la plupart du développement reste dans l’EVM, DuskVM devient une capacité qui existe, mais qui sert peu. En revanche, si des applications natives en confidentialité et des protocoles financiers commencent à passer par le chemin d’exécution natif parce que l’EVM ne peut pas satisfaire ces exigences, alors la complexité de maintenir deux environnements aura un certain intérêt.
