#dusk $DUSK La semaine dernière, en regardant la direction technique de DuskEVM, je ne pensais pas à « une nouvelle couche de compatibilité avec EVM », mais plutôt à la question de savoir à quel problème cette compatibilité répond réellement.
La plus grande inquiétude des institutions concernant les chaînes de confidentialité n’est pas la capacité technique : c’est le coût de migration. Les contrats qui tournent déjà sur Ethereum, le code qui a été audité, et les outils de développement auxquels on est habitué — tout cela implique de tout reconstruire pour s’adapter à un nouvel environnement d’exécution. Personne n’est prêt à absorber ce coût irrécupérable. L’approche de DuskEVM est l’inverse : déployer les contrats Solidity tels quels, tandis que le règlement au niveau inférieur continue de passer par le registre de confidentialité natif de DUSK. Cela signifie que les institutions n’ont pas besoin de réécrire la logique métier : il leur suffit de remplacer la couche de règlement par un réseau natif qui supporte à la fois les double registres Phoenix/Moonlight. Ainsi, les barrières pour les développeurs sont fortement réduites.
Mais la compatibilité n’est pas une intégration transparente. Les contrats EVM s’exécutent de façon transparente : tous les changements d’état sont visibles. Cela crée naturellement des frictions d’interface avec la logique de masquage par preuves à connaissance nulle de Phoenix. Si un contrat doit appeler un solde ou des données de positions stockées dans le registre de confidentialité, il y a forcément, au milieu, une sorte de « couche de traduction ». Le point clé est de savoir combien d’informations cette traduction expose : est-ce qu’elle devient une nouvelle surface d’attaque ? Les documents publics ne fournissent pas assez de détails pour l’instant. La compatibilité résout le problème de la migration côté développement, mais ne règle pas automatiquement la transmission de la confidentialité et de la conformité : ce sont deux sujets essentiellement distincts.$SPCXB
Ce qui m’intéresse davantage, c’est comment, une fois l’exécution découplée du règlement, on doit calculer la tarification du Gas et les risques liés au MEV. Si l’ordre d’exécution côté EVM peut être observé, même si le règlement de base cache les montants, l’intention de la transaction et le chemin d’appel peuvent encore être déduits. Pour les institutions qui mènent des stratégies à haute fréquence ou gèrent de grands volumes d’actifs, ce « trou » présente un risque essentiellement équivalent à « l’exposition directe des positions », la différence étant seulement le niveau de dissimulation, ce qui le rend facile à sous-estimer.$SNDKB
Donc, mon avis sur DuskEVM est le suivant : il réduit la barrière de migration pour les développeurs, mais pas le seuil de confiance des décideurs institutionnels. Ces derniers doivent pouvoir voir les résultats d’audit précis de la couche de traduction, ainsi que, dans des scénarios d’appel réels, jusqu’à quel niveau les frontières de confidentialité peuvent être réellement garanties. Ces données n’ont pas encore été validées publiquement : il faut continuer à suivre l’évolution, plutôt que de prendre la compatibilité elle-même comme conclusion.
#dusk @Dusk
La plus grande inquiétude des institutions concernant les chaînes de confidentialité n’est pas la capacité technique : c’est le coût de migration. Les contrats qui tournent déjà sur Ethereum, le code qui a été audité, et les outils de développement auxquels on est habitué — tout cela implique de tout reconstruire pour s’adapter à un nouvel environnement d’exécution. Personne n’est prêt à absorber ce coût irrécupérable. L’approche de DuskEVM est l’inverse : déployer les contrats Solidity tels quels, tandis que le règlement au niveau inférieur continue de passer par le registre de confidentialité natif de DUSK. Cela signifie que les institutions n’ont pas besoin de réécrire la logique métier : il leur suffit de remplacer la couche de règlement par un réseau natif qui supporte à la fois les double registres Phoenix/Moonlight. Ainsi, les barrières pour les développeurs sont fortement réduites.
Mais la compatibilité n’est pas une intégration transparente. Les contrats EVM s’exécutent de façon transparente : tous les changements d’état sont visibles. Cela crée naturellement des frictions d’interface avec la logique de masquage par preuves à connaissance nulle de Phoenix. Si un contrat doit appeler un solde ou des données de positions stockées dans le registre de confidentialité, il y a forcément, au milieu, une sorte de « couche de traduction ». Le point clé est de savoir combien d’informations cette traduction expose : est-ce qu’elle devient une nouvelle surface d’attaque ? Les documents publics ne fournissent pas assez de détails pour l’instant. La compatibilité résout le problème de la migration côté développement, mais ne règle pas automatiquement la transmission de la confidentialité et de la conformité : ce sont deux sujets essentiellement distincts.$SPCXB
Ce qui m’intéresse davantage, c’est comment, une fois l’exécution découplée du règlement, on doit calculer la tarification du Gas et les risques liés au MEV. Si l’ordre d’exécution côté EVM peut être observé, même si le règlement de base cache les montants, l’intention de la transaction et le chemin d’appel peuvent encore être déduits. Pour les institutions qui mènent des stratégies à haute fréquence ou gèrent de grands volumes d’actifs, ce « trou » présente un risque essentiellement équivalent à « l’exposition directe des positions », la différence étant seulement le niveau de dissimulation, ce qui le rend facile à sous-estimer.$SNDKB
Donc, mon avis sur DuskEVM est le suivant : il réduit la barrière de migration pour les développeurs, mais pas le seuil de confiance des décideurs institutionnels. Ces derniers doivent pouvoir voir les résultats d’audit précis de la couche de traduction, ainsi que, dans des scénarios d’appel réels, jusqu’à quel niveau les frontières de confidentialité peuvent être réellement garanties. Ces données n’ont pas encore été validées publiquement : il faut continuer à suivre l’évolution, plutôt que de prendre la compatibilité elle-même comme conclusion.
#dusk @Dusk
DuskEVM会成为迁移首选吗
0%
③MEV风险是不是被低估了
0%
隐私和兼容能不能两全
0%
0 Votes • Vote fermé