Beaucoup de gens se plaignent que le #dusk EVM serait « un retour en arrière ». Pour ma part, j’y vois au contraire le fait que l’équipe a enfin compris une chose : la compatibilité n’est pas une concession, c’est une manière de contrôler les coûts.
Construire de toutes pièces un nouvel environnement d’exécution : sur le plan technique, ce n’est peut-être pas inférieur à Ethereum, mais le prix à payer, c’est que tout l’écosystème de support doit être reconstruit — les cabinets d’audit doivent apprendre un nouveau langage pour produire leurs rapports, l’équipe du portefeuille doit réécrire la logique de signature, le service d’indexation doit être réadapté. Ces coûts finissent, au final, par être répercutés sur les organisations prêtes à déployer on-chain. Et quand une entreprise choisit une technologie, elle regarde d’abord : « Mon équipe actuelle peut-elle s’y mettre directement ? », plutôt que : « Cette langue est-elle conçue de façon élégante ? ».
@Dusk EVM est intelligent en ce qu’il sépare la couche d’exécution et les capacités sous-jacentes : les développeurs utilisent toujours des outils familiers pour déployer des contrats, mais tant qu’ils le veulent, ils peuvent appeler les fonctions natives d’un règlement confidentiel et les contrôles de conformité. En somme, on donne aux développeurs une option, pas une obligation de suivre un chemin unique. Les équipes qui ont déjà tokenisé sur Ethereum peuvent, en théorie, éviter de tout remettre en cause, reprendre moins de code et brancher directement la logique de règlement sur une chaîne conçue à l’origine pour des scénarios réglementés.
Mais je ne le surestimerai pas pour autant. Ajouter une couche de compatibilité, c’est ajouter une hypothèse de confiance supplémentaire. Dans les domaines où l’on communique entre couches et où l’on synchronise l’état, les accidents recensés historiquement ne sont pas moins nombreux que les failles de contrats. Le risque plus réaliste, lui, est que si la plupart des développeurs se contentent de copier leurs anciens projets à l’identique, en profitant surtout de la commodité de l’écosystème EVM, alors la capacité véritablement différenciante — le règlement confidentiel — sera mise de côté : $DUSK EVM n’aura alors pas grand-chose à voir avec une simple sidechain EVM ordinaire.
Donc je ne prête pas trop d’importance aux chiffres animés des déploiements de contrats. Ce que je veux savoir, c’est combien de ces contrats utilisent réellement les modules natifs de confidentialité et de conformité. Tant que ce ratio ne grimpe pas, l’histoire différenciante de DuskEVM restera seulement une option, sans devenir une réalité.
Construire de toutes pièces un nouvel environnement d’exécution : sur le plan technique, ce n’est peut-être pas inférieur à Ethereum, mais le prix à payer, c’est que tout l’écosystème de support doit être reconstruit — les cabinets d’audit doivent apprendre un nouveau langage pour produire leurs rapports, l’équipe du portefeuille doit réécrire la logique de signature, le service d’indexation doit être réadapté. Ces coûts finissent, au final, par être répercutés sur les organisations prêtes à déployer on-chain. Et quand une entreprise choisit une technologie, elle regarde d’abord : « Mon équipe actuelle peut-elle s’y mettre directement ? », plutôt que : « Cette langue est-elle conçue de façon élégante ? ».
@Dusk EVM est intelligent en ce qu’il sépare la couche d’exécution et les capacités sous-jacentes : les développeurs utilisent toujours des outils familiers pour déployer des contrats, mais tant qu’ils le veulent, ils peuvent appeler les fonctions natives d’un règlement confidentiel et les contrôles de conformité. En somme, on donne aux développeurs une option, pas une obligation de suivre un chemin unique. Les équipes qui ont déjà tokenisé sur Ethereum peuvent, en théorie, éviter de tout remettre en cause, reprendre moins de code et brancher directement la logique de règlement sur une chaîne conçue à l’origine pour des scénarios réglementés.
Mais je ne le surestimerai pas pour autant. Ajouter une couche de compatibilité, c’est ajouter une hypothèse de confiance supplémentaire. Dans les domaines où l’on communique entre couches et où l’on synchronise l’état, les accidents recensés historiquement ne sont pas moins nombreux que les failles de contrats. Le risque plus réaliste, lui, est que si la plupart des développeurs se contentent de copier leurs anciens projets à l’identique, en profitant surtout de la commodité de l’écosystème EVM, alors la capacité véritablement différenciante — le règlement confidentiel — sera mise de côté : $DUSK EVM n’aura alors pas grand-chose à voir avec une simple sidechain EVM ordinaire.
Donc je ne prête pas trop d’importance aux chiffres animés des déploiements de contrats. Ce que je veux savoir, c’est combien de ces contrats utilisent réellement les modules natifs de confidentialité et de conformité. Tant que ce ratio ne grimpe pas, l’histoire différenciante de DuskEVM restera seulement une option, sans devenir une réalité.