“EVM compatible” a résolu une partie du problème pour permettre aux développeurs d’entrer. Ce que Hedger doit résoudre, c’est : une fois que les institutions sont entrées, quelles données ne devraient pas être rendues publiques
Récemment, je suis tombé sur une analyse de DuskEVM. L’auteur a dit une phrase qui m’a fait réfléchir longtemps : « L’EVM compatible ne résout qu’une moitié du problème ».
Solidity, Foundry, Hardhat : ces outils permettent aux développeurs de reprendre l’écosystème d’outils Ethereum familier. Mais l’auteur a soulevé une question plus sensible : les institutions sont-elles vraiment prêtes à rendre publiques, à l’intégralité, leurs soldes, leurs positions et le montant de leurs transactions ?
Plus j’y réfléchis, plus je pense que c’est la contradiction centrale du secteur RWA. Vous demandez aux institutions de mettre des titres on-chain : ce n’est pas la partie technique qui pose problème. Le problème, c’est qu’après la mise en chaîne, toutes les données de transaction sont observées par tout le monde — la position, les contreparties, les flux de fonds : tout est transparent. Dans le marché financier traditionnel, cela est inacceptable.
@Dusk
La réponse apportée par le module Hedger de Dusk est la suivante : le chiffrement homomorphe permet de participer aux calculs tout en conservant les données chiffrées, et les preuves à connaissance nulle servent à prouver que le résultat respecte les règles. Les données ne doivent pas forcément être publiques, mais l’exécution peut néanmoins être vérifiée.
Pour les teneurs de marché, cela permet de masquer les positions sensibles ; pour les institutions financières, de protéger les soldes confidentiels ; et quand il faut auditer, d’autoriser la divulgation. Sur le plan logique, cette conception résout bien le « paradoxe confidentialité-conformité ».
Mais le problème, c’est qu’à l’heure actuelle, Hedger est encore cantonné au testnet. Une fonctionnalité encore en phase de test a été intégrée au récit central de RWA côté institution. Chiffrement homomorphe + preuves à connaissance nulle : sur le papier, l’ensemble fonctionne. Mais entre le fait que la théorie soit correcte et le moment où les institutions commencent réellement à l’utiliser, il manque encore trois étapes : faire tourner le réseau principal, passer des tests de charge, et obtenir la reconnaissance du régulateur.
L’« EVM compatibility » résout la question de savoir comment les développeurs peuvent entrer. Ce que Hedger doit résoudre, ce sont, une fois les institutions entrées, les données qui ne devraient tout simplement pas être rendues publiques. Si le réseau principal de DuskEVM parvient finalement à faire fonctionner ce workflow EVM confidentiel, c’est là que je pense qu’il se crée une véritable différence. D’ici là, « l’EVM compatible » ne résout que la moitié du problème.
#dusk $DUSK
Récemment, je suis tombé sur une analyse de DuskEVM. L’auteur a dit une phrase qui m’a fait réfléchir longtemps : « L’EVM compatible ne résout qu’une moitié du problème ».
Solidity, Foundry, Hardhat : ces outils permettent aux développeurs de reprendre l’écosystème d’outils Ethereum familier. Mais l’auteur a soulevé une question plus sensible : les institutions sont-elles vraiment prêtes à rendre publiques, à l’intégralité, leurs soldes, leurs positions et le montant de leurs transactions ?
Plus j’y réfléchis, plus je pense que c’est la contradiction centrale du secteur RWA. Vous demandez aux institutions de mettre des titres on-chain : ce n’est pas la partie technique qui pose problème. Le problème, c’est qu’après la mise en chaîne, toutes les données de transaction sont observées par tout le monde — la position, les contreparties, les flux de fonds : tout est transparent. Dans le marché financier traditionnel, cela est inacceptable.
@Dusk
La réponse apportée par le module Hedger de Dusk est la suivante : le chiffrement homomorphe permet de participer aux calculs tout en conservant les données chiffrées, et les preuves à connaissance nulle servent à prouver que le résultat respecte les règles. Les données ne doivent pas forcément être publiques, mais l’exécution peut néanmoins être vérifiée.
Pour les teneurs de marché, cela permet de masquer les positions sensibles ; pour les institutions financières, de protéger les soldes confidentiels ; et quand il faut auditer, d’autoriser la divulgation. Sur le plan logique, cette conception résout bien le « paradoxe confidentialité-conformité ».
Mais le problème, c’est qu’à l’heure actuelle, Hedger est encore cantonné au testnet. Une fonctionnalité encore en phase de test a été intégrée au récit central de RWA côté institution. Chiffrement homomorphe + preuves à connaissance nulle : sur le papier, l’ensemble fonctionne. Mais entre le fait que la théorie soit correcte et le moment où les institutions commencent réellement à l’utiliser, il manque encore trois étapes : faire tourner le réseau principal, passer des tests de charge, et obtenir la reconnaissance du régulateur.
L’« EVM compatibility » résout la question de savoir comment les développeurs peuvent entrer. Ce que Hedger doit résoudre, ce sont, une fois les institutions entrées, les données qui ne devraient tout simplement pas être rendues publiques. Si le réseau principal de DuskEVM parvient finalement à faire fonctionner ce workflow EVM confidentiel, c’est là que je pense qu’il se crée une véritable différence. D’ici là, « l’EVM compatible » ne résout que la moitié du problème.
#dusk $DUSK
