#dusk La semaine dernière, lorsque j’ai configuré localement un nœud DuskEVM pour tester le script de déploiement, ma principale préoccupation concernait la visibilité des données dans les emplacements de stockage. Dans l’architecture Ethereum traditionnelle, l’arbre d’état global est entièrement transparent et consultable. Dès lors que la machine virtuelle respecte la sémantique standard de l’EVM, les propriétés de confidentialité revendiquées sur la chaîne ne peuvent pas s’appliquer automatiquement : il faut nécessairement s’appuyer sur des mécanismes de preuve supplémentaires.
L’architecture à deux voies de Dusk divise le réseau en plusieurs couches : le consensus et le règlement sont gérés de manière centralisée par la couche inférieure DuskDS, la DuskVM native traite les actifs confidentiels sur la chaîne en s’appuyant sur le protocole Phoenix et la norme XSC, tandis que la nouvelle DuskEVM n’est qu’un outil destiné à faciliter la migration. Cette approche modulaire évite certes d’avoir à remanier le code Rust, mais elle scinde la logique de sécurité, auparavant unifiée, en deux systèmes distincts.$DUSK
Le principal désaccord technique porte sur la répartition des responsabilités. Si, pour implémenter leur logique métier dans DuskEVM, les développeurs doivent appeler manuellement des modules externes tels que Citadel afin de générer des preuves à divulgation nulle de connaissance, cela signifie que la protection de la vie privée est transférée de la couche protocolaire au code applicatif. À la moindre erreur dans un contrat intelligent, les données essentielles relatives aux transactions et aux positions pourraient tout de même être exposées dans l’état public.$BTC
D’un point de vue technique, adopter Solidity permet effectivement d’attirer rapidement des développeurs, mais cette approche brouille aussi les véritables frontières des données. Pour les applications institutionnelles portant sur des actifs réels, rien n’est plus problématique que des règles floues. La coexistence de deux environnements d’exécution accroît au contraire le coût d’audit des appels d’actifs entre les couches ainsi que la surface d’attaque, et les développeurs doivent assumer eux-mêmes les risques liés à la conformité.$ETH
À mon avis, tout en élargissant la compatibilité, l’équipe doit rapidement préciser les normes de correspondance des états et de synchronisation de la confidentialité entre les deux couches. Un simple compromis technique aura du mal à convaincre les investisseurs institutionnels les plus rigoureux. Lors de la création d’applications confidentielles, accordez-vous davantage d’importance à la confidentialité intrinsèque du WASM natif ou préférez-vous la facilité de développement qu’offre la couche de compatibilité ?@Dusk
L’architecture à deux voies de Dusk divise le réseau en plusieurs couches : le consensus et le règlement sont gérés de manière centralisée par la couche inférieure DuskDS, la DuskVM native traite les actifs confidentiels sur la chaîne en s’appuyant sur le protocole Phoenix et la norme XSC, tandis que la nouvelle DuskEVM n’est qu’un outil destiné à faciliter la migration. Cette approche modulaire évite certes d’avoir à remanier le code Rust, mais elle scinde la logique de sécurité, auparavant unifiée, en deux systèmes distincts.$DUSK
Le principal désaccord technique porte sur la répartition des responsabilités. Si, pour implémenter leur logique métier dans DuskEVM, les développeurs doivent appeler manuellement des modules externes tels que Citadel afin de générer des preuves à divulgation nulle de connaissance, cela signifie que la protection de la vie privée est transférée de la couche protocolaire au code applicatif. À la moindre erreur dans un contrat intelligent, les données essentielles relatives aux transactions et aux positions pourraient tout de même être exposées dans l’état public.$BTC
D’un point de vue technique, adopter Solidity permet effectivement d’attirer rapidement des développeurs, mais cette approche brouille aussi les véritables frontières des données. Pour les applications institutionnelles portant sur des actifs réels, rien n’est plus problématique que des règles floues. La coexistence de deux environnements d’exécution accroît au contraire le coût d’audit des appels d’actifs entre les couches ainsi que la surface d’attaque, et les développeurs doivent assumer eux-mêmes les risques liés à la conformité.$ETH
À mon avis, tout en élargissant la compatibilité, l’équipe doit rapidement préciser les normes de correspondance des états et de synchronisation de la confidentialité entre les deux couches. Un simple compromis technique aura du mal à convaincre les investisseurs institutionnels les plus rigoureux. Lors de la création d’applications confidentielles, accordez-vous davantage d’importance à la confidentialité intrinsèque du WASM natif ou préférez-vous la facilité de développement qu’offre la couche de compatibilité ?@Dusk