Ces deux derniers jours, j’ai refait les “Core Components” de @Dusk de fond en comble, afin de bien séparer les trois noms : DuskVM, DuskEVM et DuskDS. Au début, je pensais que ce n’était que « une chaîne qui soit compatible avec deux machines virtuelles », mais en réalité, la répartition ressemble plutôt à trois couches : DuskDS gère le consensus, la finalité et la disponibilité des données ; DuskVM permet d’exécuter directement, sur la L1, des contrats Rust/WASM ; et DuskEVM fournit un environnement d’exécution équivalent à l’EVM, basé sur OP Stack, en confiant au DuskDS le règlement et la publication des données.
Cela signifie que, pour les développeurs, il ne s’agit pas de choisir aveuglément l’une ou l’autre option. Si vous avez déjà des contrats Solidity, des dépendances liées aux portefeuilles et aux outils EVM, alors passer par DuskEVM coûte moins cher. En revanche, si vous devez toucher directement aux actifs de la L1, au modèle de confidentialité de Phoenix, aux capacités de ZK, ou à des contrôles plus bas niveau des protocoles, alors DuskVM est l’entrée native. Les deux voies partagent la même base de règlement, mais cela ne veut pas dire que les fonctions et les hypothèses de sécurité sont exactement identiques.
Je me méfie particulièrement de l’affirmation « EVM compatible = l’écosystème arrive automatiquement ». La compatibilité réduit seulement le seuil de déploiement ; elle ne remplace pas la connexion du portefeuille, les RPC stables, les indexeurs, la liquidité et les utilisateurs réels. À l’inverse, ne mettre en avant que le natif Rust/ZK ne suffit pas non plus : les outils sont trop “rugueux”, et les développeurs ne vont pas réécrire tout leur produit pour une question de pureté technique.
Donc, en regardant les progrès techniques de $DUSK , j’ai tendance à fragmenter les indicateurs : DuskEVM dispose-t-il d’applications Solidity tierces ? DuskVM a-t-il des contrats non officiels ? Le chemin de règlement vers DuskDS des deux côtés est-il stable ? Si la “douve” de #dusk se confirme, elle devrait être : « on peut entrer quand on connaît les outils, et on peut encore descendre quand on a besoin de confidentialité », pas trois nouveaux noms empilés. Vous choisirez d’abord la compatibilité, ou les capacités natives ?
Cela signifie que, pour les développeurs, il ne s’agit pas de choisir aveuglément l’une ou l’autre option. Si vous avez déjà des contrats Solidity, des dépendances liées aux portefeuilles et aux outils EVM, alors passer par DuskEVM coûte moins cher. En revanche, si vous devez toucher directement aux actifs de la L1, au modèle de confidentialité de Phoenix, aux capacités de ZK, ou à des contrôles plus bas niveau des protocoles, alors DuskVM est l’entrée native. Les deux voies partagent la même base de règlement, mais cela ne veut pas dire que les fonctions et les hypothèses de sécurité sont exactement identiques.
Je me méfie particulièrement de l’affirmation « EVM compatible = l’écosystème arrive automatiquement ». La compatibilité réduit seulement le seuil de déploiement ; elle ne remplace pas la connexion du portefeuille, les RPC stables, les indexeurs, la liquidité et les utilisateurs réels. À l’inverse, ne mettre en avant que le natif Rust/ZK ne suffit pas non plus : les outils sont trop “rugueux”, et les développeurs ne vont pas réécrire tout leur produit pour une question de pureté technique.
Donc, en regardant les progrès techniques de $DUSK , j’ai tendance à fragmenter les indicateurs : DuskEVM dispose-t-il d’applications Solidity tierces ? DuskVM a-t-il des contrats non officiels ? Le chemin de règlement vers DuskDS des deux côtés est-il stable ? Si la “douve” de #dusk se confirme, elle devrait être : « on peut entrer quand on connaît les outils, et on peut encore descendre quand on a besoin de confidentialité », pas trois nouveaux noms empilés. Vous choisirez d’abord la compatibilité, ou les capacités natives ?
