En relisant l’architecture de Dusk aujourd’hui, j’ai remarqué un point qui est relativement facile à ignorer !

Pourquoi garder DuskVM ?

Après tout, il existe déjà DuskEVM, et les développeurs peuvent directement utiliser des outils assez matures comme Solidity, Vyper, Hardhat et Foundry. Pour la plupart des applications, la simple compatibilité avec l’EVM suffit déjà.

Mais Dusk n’a pas pour autant abandonné l’environnement d’exécution natif.

DuskVM s’exécute directement sur Dusk L1, principalement pour des contrats Rust/WASM. Si une application doit accéder directement à des actifs de bas niveau, au modèle de transactions, aux capacités de confidentialité ou à des fonctionnalités liées aux preuves à divulgation nulle (zero-knowledge), alors DuskVM offre en fait des choix plus bas niveau.

Je pense que cela reflète une façon assez claire de faire des compromis techniques chez Dusk.

DuskEVM vise à résoudre le problème « comment faire venir davantage de développeurs », tandis que DuskVM répond à « quand une application a vraiment besoin de capacités de bas niveau, peut-elle continuer à aller plus en profondeur ».

Ces deux orientations ne s’opposent pas.

Pour la DeFi classique ou les applications de tokenisation, l’EVM peut déjà suffire ; mais si, à l’avenir, le marché financier fait apparaître des règles d’actifs plus complexes, une logique de confidentialité et des besoins de règlement, les développeurs auront besoin de plus que de la simple compatibilité.

Donc, en relisant aujourd’hui le double environnement d’exécution de Dusk, je préfère l’interpréter comme une conception d’infrastructure de long terme, plutôt que comme le simple ajout d’un EVM.

Ce qui vaut vraiment la peine d’être observé, c’est peut-être combien d’applications commenceront à avoir besoin, à l’avenir, des capacités de bas niveau que DuskVM fournit.#dusk $DUSK @Dusk
Penses-tu que le double environnement d’exécution de Dusk est nécessaire ?