18 août : la SEC américaine a proposé de nouvelles règles relatives aux crypto-actifs. L’objectif est de prévoir, pour certains contrats d’investissement impliquant des crypto-actifs, un parcours d’émission ciblée. Une des exemptions pourrait aller jusqu’à 75 millions de dollars sur 12 mois, mais il s’agit toujours d’une proposition : ce n’est pas encore une loi entrée en vigueur.
Ce sujet me fait penser à une question souvent négligée : si des titres devaient vraiment être « mis en chaîne », la comptabilité devrait-elle être entièrement publique, ou au contraire entièrement dissimulée ? La réponse de Dusk n’est pas un choix entre l’un et l’autre : elle consiste à conserver à la fois Moonlight et Phoenix.
Commençons par deux métaphores familières. Moonlight ressemble davantage à un compte bancaire : c’est un modèle account-based, où le compte est identifié par une clé publique. Le solde, le nonce, ainsi que l’expéditeur et le destinataire d’un transfert, de même que le montant, sont tous visibles. Il est adapté aux processus qui nécessitent rapprochement, reporting ou vérifications publiques. Phoenix, lui, ressemble à un ensemble de billets chiffrés : les actifs existent sous forme d’encrypted notes, dans un modèle UTXO. Les transactions peuvent être justifiées via des preuves à divulgation nulle (zero-knowledge) montrant que « j’ai le droit de dépenser, que le solde est suffisant et qu’il n’y a pas de double-dépense », sans devoir rendre publics le montant, les notes spécifiques et l’expéditeur.
Mais Phoenix n’est pas pour autant « totalement anonyme ». La documentation officielle précise clairement que les informations de l’expéditeur sont visibles par le destinataire. Les utilisateurs peuvent aussi, grâce à un viewing key, effectuer une divulgation sélective lorsque la réglementation ou un audit l’exige. C’est un point crucial : la protection de la vie privée vise à éviter une exposition inutile à l’ensemble du réseau, pas à effacer toutes les responsabilités.
Les deux modèles sont finalement coordonnés par le Transfer Contract de DuskDS. Il accepte des transactions de formats différents, les oriente vers les logiques de vérification correspondantes, et gère de manière unifiée les frais, l’état global et les problèmes de double-spending. Du point de vue de la nature, les transactions doivent toutes satisfaire la propriété, le solde et les frais, la prévention des doubles dépenses et la résistance à la falsification ; la différence réside dans le fait que Moonlight vérifie directement l’état public, tandis que Phoenix vérifie principalement la preuve ZK.
@Dusk_Foundation $DUSK #dusk
En résumé, Dusk ne fait pas vraiment le choix entre « transparence » et « confidentialité », mais permet au même système financier de choisir le sens de la comptabilité selon le contexte : pour les vérifications publiques, utiliser Moonlight ; pour réduire l’exposition, utiliser Phoenix.
Ce sujet me fait penser à une question souvent négligée : si des titres devaient vraiment être « mis en chaîne », la comptabilité devrait-elle être entièrement publique, ou au contraire entièrement dissimulée ? La réponse de Dusk n’est pas un choix entre l’un et l’autre : elle consiste à conserver à la fois Moonlight et Phoenix.
Commençons par deux métaphores familières. Moonlight ressemble davantage à un compte bancaire : c’est un modèle account-based, où le compte est identifié par une clé publique. Le solde, le nonce, ainsi que l’expéditeur et le destinataire d’un transfert, de même que le montant, sont tous visibles. Il est adapté aux processus qui nécessitent rapprochement, reporting ou vérifications publiques. Phoenix, lui, ressemble à un ensemble de billets chiffrés : les actifs existent sous forme d’encrypted notes, dans un modèle UTXO. Les transactions peuvent être justifiées via des preuves à divulgation nulle (zero-knowledge) montrant que « j’ai le droit de dépenser, que le solde est suffisant et qu’il n’y a pas de double-dépense », sans devoir rendre publics le montant, les notes spécifiques et l’expéditeur.
Mais Phoenix n’est pas pour autant « totalement anonyme ». La documentation officielle précise clairement que les informations de l’expéditeur sont visibles par le destinataire. Les utilisateurs peuvent aussi, grâce à un viewing key, effectuer une divulgation sélective lorsque la réglementation ou un audit l’exige. C’est un point crucial : la protection de la vie privée vise à éviter une exposition inutile à l’ensemble du réseau, pas à effacer toutes les responsabilités.
Les deux modèles sont finalement coordonnés par le Transfer Contract de DuskDS. Il accepte des transactions de formats différents, les oriente vers les logiques de vérification correspondantes, et gère de manière unifiée les frais, l’état global et les problèmes de double-spending. Du point de vue de la nature, les transactions doivent toutes satisfaire la propriété, le solde et les frais, la prévention des doubles dépenses et la résistance à la falsification ; la différence réside dans le fait que Moonlight vérifie directement l’état public, tandis que Phoenix vérifie principalement la preuve ZK.
@Dusk_Foundation $DUSK #dusk
En résumé, Dusk ne fait pas vraiment le choix entre « transparence » et « confidentialité », mais permet au même système financier de choisir le sens de la comptabilité selon le contexte : pour les vérifications publiques, utiliser Moonlight ; pour réduire l’exposition, utiliser Phoenix.