Le 10 août @Dusk a rejoint le réseau de test DuskEVM. Les développeurs peuvent y déployer avec Solidity et Hardhat. Ma première réaction : c’est un peu étrange.
Étrange… pourquoi ? @Dusk a passé plus de sept ans à construire un L1 natif axé sur la confidentialité : DuskVM exécute du Rust et du WASM, et la confidentialité « grandit » depuis la couche de transition d’état, c’est sa différenciation la plus solide. Et maintenant, ils ajoutent une couche de compatibilité EVM — autrement dit, ils admettent implicitement : « les outils que vous utilisez devraient être ceux d’Ethereum ». On dirait un compromis.
J’ai ensuite changé d’avis. Parce que la vérité est difficile à entendre, mais elle est là : sans avantage technique des développeurs, ce n’est pas un avantage.
Les développeurs Solidity, et ceux du camp Rust + WASM, ne sont pas en même nombre. Faire réapprendre le Rust, réécrire les processus d’audit, et remplacer les outils de test à une équipe qui a déjà intégré Aave pour ses capacités de confidentialité : la plupart renonceront. Si vous n’entrez pas dans le workflow des autres, c’est zéro.
DuskEVM s’appuie sur OP Stack : le règlement et la disponibilité des données reviennent à DuskDS. La répartition est claire : la couche basse gère les invariants de confidentialité et la finalité, la couche haute gère l’expérience développeur. Ce qui m’inquiète vraiment, c’est la fissure entre les deux.
Avec Solidity, quelle quantité de capacités de confidentialité peut-on obtenir ? Même niveau que les contrats natifs DuskEVM, ou une version dégradée ? Plus important encore : les actifs entre couches — des titres tokenisés dont les transactions ont eu lieu au niveau EVM — ceux dont la liste blanche, les limites de position, et les restrictions de juridiction sont codées en natif : est-ce qu’ils sont encore reconnus ?
Si une chaîne intègre la conformité dans les actifs au niveau L1, mais que la couche d’exécution L2 n’arrive pas à l’exprimer, alors c’est comme si on avait ouvert une porte de contournement. Ce n’est pas un problème propre à Dusk, mais pour une chaîne qui vend du « natif conforme », c’est particulièrement crucial.
Données de référence : mise en ligne du mainnet le 7 janvier 2025. La TVL de Sozu tourne autour de 43 millions, annualisée à environ 33 %. C’est une synthèse via des canaux publics, pas un test en conditions réelles on-chain.
En regardant froidement : DuskEVM est encore en testnet, et aucune application de niveau institutionnel n’a encore réellement tourné. L’interface de compatibilité est-elle pratique ? Il faudra attendre que quelqu’un y écrive de la complexité réelle.
Si vous étiez développeur, échangeriez-vous la capacité de confidentialité d’une chaîne contre un changement de langage et de chaîne d’outils ? Ou attendriez-vous qu’ils aient vraiment aplani la route EVM avant de décider ? Dites la vérité.
#dusk $DUSK @Dusk
Étrange… pourquoi ? @Dusk a passé plus de sept ans à construire un L1 natif axé sur la confidentialité : DuskVM exécute du Rust et du WASM, et la confidentialité « grandit » depuis la couche de transition d’état, c’est sa différenciation la plus solide. Et maintenant, ils ajoutent une couche de compatibilité EVM — autrement dit, ils admettent implicitement : « les outils que vous utilisez devraient être ceux d’Ethereum ». On dirait un compromis.
J’ai ensuite changé d’avis. Parce que la vérité est difficile à entendre, mais elle est là : sans avantage technique des développeurs, ce n’est pas un avantage.
Les développeurs Solidity, et ceux du camp Rust + WASM, ne sont pas en même nombre. Faire réapprendre le Rust, réécrire les processus d’audit, et remplacer les outils de test à une équipe qui a déjà intégré Aave pour ses capacités de confidentialité : la plupart renonceront. Si vous n’entrez pas dans le workflow des autres, c’est zéro.
DuskEVM s’appuie sur OP Stack : le règlement et la disponibilité des données reviennent à DuskDS. La répartition est claire : la couche basse gère les invariants de confidentialité et la finalité, la couche haute gère l’expérience développeur. Ce qui m’inquiète vraiment, c’est la fissure entre les deux.
Avec Solidity, quelle quantité de capacités de confidentialité peut-on obtenir ? Même niveau que les contrats natifs DuskEVM, ou une version dégradée ? Plus important encore : les actifs entre couches — des titres tokenisés dont les transactions ont eu lieu au niveau EVM — ceux dont la liste blanche, les limites de position, et les restrictions de juridiction sont codées en natif : est-ce qu’ils sont encore reconnus ?
Si une chaîne intègre la conformité dans les actifs au niveau L1, mais que la couche d’exécution L2 n’arrive pas à l’exprimer, alors c’est comme si on avait ouvert une porte de contournement. Ce n’est pas un problème propre à Dusk, mais pour une chaîne qui vend du « natif conforme », c’est particulièrement crucial.
Données de référence : mise en ligne du mainnet le 7 janvier 2025. La TVL de Sozu tourne autour de 43 millions, annualisée à environ 33 %. C’est une synthèse via des canaux publics, pas un test en conditions réelles on-chain.
En regardant froidement : DuskEVM est encore en testnet, et aucune application de niveau institutionnel n’a encore réellement tourné. L’interface de compatibilité est-elle pratique ? Il faudra attendre que quelqu’un y écrive de la complexité réelle.
Si vous étiez développeur, échangeriez-vous la capacité de confidentialité d’une chaîne contre un changement de langage et de chaîne d’outils ? Ou attendriez-vous qu’ils aient vraiment aplani la route EVM avant de décider ? Dites la vérité.
#dusk $DUSK @Dusk
