J’ai disputé avec quelqu’un toute la nuit sur « la chaîne de confidentialité peut-elle passer la réglementation ? ». Ce matin, en relisant le code, j’ai vu que Dusk avait déjà glissé la réponse dedans.
Bonne idée, le grand gâteau ! Le BTC monte très bien !
Hier soir, j’ai eu un échange jusqu’à deux heures avec un ami qui travaille sur la conformité. Il a martelé une seule chose : « Le combo ZK + UTXO, les organismes d’audit ne peuvent tout simplement pas faire leur travail, et la réglementation ne le reconnaîtra pas. » Je lui ai répliqué en m’appuyant sur la divulgation sélective de Phoenix. Il m’a alors lâché : « Le code peut-il exporter Excel en un clic ? » Et il a raccroché.
J’ai été bloqué par cette phrase pendant un moment.
Mais ce matin, en parcourant la documentation, j’ai repéré un détail que je n’avais pas trop remarqué : le mécanisme de View Key de Phoenix — la clé est scindée en deux : une pour consulter et une pour dépenser. La première peut être confiée à un tiers pour qu’il scanne et identifie les transactions qui vous appartiennent. La seconde reste à vie entre vos mains. Que signifie cela ? L’auditeur peut obtenir le View Key pour vérifier si vous avez commis des opérations non conformes, ou si vous avez effectué des transferts en excès, mais il ne peut pas prendre un seul centime chez vous. La « vérifiabilité » nécessaire à la conformité et l’« inviolabilité » nécessaire à la sécurité des actifs sont résolues en les séparant avec une seule clé.
L’« export Excel en un clic » dont mon ami parlait répond bien à un besoin réel : les régulateurs ne discutent pas avec vous d’idéaux cryptographiques, ils veulent quelque chose qu’on peut imprimer et archiver. Ce qui est intéressant avec cette conception de Phoenix, c’est qu’elle ne traite pas « confidentialité » et « auditabilité » comme des opposés. Elle construit plutôt un pont au milieu avec le View Key : ce que vous devez montrer, vous le montrez ; ce que vous ne devez pas laisser partir, vous ne pouvez pas l’emporter. Le mécanisme de Nullifier mérite aussi d’être mentionné : pour chaque transaction privée, on publie un identifiant unique de destruction, au lieu de révéler directement quelle note (note) a été dépensée. L’auditeur peut vérifier que « cette transaction a bien eu lieu et qu’il n’y a pas de double dépense », mais il ne peut pas savoir qui a transféré combien à qui.
Bien sûr, on ne peut pas dire que ce soit parfait à 100 % : une fois le View Key délégué, un tiers peut voir vos enregistrements de réception, ce qui constitue à lui seul un coût de confiance. À qui on le montre, comment on le conserve ensuite, et s’il y a une fuite : le protocole ne peut pas le garantir.
Mais au moins, c’est dans la bonne direction : la confidentialité ne doit pas forcément s’opposer à la réglementation. La question n’a jamais été « est-ce qu’on peut être conforme ? », mais plutôt « quel est le coût de la conformité ? ». La réponse de Phoenix est que le coût peut être une clé en lecture seule, non une mise à nu totale de tout votre compte.
@Dusk $DUSK #dusk
Bonne idée, le grand gâteau ! Le BTC monte très bien !
Hier soir, j’ai eu un échange jusqu’à deux heures avec un ami qui travaille sur la conformité. Il a martelé une seule chose : « Le combo ZK + UTXO, les organismes d’audit ne peuvent tout simplement pas faire leur travail, et la réglementation ne le reconnaîtra pas. » Je lui ai répliqué en m’appuyant sur la divulgation sélective de Phoenix. Il m’a alors lâché : « Le code peut-il exporter Excel en un clic ? » Et il a raccroché.
J’ai été bloqué par cette phrase pendant un moment.
Mais ce matin, en parcourant la documentation, j’ai repéré un détail que je n’avais pas trop remarqué : le mécanisme de View Key de Phoenix — la clé est scindée en deux : une pour consulter et une pour dépenser. La première peut être confiée à un tiers pour qu’il scanne et identifie les transactions qui vous appartiennent. La seconde reste à vie entre vos mains. Que signifie cela ? L’auditeur peut obtenir le View Key pour vérifier si vous avez commis des opérations non conformes, ou si vous avez effectué des transferts en excès, mais il ne peut pas prendre un seul centime chez vous. La « vérifiabilité » nécessaire à la conformité et l’« inviolabilité » nécessaire à la sécurité des actifs sont résolues en les séparant avec une seule clé.
L’« export Excel en un clic » dont mon ami parlait répond bien à un besoin réel : les régulateurs ne discutent pas avec vous d’idéaux cryptographiques, ils veulent quelque chose qu’on peut imprimer et archiver. Ce qui est intéressant avec cette conception de Phoenix, c’est qu’elle ne traite pas « confidentialité » et « auditabilité » comme des opposés. Elle construit plutôt un pont au milieu avec le View Key : ce que vous devez montrer, vous le montrez ; ce que vous ne devez pas laisser partir, vous ne pouvez pas l’emporter. Le mécanisme de Nullifier mérite aussi d’être mentionné : pour chaque transaction privée, on publie un identifiant unique de destruction, au lieu de révéler directement quelle note (note) a été dépensée. L’auditeur peut vérifier que « cette transaction a bien eu lieu et qu’il n’y a pas de double dépense », mais il ne peut pas savoir qui a transféré combien à qui.
Bien sûr, on ne peut pas dire que ce soit parfait à 100 % : une fois le View Key délégué, un tiers peut voir vos enregistrements de réception, ce qui constitue à lui seul un coût de confiance. À qui on le montre, comment on le conserve ensuite, et s’il y a une fuite : le protocole ne peut pas le garantir.
Mais au moins, c’est dans la bonne direction : la confidentialité ne doit pas forcément s’opposer à la réglementation. La question n’a jamais été « est-ce qu’on peut être conforme ? », mais plutôt « quel est le coût de la conformité ? ». La réponse de Phoenix est que le coût peut être une clé en lecture seule, non une mise à nu totale de tout votre compte.
@Dusk $DUSK #dusk