Après avoir testé ce double compte avec échanges réciproques sur Dusk, j’ai senti un frisson dans le dos : la confidentialité, c’est pour servir les utilisateurs, pas pour que les développeurs puissent s’en prendre aux autres.
Hier soir, j’ai lu un post d’essai. L’auteur a fait des allers-retours entre la Moonlight de Dusk et Phoenix, et plus il jouait, plus ça devenait étrange.
Deux adresses dérivées du même set de seed (phrases mnémoniques) : l’une est transparente, comme dans un bocal en verre ; l’autre est une boîte noire, jusqu’au point où l’on ne voit même pas le solde. Côté utilisateur, il suffit d’appuyer sur « basculer » pour que tout passe, mais en réalité, au niveau des fondations du protocole, il tourne complètement sur deux logiques de comptabilité distinctes : Moonlight correspond à un modèle de compte, avec un solde directement écrit dans un smart contract ; Phoenix repose sur un schéma UTXO + note, en s’appuyant sur des engagements de Pedersen et des nullifiers.
@Dusk
Tu vois que c’est une conception géniale ? Oui. Mais essaie donc d’écrire un contrat de prêt dessus… Au moment du règlement, il faut gérer en même temps deux états : le solde ETH et les nullifiers des notes de confidentialité doivent être calculés ensemble. Écrire la logique Moonlight fait craindre que les gros portefeuilles se fassent cibler ; écrire la logique Phoenix, c’est risquer que la régulation coupe net tes interfaces. Dans la documentation, une phrase légère et creuse du genre « choisir selon le besoin »… pour les développeurs, ça donne juste envie d’engueuler. Ce n’est pas de la modularité : c’est faire payer le prix aux écosystèmes.
Ce qui me glace encore plus, c’est une autre analyse. L’histoire des tokens de titres (securities) de NPEX est plutôt bien racontée, mais au final tout le monde finit cramponné à Moonlight. Les gens de la MiCA exigent même des audits trimestriels des réserves des stablecoins ; et tu leur dis « j’ai un zk-proof pour choisir une vue anonymisée » ? Leur première réaction, côté régulateur, sera toujours : est-ce que le code peut exporter un Excel en un clic ? La « divulgation sélective » de Phoenix, aux yeux des juristes, ressemble à une boîte noire technique : en cas de pépin, qui signe ? Les institutions ne sont pas naïves : avec de l’argent réel en jeu, elles préféreront courir à poil, mais pouvoir attribuer clairement les responsabilités.
Aujourd’hui, le taux de staking on-chain est de 36%, ça a l’air correct, mais dans le milieu tout le monde sait que c’est surtout du self-hype de la part des nœuds. DuskEVM est déployé, certes. Mais si, l’année prochaine, la colonne Phoenix reste vide dans la liste des Dapp, ce projet se transformera en une chaîne EVM avec plugin de confidentialité — et le récit s’effondrera quasiment à moitié.
Je ne dis pas que la technologie ne va pas : le couplage UTXO + ZK, c’est vraiment du costaud. Mais l’absence de réponse par défaut côté produit, c’est le plus gros échec. Un utilisateur lambda n’arrive même pas à retenir sa phrase mnémonique : tu veux en plus qu’il se demande à chaque transfert, « aujourd’hui, j’active ou non la confidentialité ? »
Je pensais à mettre un dossier d’observation, mais finalement je retire. On verra quand on aura le premier exemple où quelqu’un jette la liquidité centrale dans Phoenix, et obtient en même temps une validation écrite de la part de la régulation européenne.
#dusk $DUSK
Hier soir, j’ai lu un post d’essai. L’auteur a fait des allers-retours entre la Moonlight de Dusk et Phoenix, et plus il jouait, plus ça devenait étrange.
Deux adresses dérivées du même set de seed (phrases mnémoniques) : l’une est transparente, comme dans un bocal en verre ; l’autre est une boîte noire, jusqu’au point où l’on ne voit même pas le solde. Côté utilisateur, il suffit d’appuyer sur « basculer » pour que tout passe, mais en réalité, au niveau des fondations du protocole, il tourne complètement sur deux logiques de comptabilité distinctes : Moonlight correspond à un modèle de compte, avec un solde directement écrit dans un smart contract ; Phoenix repose sur un schéma UTXO + note, en s’appuyant sur des engagements de Pedersen et des nullifiers.
@Dusk
Tu vois que c’est une conception géniale ? Oui. Mais essaie donc d’écrire un contrat de prêt dessus… Au moment du règlement, il faut gérer en même temps deux états : le solde ETH et les nullifiers des notes de confidentialité doivent être calculés ensemble. Écrire la logique Moonlight fait craindre que les gros portefeuilles se fassent cibler ; écrire la logique Phoenix, c’est risquer que la régulation coupe net tes interfaces. Dans la documentation, une phrase légère et creuse du genre « choisir selon le besoin »… pour les développeurs, ça donne juste envie d’engueuler. Ce n’est pas de la modularité : c’est faire payer le prix aux écosystèmes.
Ce qui me glace encore plus, c’est une autre analyse. L’histoire des tokens de titres (securities) de NPEX est plutôt bien racontée, mais au final tout le monde finit cramponné à Moonlight. Les gens de la MiCA exigent même des audits trimestriels des réserves des stablecoins ; et tu leur dis « j’ai un zk-proof pour choisir une vue anonymisée » ? Leur première réaction, côté régulateur, sera toujours : est-ce que le code peut exporter un Excel en un clic ? La « divulgation sélective » de Phoenix, aux yeux des juristes, ressemble à une boîte noire technique : en cas de pépin, qui signe ? Les institutions ne sont pas naïves : avec de l’argent réel en jeu, elles préféreront courir à poil, mais pouvoir attribuer clairement les responsabilités.
Aujourd’hui, le taux de staking on-chain est de 36%, ça a l’air correct, mais dans le milieu tout le monde sait que c’est surtout du self-hype de la part des nœuds. DuskEVM est déployé, certes. Mais si, l’année prochaine, la colonne Phoenix reste vide dans la liste des Dapp, ce projet se transformera en une chaîne EVM avec plugin de confidentialité — et le récit s’effondrera quasiment à moitié.
Je ne dis pas que la technologie ne va pas : le couplage UTXO + ZK, c’est vraiment du costaud. Mais l’absence de réponse par défaut côté produit, c’est le plus gros échec. Un utilisateur lambda n’arrive même pas à retenir sa phrase mnémonique : tu veux en plus qu’il se demande à chaque transfert, « aujourd’hui, j’active ou non la confidentialité ? »
Je pensais à mettre un dossier d’observation, mais finalement je retire. On verra quand on aura le premier exemple où quelqu’un jette la liquidité centrale dans Phoenix, et obtient en même temps une validation écrite de la part de la régulation européenne.
#dusk $DUSK
