Quelque chose me fait m’arrêter en lisant sur le Dusk Network : DuskDS et DuskEVM sont décrits comme deux parties différentes, mais qui ne sont pourtant pas indépendantes.
Je commence par l’architecture. La documentation Dusk appelle DuskDS la couche de règlement et d’acquisition des données, qui assure le consensus, la finalité et les modèles de transactions natives de Dusk. DuskEVM est un environnement d’exécution compatible avec l’EVM, où les smart contracts Solidity peuvent tourner avec les outils familiers. Plus important encore, DuskEVM utilise DuskDS pour le règlement et l’acquisition des données.
Je veux vérifier si ce n’est qu’une façon de nommer au niveau de l’architecture, ou s’il existe une véritable séparation des responsabilités.
En allant plus loin, je constate que DuskDS gère le consensus, la finalité et l’acquisition des données, ainsi que des modèles de transactions tels que Moonlight et Phoenix. DuskEVM se concentre sur l’exécution et permet d’utiliser Hardhat, Foundry ainsi que l’écosystème EVM. L’une fournit la base du règlement, l’autre s’occupe de l’exécution.
Attendez—ce n’est pas encore suffisant pour dire que ces deux couches « se complètent » au sens des performances ou de la sécurité. D’après ce que j’ai pu vérifier dans la documentation, le lien le plus clair est que l’exécution est séparée du règlement.
Ce qui est intéressant, c’est que Dusk utilise la modularité pour garder le règlement séparé, tout en restant ouvert aux développeurs grâce à l’EVM.
Alors, si l’adoption des applications augmente, cette frontière entre exécution et règlement crée-t-elle vraiment un avantage, ou s’agit-il simplement d’une manière d’organiser l’architecture?
#dusk $DUSK @Dusk $BTC
Je commence par l’architecture. La documentation Dusk appelle DuskDS la couche de règlement et d’acquisition des données, qui assure le consensus, la finalité et les modèles de transactions natives de Dusk. DuskEVM est un environnement d’exécution compatible avec l’EVM, où les smart contracts Solidity peuvent tourner avec les outils familiers. Plus important encore, DuskEVM utilise DuskDS pour le règlement et l’acquisition des données.
Je veux vérifier si ce n’est qu’une façon de nommer au niveau de l’architecture, ou s’il existe une véritable séparation des responsabilités.
En allant plus loin, je constate que DuskDS gère le consensus, la finalité et l’acquisition des données, ainsi que des modèles de transactions tels que Moonlight et Phoenix. DuskEVM se concentre sur l’exécution et permet d’utiliser Hardhat, Foundry ainsi que l’écosystème EVM. L’une fournit la base du règlement, l’autre s’occupe de l’exécution.
Attendez—ce n’est pas encore suffisant pour dire que ces deux couches « se complètent » au sens des performances ou de la sécurité. D’après ce que j’ai pu vérifier dans la documentation, le lien le plus clair est que l’exécution est séparée du règlement.
Ce qui est intéressant, c’est que Dusk utilise la modularité pour garder le règlement séparé, tout en restant ouvert aux développeurs grâce à l’EVM.
Alors, si l’adoption des applications augmente, cette frontière entre exécution et règlement crée-t-elle vraiment un avantage, ou s’agit-il simplement d’une manière d’organiser l’architecture?
#dusk $DUSK @Dusk $BTC
