#dusk $DUSK Aujourd’hui, en étudiant la machine virtuelle Piecrust de Dusk, une question m’est restée en tête : si DuskEVM est compatible avec Ethereum, en quoi se distingue-t-il des dizaines de chaînes compatibles EVM disponibles sur le marché ? N’est-ce pas, dans tous les cas, permettre aux développeurs Solidity de migrer ? En regardant plus attentivement la logique de conception de Piecrust, je me suis rendu compte que cette “compatibilité” est bien plus profonde que ce que j’imaginais.
La plupart des chaînes compatibles EVM adoptent une approche du type “si les contrats Ethereum peuvent tourner, alors c’est bon”, en considérant la compatibilité comme une simple option. Mais la position de Piecrust est complètement différente : il s’agit d’un environnement d’exécution EVM nativement intégré à une chaîne de confidentialité basée sur UTXO. Cela signifie que les smart contracts écrits en Solidity peuvent directement appeler les fonctionnalités de confidentialité natives de Dusk : manipuler des notes chiffrées au niveau du contrat, déclencher la génération et la vérification des preuves à connaissance zéro, et lire/écrire l’état privé de Phoenix. Ce n’est pas du tout la même chose que “faire tourner un EVM sur une chaîne transparente”.
Cela m’a fait penser à une discussion que j’ai eue il y a un mois avec un ami qui travaille sur la DeFi. Il m’a dit que leur équipe voulait mettre en place, on-chain, des transactions de dark pools “au niveau institutionnel”. Le principal obstacle, selon lui, n’était pas l’algorithme de matching, mais le fait que les smart contracts ne peuvent pas gérer à la fois la “confidentialité des positions” et “la divulgation sélective” : sur une chaîne publique, tout ce qui est écrit est transparent ; sur une chaîne de confidentialité, en revanche, on ne peut pas exécuter une logique de contrat complexe. Si la conception de Piecrust peut vraiment être concrétisée, cela revient à construire un pont entre “confidentialité” et “programmabilité” : ce n’est pas l’un ou l’autre, c’est les deux.
Mais le coût est aussi bien réel : la complexité de cette architecture est d’un ordre de grandeur supérieur à celle d’une chaîne EVM classique. Une fois arrivés, les développeurs doivent déjà passer beaucoup de temps à comprendre le cycle de vie des notes UTXO et la logique de consommation des nullifiers. L’inertie liée au “cold start” de l’écosystème est aussi loin d’être négligeable.
Pour l’instant, on a gardé une réserve de base (“bottom”) : l’équipe attendra de voir des données mesurées en conditions réelles—le code des premiers prototypes DeFi tournant sur Piecrust et les relevés de consommation de gas—avant de décider du passage à l’échelle.
Et vous, pensez-vous que ce duo “confidentialité + programmabilité” est un vrai besoin pour les développeurs DeFi, ou une fausse bonne idée ? Dites-moi dans les commentaires. @Dusk $BTC
La plupart des chaînes compatibles EVM adoptent une approche du type “si les contrats Ethereum peuvent tourner, alors c’est bon”, en considérant la compatibilité comme une simple option. Mais la position de Piecrust est complètement différente : il s’agit d’un environnement d’exécution EVM nativement intégré à une chaîne de confidentialité basée sur UTXO. Cela signifie que les smart contracts écrits en Solidity peuvent directement appeler les fonctionnalités de confidentialité natives de Dusk : manipuler des notes chiffrées au niveau du contrat, déclencher la génération et la vérification des preuves à connaissance zéro, et lire/écrire l’état privé de Phoenix. Ce n’est pas du tout la même chose que “faire tourner un EVM sur une chaîne transparente”.
Cela m’a fait penser à une discussion que j’ai eue il y a un mois avec un ami qui travaille sur la DeFi. Il m’a dit que leur équipe voulait mettre en place, on-chain, des transactions de dark pools “au niveau institutionnel”. Le principal obstacle, selon lui, n’était pas l’algorithme de matching, mais le fait que les smart contracts ne peuvent pas gérer à la fois la “confidentialité des positions” et “la divulgation sélective” : sur une chaîne publique, tout ce qui est écrit est transparent ; sur une chaîne de confidentialité, en revanche, on ne peut pas exécuter une logique de contrat complexe. Si la conception de Piecrust peut vraiment être concrétisée, cela revient à construire un pont entre “confidentialité” et “programmabilité” : ce n’est pas l’un ou l’autre, c’est les deux.
Mais le coût est aussi bien réel : la complexité de cette architecture est d’un ordre de grandeur supérieur à celle d’une chaîne EVM classique. Une fois arrivés, les développeurs doivent déjà passer beaucoup de temps à comprendre le cycle de vie des notes UTXO et la logique de consommation des nullifiers. L’inertie liée au “cold start” de l’écosystème est aussi loin d’être négligeable.
Pour l’instant, on a gardé une réserve de base (“bottom”) : l’équipe attendra de voir des données mesurées en conditions réelles—le code des premiers prototypes DeFi tournant sur Piecrust et les relevés de consommation de gas—avant de décider du passage à l’échelle.
Et vous, pensez-vous que ce duo “confidentialité + programmabilité” est un vrai besoin pour les développeurs DeFi, ou une fausse bonne idée ? Dites-moi dans les commentaires. @Dusk $BTC
A. 真需求,机构入场必须标配
0%
B. 伪需求,DeFi核心就是透明
0%
C. 看开发者工具好不好用再说
0%
D. 先看有没有实际项目跑出来
0%
0 Votes • Vote fermé