J’ai encore relu hier le document de @Dusk et, franchement, ça m’a un peu mis dans un état de “décrochage”.
D’un côté, ils disent être dans la “privacy track”, et la solution de Phoenix avec UTXO plus preuves à connaissance zéro est vraiment solide : les infos de transfert sont soigneusement protégées. Puis, juste après, ils bricolent un DuskEVM compatible Solidity, clairement pour capter le flux des développeurs d’Ethereum. Et même l’officiel le dit : le modèle de compte et l’UTXO ne sont pas du tout la même espèce en matière de confidentialité. Donc la compatibilité “à fond” implique de sacrifier l’anonymat. C’est là que ça devient gênant : développer avec l’outil EVM, c’est ultra simple, mais la privacy n’est plus qu’à moitié ; si on veut une confidentialité vérifiable et réellement audit-able, il faut s’attaquer aux barrières de l’environnement natif, et se retrouver coincé entre les deux, c’est assez inconfortable.
Côté nœud, c’est encore plus tortueux. Avec le consensus Succinct Attestation, miser 1000 DUSK te donne le rôle de Provisioner : le seuil a l’air très abordable, et même les particuliers peuvent essayer. Mais si tu regardes plus haut, la vraie sortie de valeur : les canaux RWA, les licences NPEX, la vérification d’identité conforme, tout est entre les mains d’institutions. La couche de base est un PoS permissionless, la couche supérieure est un club permissionné. Dans ce type d’architecture, je n’ai pas encore compris comment le token pourrait capturer de la valeur.
Et il y a aussi cette émission native, avec une ambition franchement énorme. Leur intention n’est pas simplement d’émettre un token, mais d’embarquer dans une machine à états tout : liste blanche, view key, transferts contrôlés, et règlement/livraison. Dans l’idéal, les titres privés placés en privé n’auraient plus besoin de comptabilité hors chaîne, mais le problème, c’est la validité juridique et des sujets comme la garde et la reconnaissance : aussi élégant que soit le déroulement on-chain, ça ne remplace pas ces aspects.
Honnêtement, les choix de Phoenix en matière de divulgation sélective, le basculement entre deux modèles de Moonlight, et la logique d’émission de Citadel sont, sur le plan du design, vraiment ingénieux. Mais l’expérience concrète montre une complexité non négligeable : pour un utilisateur lambda, ça a de fortes chances de décourager. Il y a de la place pour le récit de conformité dans le cadre du MiCA en Europe, j’admets. Mais est-ce que l’avantage technique pourra vraiment se traduire par de l’activité on-chain ? Ça dépendra surtout de la capacité de l’écosystème à tourner réellement.
Je continuerai à surveiller, mais avant que l’argent réel ne rentre, il faut d’abord démêler proprement ces logiques d’épine dorsale. #dusk $DUSK
D’un côté, ils disent être dans la “privacy track”, et la solution de Phoenix avec UTXO plus preuves à connaissance zéro est vraiment solide : les infos de transfert sont soigneusement protégées. Puis, juste après, ils bricolent un DuskEVM compatible Solidity, clairement pour capter le flux des développeurs d’Ethereum. Et même l’officiel le dit : le modèle de compte et l’UTXO ne sont pas du tout la même espèce en matière de confidentialité. Donc la compatibilité “à fond” implique de sacrifier l’anonymat. C’est là que ça devient gênant : développer avec l’outil EVM, c’est ultra simple, mais la privacy n’est plus qu’à moitié ; si on veut une confidentialité vérifiable et réellement audit-able, il faut s’attaquer aux barrières de l’environnement natif, et se retrouver coincé entre les deux, c’est assez inconfortable.
Côté nœud, c’est encore plus tortueux. Avec le consensus Succinct Attestation, miser 1000 DUSK te donne le rôle de Provisioner : le seuil a l’air très abordable, et même les particuliers peuvent essayer. Mais si tu regardes plus haut, la vraie sortie de valeur : les canaux RWA, les licences NPEX, la vérification d’identité conforme, tout est entre les mains d’institutions. La couche de base est un PoS permissionless, la couche supérieure est un club permissionné. Dans ce type d’architecture, je n’ai pas encore compris comment le token pourrait capturer de la valeur.
Et il y a aussi cette émission native, avec une ambition franchement énorme. Leur intention n’est pas simplement d’émettre un token, mais d’embarquer dans une machine à états tout : liste blanche, view key, transferts contrôlés, et règlement/livraison. Dans l’idéal, les titres privés placés en privé n’auraient plus besoin de comptabilité hors chaîne, mais le problème, c’est la validité juridique et des sujets comme la garde et la reconnaissance : aussi élégant que soit le déroulement on-chain, ça ne remplace pas ces aspects.
Honnêtement, les choix de Phoenix en matière de divulgation sélective, le basculement entre deux modèles de Moonlight, et la logique d’émission de Citadel sont, sur le plan du design, vraiment ingénieux. Mais l’expérience concrète montre une complexité non négligeable : pour un utilisateur lambda, ça a de fortes chances de décourager. Il y a de la place pour le récit de conformité dans le cadre du MiCA en Europe, j’admets. Mais est-ce que l’avantage technique pourra vraiment se traduire par de l’activité on-chain ? Ça dépendra surtout de la capacité de l’écosystème à tourner réellement.
Je continuerai à surveiller, mais avant que l’argent réel ne rentre, il faut d’abord démêler proprement ces logiques d’épine dorsale. #dusk $DUSK