Auparavant, je pensais qu’une blockchain publique pouvait simplement mettre en place plusieurs environnements d’exécution supplémentaires, au maximum pour offrir aux développeurs une option de plus. Mais après avoir dissocié l’architecture de @Dusk , j’ai compris que la relation entre DuskVM et DuskEVM n’est pas si simple : elles ressemblent davantage à deux portes d’entrée conçues pour des besoins différents. $DUSK
DuskVM s’exécute directement sur Dusk L1, en utilisant Rust/WASM. Il convient aux cas d’appel d’actifs natifs, à la confidentialité et aux capacités ZK. DuskEVM, quant à lui, est comme un pont de migration : il permet aux développeurs Solidity de continuer à utiliser des portefeuilles, frameworks et outils de test familiers. À la fin, les résultats des deux côtés sont confiés à DuskDS pour le règlement. #dusk
Cela signifie que le rôle de DuskEVM ne se limite pas à réduire le seuil de migration. Par exemple, si une application financière classique veut d’abord s’appuyer sur une chaîne d’outils EVM mature, elle peut commencer par DuskEVM. Mais si l’on traite des valeurs mobilières confidentielles, des transferts d’actifs sous contrôle, ou si l’on a besoin d’appeler les capacités secrètes natives de Dusk, on ne peut pas s’arrêter à la seule couche EVM : une grande partie de la logique doit encore passer par DuskVM.
D’où une question. Imaginons qu’une application doive à la fois intégrer des contrats Solidity et gérer des actifs de confidentialité natifs de Dusk : l’état principal doit-il être placé où ? Comment synchroniser les deux environnements ? Qui vérifie les appels entre couches ? En cas d’erreur, le développeur doit-il diagnostiquer un problème de contrat, un problème d’environnement d’exécution, ou un problème au niveau du règlement ? $BTC
C’est pourquoi, aujourd’hui, je ne vois pas le multi-environnement d’exécution de Dusk comme un simple avantage de compatibilité. D’un côté, il permet à davantage de développeurs d’entrer ; de l’autre, il confie à l’équipe produit les difficultés de conception du système. Ce qui mérite vraiment d’être observé, ce n’est pas le nombre de manières d’exécuter que propose Dusk, mais si ces environnements peuvent établir des limites claires entre eux : pour que les développeurs fassent moins de compromis inutiles, et non pour empiler toujours plus de complexité d’architecture afin d’appeler simultanément différentes capacités. $ETH
DuskVM s’exécute directement sur Dusk L1, en utilisant Rust/WASM. Il convient aux cas d’appel d’actifs natifs, à la confidentialité et aux capacités ZK. DuskEVM, quant à lui, est comme un pont de migration : il permet aux développeurs Solidity de continuer à utiliser des portefeuilles, frameworks et outils de test familiers. À la fin, les résultats des deux côtés sont confiés à DuskDS pour le règlement. #dusk
Cela signifie que le rôle de DuskEVM ne se limite pas à réduire le seuil de migration. Par exemple, si une application financière classique veut d’abord s’appuyer sur une chaîne d’outils EVM mature, elle peut commencer par DuskEVM. Mais si l’on traite des valeurs mobilières confidentielles, des transferts d’actifs sous contrôle, ou si l’on a besoin d’appeler les capacités secrètes natives de Dusk, on ne peut pas s’arrêter à la seule couche EVM : une grande partie de la logique doit encore passer par DuskVM.
D’où une question. Imaginons qu’une application doive à la fois intégrer des contrats Solidity et gérer des actifs de confidentialité natifs de Dusk : l’état principal doit-il être placé où ? Comment synchroniser les deux environnements ? Qui vérifie les appels entre couches ? En cas d’erreur, le développeur doit-il diagnostiquer un problème de contrat, un problème d’environnement d’exécution, ou un problème au niveau du règlement ? $BTC
C’est pourquoi, aujourd’hui, je ne vois pas le multi-environnement d’exécution de Dusk comme un simple avantage de compatibilité. D’un côté, il permet à davantage de développeurs d’entrer ; de l’autre, il confie à l’équipe produit les difficultés de conception du système. Ce qui mérite vraiment d’être observé, ce n’est pas le nombre de manières d’exécuter que propose Dusk, mais si ces environnements peuvent établir des limites claires entre eux : pour que les développeurs fassent moins de compromis inutiles, et non pour empiler toujours plus de complexité d’architecture afin d’appeler simultanément différentes capacités. $ETH