Après avoir revu Dusk, j’ai au contraire commencé à m’intéresser à une question très rarement abordée : où devrait vraiment se situer le « pouvoir d’exécution » sur la chaîne ?
En étudiant récemment @Dusk , je me suis rendu compte que je regardais de moins en moins une fonctionnalité isolée, et que je commençais plutôt à observer comment une blockchain financière publique répartit ses capacités d’exécution.
Dusk ne met pas tout dans un seul environnement d’exécution. DuskEVM gère Solidity, Vyper et les outils EVM familiers ; DuskVM s’exécute directement sur Dusk L1, vise les contrats Rust/WASM, et peut accéder aux actifs au niveau du protocole, au modèle de transaction natif, ainsi qu’aux capacités de confidentialité et de ZK ; la couche de base DuskDS se charge, elle, du consensus, du règlement et de la disponibilité des données. La documentation officielle décrit d’ailleurs très clairement cette répartition.
Je pense qu’il y a ici une distinction facile à négliger : la compatibilité EVM résout la question de « comment faire venir les développeurs », tandis qu’un environnement d’exécution natif répond à « quelles choses doivent absolument rester proches de la L1 pour fonctionner correctement ».
Pour des applications DeFi classiques, les outils EVM sont déjà très pratiques ; mais si l’application implique des transactions privées, des actifs réglementés, ou nécessite d’appeler directement les capacités natives de Dusk, alors traiter tout cela selon le paradigme EVM traditionnel peut au contraire limiter la conception du protocole.
C’est aussi l’angle sous lequel j’ai recommencé à comprendre Dusk. Il ne cherche pas simplement à être « compatible avec plus de choses » ; il essaie de donner à différents types d’applications des emplacements d’exécution différents, tout en ramenant le résultat final vers une même couche de règlement.
En regardant à nouveau $DUSK , on voit aussi qu’il joue simultanément le rôle de gas et de staking, ce qui fait que l’exécution des transactions et la sécurité du réseau partagent le même actif économique.
Bien sûr, pour savoir si cette architecture peut vraiment créer de la valeur, il faudra encore voir si les développeurs accepteront de quitter la voie purement EVM pour profiter des capacités natives, et quelle forme d’exécution les applications financières réelles finiront par choisir.
Donc, ce que j’ai surtout envie d’observer maintenant, ce n’est pas si Dusk « a ou non un EVM », mais s’il peut démontrer une chose : dans des scénarios financiers complexes, l’environnement d’exécution lui-même peut aussi faire partie de la conception du protocole. #dusk $DUSK @Dusk
En étudiant récemment @Dusk , je me suis rendu compte que je regardais de moins en moins une fonctionnalité isolée, et que je commençais plutôt à observer comment une blockchain financière publique répartit ses capacités d’exécution.
Dusk ne met pas tout dans un seul environnement d’exécution. DuskEVM gère Solidity, Vyper et les outils EVM familiers ; DuskVM s’exécute directement sur Dusk L1, vise les contrats Rust/WASM, et peut accéder aux actifs au niveau du protocole, au modèle de transaction natif, ainsi qu’aux capacités de confidentialité et de ZK ; la couche de base DuskDS se charge, elle, du consensus, du règlement et de la disponibilité des données. La documentation officielle décrit d’ailleurs très clairement cette répartition.
Je pense qu’il y a ici une distinction facile à négliger : la compatibilité EVM résout la question de « comment faire venir les développeurs », tandis qu’un environnement d’exécution natif répond à « quelles choses doivent absolument rester proches de la L1 pour fonctionner correctement ».
Pour des applications DeFi classiques, les outils EVM sont déjà très pratiques ; mais si l’application implique des transactions privées, des actifs réglementés, ou nécessite d’appeler directement les capacités natives de Dusk, alors traiter tout cela selon le paradigme EVM traditionnel peut au contraire limiter la conception du protocole.
C’est aussi l’angle sous lequel j’ai recommencé à comprendre Dusk. Il ne cherche pas simplement à être « compatible avec plus de choses » ; il essaie de donner à différents types d’applications des emplacements d’exécution différents, tout en ramenant le résultat final vers une même couche de règlement.
En regardant à nouveau $DUSK , on voit aussi qu’il joue simultanément le rôle de gas et de staking, ce qui fait que l’exécution des transactions et la sécurité du réseau partagent le même actif économique.
Bien sûr, pour savoir si cette architecture peut vraiment créer de la valeur, il faudra encore voir si les développeurs accepteront de quitter la voie purement EVM pour profiter des capacités natives, et quelle forme d’exécution les applications financières réelles finiront par choisir.
Donc, ce que j’ai surtout envie d’observer maintenant, ce n’est pas si Dusk « a ou non un EVM », mais s’il peut démontrer une chose : dans des scénarios financiers complexes, l’environnement d’exécution lui-même peut aussi faire partie de la conception du protocole. #dusk $DUSK @Dusk