En relisant @Dusk , ce qui m’a vraiment fait m’arrêter n’est pas la technologie de confidentialité, mais une question plus concrète : une fois que des actifs comme les titres sont “tokenisés” sur la blockchain, les critères d’éligibilité des investisseurs, les restrictions de transfert et la divulgation d’informations peuvent-ils devenir directement des règles on-chain ?
Le modèle Phoenix de Dusk m’apporte une réponse plutôt intéressante. Les transactions peuvent masquer les parties impliquées et les montants, tout en permettant une divulgation ciblée via une “viewing key”. Pour les actifs financiers, cela est plus utile que de chercher uniquement “à ce que tout le monde ne voie rien”, car la régulation n’a souvent pas besoin de toutes les données : elle a besoin, dans des conditions particulières, de pouvoir vérifier des données spécifiques. Moonlight conserve quant à lui le modèle de comptes publics, tandis que DuskDS s’occupe du règlement sous-jacent ; ces deux modes peuvent servir à différents types d’activités.
Mais je pense aussi que le plus grand avantage de cette conception — et, potentiellement, sa plus grande barrière à l’écosystème — est là. DuskVM est orientée Rust et WASM, ce qui convient aux applications natives de confidentialité et aux usages de la preuve à divulgation nulle (zero-knowledge). DuskEVM, de son côté, est compatible avec Solidity et les outils EVM existants. Plus de choix ne signifie pas forcément un développement plus simple : si l’équipe finit par utiliser principalement l’EVM, l’écart technique de Dusk risque d’être atténué. La question la plus réaliste reste le coût de calcul des preuves à connaissance nulle, ainsi que les exigences du Prover en ressources matérielles : ce sont aussi des enjeux d’ingénierie à résoudre pour passer à l’échelle.
Côté token, je m’intéresse davantage aux besoins d’utilisation concrets de $DUSK qu’à l’observation seule de l’offre. En tant qu’actif natif du réseau, DUSK est directement lié aux fonctions du réseau comme les frais de transaction et le staking. Cela signifie que sa capacité à porter une valeur élevée dépend, dans une large mesure, de la question de savoir si le réseau continue d’augmenter ses activités réelles. Le design officiel de l’offre utilise un mécanisme de libération sur le long terme, avec une limite de 1 milliard de tokens. Pour moi, ces chiffres ne sont pas l’enjeu principal : ce qui mérite vraiment d’être observé, c’est si, à l’avenir, l’usage du réseau pourra correspondre aux besoins fonctionnels des tokens.
En reconsidérant Dusk, je me demande surtout s’il peut intégrer réellement la confidentialité, l’identité et les règles relatives aux actifs dans le flux quotidien des activités financières. La capacité technique sert à répondre à “peut-on le faire”, tandis que l’adoption réelle répond à “est-ce nécessaire de le faire”. Pour Dusk, la chose la plus intéressante à surveiller ensuite n’est peut-être pas d’ajouter davantage de modules techniques, mais de voir s’il y aura de plus en plus d’actifs réels prêts à rester. #dusk
Le modèle Phoenix de Dusk m’apporte une réponse plutôt intéressante. Les transactions peuvent masquer les parties impliquées et les montants, tout en permettant une divulgation ciblée via une “viewing key”. Pour les actifs financiers, cela est plus utile que de chercher uniquement “à ce que tout le monde ne voie rien”, car la régulation n’a souvent pas besoin de toutes les données : elle a besoin, dans des conditions particulières, de pouvoir vérifier des données spécifiques. Moonlight conserve quant à lui le modèle de comptes publics, tandis que DuskDS s’occupe du règlement sous-jacent ; ces deux modes peuvent servir à différents types d’activités.
Mais je pense aussi que le plus grand avantage de cette conception — et, potentiellement, sa plus grande barrière à l’écosystème — est là. DuskVM est orientée Rust et WASM, ce qui convient aux applications natives de confidentialité et aux usages de la preuve à divulgation nulle (zero-knowledge). DuskEVM, de son côté, est compatible avec Solidity et les outils EVM existants. Plus de choix ne signifie pas forcément un développement plus simple : si l’équipe finit par utiliser principalement l’EVM, l’écart technique de Dusk risque d’être atténué. La question la plus réaliste reste le coût de calcul des preuves à connaissance nulle, ainsi que les exigences du Prover en ressources matérielles : ce sont aussi des enjeux d’ingénierie à résoudre pour passer à l’échelle.
Côté token, je m’intéresse davantage aux besoins d’utilisation concrets de $DUSK qu’à l’observation seule de l’offre. En tant qu’actif natif du réseau, DUSK est directement lié aux fonctions du réseau comme les frais de transaction et le staking. Cela signifie que sa capacité à porter une valeur élevée dépend, dans une large mesure, de la question de savoir si le réseau continue d’augmenter ses activités réelles. Le design officiel de l’offre utilise un mécanisme de libération sur le long terme, avec une limite de 1 milliard de tokens. Pour moi, ces chiffres ne sont pas l’enjeu principal : ce qui mérite vraiment d’être observé, c’est si, à l’avenir, l’usage du réseau pourra correspondre aux besoins fonctionnels des tokens.
En reconsidérant Dusk, je me demande surtout s’il peut intégrer réellement la confidentialité, l’identité et les règles relatives aux actifs dans le flux quotidien des activités financières. La capacité technique sert à répondre à “peut-on le faire”, tandis que l’adoption réelle répond à “est-ce nécessaire de le faire”. Pour Dusk, la chose la plus intéressante à surveiller ensuite n’est peut-être pas d’ajouter davantage de modules techniques, mais de voir s’il y aura de plus en plus d’actifs réels prêts à rester. #dusk