J’ai déjà vu @Dusk raconter à la fois Moonlight et Phoenix, et j’ai eu l’impression que c’était comme si on faisait deux versions du même truc : « virement ordinaire » et « virement privé », chacune avec ses propres fonctionnalités, donc avec redondance. En relisant ensemble la documentation du modèle de transactions et la notice d’intégration des exchanges, je me suis rendu compte que les deux modèles ne sont pas là pour faire de la “mise en scène” : ils reconnaissent, au sein d’une même couche de règlement, que certains flux de fonds doivent être publics, tandis que d’autres ne devraient pas exposer le montant et les relations à tout le monde.
Moonlight est un modèle de comptes public : le solde, l’expéditeur, le destinataire et le montant sont visibles. C’est plus simple pour les scénarios comme les recharges côté exchange, le trésor (timelock/treasury) et les cas nécessitant une comptabilité publique.
Phoenix, lui, place les fonds dans des notes chiffrées. Il utilise une preuve à divulgation nulle de connaissance pour confirmer qu’il n’y a pas de double dépense et que les fonds sont suffisants, tout en ne révélant pas aux observateurs le montant exact ni la note correspondante. Lorsqu’un audit est nécessaire, la divulgation sélective se fait via une viewing key.
Le principal malentendu ici, c’est : « comme il y a de la confidentialité, alors le navigateur ne peut rien voir ». Le navigateur officiel peut toujours voir la blockchain : les métadonnées publiques comme les blocs, le type de transaction, les frais et le gas. La plage exacte de ce qui est visible dépend du modèle de transaction et des contrats. À l’inverse, un exchange ne peut pas non plus traiter Phoenix comme Moonlight et le “scanner” directement : la documentation d’intégration officielle recommande clairement d’effectuer les recharges avec Moonlight ; pour les soldes privés, il faut d’abord les convertir en comptes publics. La logique de custody (dépôt) et de scan est totalement différente.
Donc le défi de $DUSK n’est pas de prouver que la confidentialité est possible, mais de permettre aux utilisateurs de ne pas emprunter le mauvais chemin lorsqu’ils passent de la sphère publique à la sphère privée. Pour que #dusk entre dans des flux de fonds sous réglementation, il faut que la confidentialité par défaut, la divulgation à la demande et une custody prévisible coexistent. Vous craignez davantage que la transparence totale divulgue les positions, ou bien que les deux modèles augmentent trop la complexité du produit ?
Moonlight est un modèle de comptes public : le solde, l’expéditeur, le destinataire et le montant sont visibles. C’est plus simple pour les scénarios comme les recharges côté exchange, le trésor (timelock/treasury) et les cas nécessitant une comptabilité publique.
Phoenix, lui, place les fonds dans des notes chiffrées. Il utilise une preuve à divulgation nulle de connaissance pour confirmer qu’il n’y a pas de double dépense et que les fonds sont suffisants, tout en ne révélant pas aux observateurs le montant exact ni la note correspondante. Lorsqu’un audit est nécessaire, la divulgation sélective se fait via une viewing key.
Le principal malentendu ici, c’est : « comme il y a de la confidentialité, alors le navigateur ne peut rien voir ». Le navigateur officiel peut toujours voir la blockchain : les métadonnées publiques comme les blocs, le type de transaction, les frais et le gas. La plage exacte de ce qui est visible dépend du modèle de transaction et des contrats. À l’inverse, un exchange ne peut pas non plus traiter Phoenix comme Moonlight et le “scanner” directement : la documentation d’intégration officielle recommande clairement d’effectuer les recharges avec Moonlight ; pour les soldes privés, il faut d’abord les convertir en comptes publics. La logique de custody (dépôt) et de scan est totalement différente.
Donc le défi de $DUSK n’est pas de prouver que la confidentialité est possible, mais de permettre aux utilisateurs de ne pas emprunter le mauvais chemin lorsqu’ils passent de la sphère publique à la sphère privée. Pour que #dusk entre dans des flux de fonds sous réglementation, il faut que la confidentialité par défaut, la divulgation à la demande et une custody prévisible coexistent. Vous craignez davantage que la transparence totale divulgue les positions, ou bien que les deux modèles augmentent trop la complexité du produit ?
