Confidentialité programmable : comment cela pourrait-il être plus respectueux de la conformité au monde Web3

Chez Ola, nous sommes tout à fait d'accord avec la déclaration de a16z dans leur article " Garantir la confidentialité des cryptomonnaies et la conformité réglementaire " à propos du web3 :

« Le développement et la régulation de web3 – une évolution d’Internet alimentée par la cryptographie – doit atteindre deux objectifs souvent contradictoires. Objectif 1 : Préserver la vie privée des consommateurs, malgré la nature transparente par défaut des blockchains . Objectif 2 : Réduire le risque de financement illicite dans l’intérêt de la sécurité nationale.

Cette vision correspond à ce qu'Ola a décrit dans l'article " Ola – Façonnez votre propre parcours Web3 ". De plus, l'accent mis sur le haut débit est une fonctionnalité qu'Ola travaille actuellement dur pour mettre en œuvre.

Qu'il s'agisse de scénarios privés ou non privés, la programmabilité est un attribut extrêmement important. Dans le domaine de la confidentialité programmable, outre Ola, Aztec et Miden travaillent tous deux vers le même objectif.

L'article d'Ola, " Sin7y Tech Review (35) : Hybrid Rollup – L'infrastructure de nouvelle génération - HackMD ," décrit les différences entre ces trois solutions.

Dans cet article, nous nous concentrerons davantage sur l'explication de la conception d'Ola en termes de conformité . Comme décrit dans l'article a16z, la confidentialité doit englober deux attributs simultanément :

1. Obtenez une protection native de la confidentialité pour protéger les informations des utilisateurs.

   
   

2. Assurer la conformité réglementaire pour suivre les activités illicites.

Le premier point est relativement simple à réaliser. Concernant le second, chaque projet a ses propres considérations et compromis. Nous examinerons principalement le processus de réflexion et la conception d'Ola en matière de conformité réglementaire.

En abordant cela dans la perspective de résoudre des problèmes du monde réel, examinons d'abord les défis auxquels sont confrontés divers projets de confidentialité en termes de conformité réglementaire. Comme décrit dans le chapitre « Désanonymisation sélective involontaire » de l'article « Solutions réglementaires protégeant la vie privée utilisant des preuves sans connaissance : article complet - a16z crypto ", la question centrale est : " Qui conserve la clé privée pour débloquer la traçabilité ? "

Pourquoi avons-nous besoin d’une clé privée pour débloquer la traçabilité ?

La nécessité d'une clé privée pour assurer la traçabilité est liée aux conceptions actuelles en matière de confidentialité.

Étant donné que presque toutes les solutions de confidentialité actuellement basées sur la technologie zk (zero-knowledge) s'inspirent de Zcash, nous discuterons directement de la conception de Zcash, comme illustré ci-dessous :

Dans l'article " Sin7y Tech Review (33) : Principes des transactions privées et problèmes de conformité réglementaire - HackMD ", vous pouvez trouver les principes de conception derrière les transactions privées. Nous expliquerons brièvement comment la confidentialité est préservée dans le cadre de cette conception et comment elle répond aux préoccupations réglementaires :

1. Masquage de l'initiateur de la transaction, ou de l'expéditeur : Ceci est réalisé grâce à une signature unique, comme détaillé dans la section 4.1.7.1 du protocole zcash-sapling .

   
   

2. Masquer le destinataire de la transaction, ou le destinataire : Ceci se divise en deux scénarios :

   
   

ⅰ. La dissimulation aux tiers est obtenue en cryptant les informations de transaction à l'aide de l'adresse publique du destinataire. Voir l'article 4.19.1 du protocole zcash-sapling . Le destinataire passe ensuite au crible les transactions à l'aide d'une clé privée (appelée clé de vue entrante) pour déchiffrer et filtrer les transactions qui lui sont envoyées, comme décrit dans la section 4.19.2 du protocole zcash-sapling . Le contenu de la transaction lui-même ne contient aucune information sur le destinataire.

ⅱ. Le fait de se cacher du même expéditeur s'effectue à l'aide d'une adresse publique unique.

3. Pour la dissimulation des informations sur les transactions : L'approche implique l'utilisation de preuves sans connaissance et de schémas secrets partagés. Se référer aux sections 4.17 et 4.19 du protocole zcash-sapling .

   
   

4. Pour la mise en œuvre du non traçable : L'approche s'appuie sur la conception de l'arbre d'engagement (appelé ci-après "CM") et de l'arbre d'annulation (appelé ci-après "NF"). Cette conception répond aux objectifs suivants :

   
   

ⅰ. Chaque UTXO (Unspent Transaction Output) correspond à un CM et un NF, mais il n'y a pas de lien direct entre les deux.

ⅱ. L'arborescence CM et l'arborescence NF sont des arborescences à ajout uniquement.

ⅲ. L'arbre CM est utilisé pour prouver la validité de l'UTXO, tandis que l'arbre NF empêche la double dépense de l'UTXO.

Sur la base de la conception de confidentialité ci-dessus, les utilisateurs peuvent bénéficier des fonctionnalités de protection de la confidentialité suivantes :

1. Chaque transaction reste invisible pour les parties externes.

   
   

2. Les liens entre les transactions sont intraçables.

   
   

Cela semble être une conception de protection de la vie privée sans faille pour les utilisateurs. Cependant, dans la réalité, tous les utilisateurs n’agissent pas avec des intentions réelles et licites. Des mécanismes doivent être en place pour divulguer une partie ou la totalité des détails des transactions privées afin d'assurer la traçabilité lorsque cela est nécessaire.

Cela aide les organismes de réglementation à prendre des mesures contre les utilisateurs malveillants. Dans le cas contraire, cette forme de confidentialité pourrait devenir un outil permettant à des acteurs malveillants de nuire aux utilisateurs ordinaires.

La conception de confidentialité susmentionnée permet-elle aux autorités de régulation de tracer facilement les transactions et d’appliquer les réglementations ? La réponse est non. Comme l'illustre le diagramme fourni (qui est référencé mais non représenté), la conception actuelle de la confidentialité nécessite une clé d'affichage pour déverrouiller la traçabilité des transactions.

Cependant, cette clé de vue est détenue par l’utilisateur, ce qui la rend directement inaccessible aux régulateurs. Cela rejoint les problèmes décrits dans les sections 13/14 intitulées « Désanonymisation sélective volontaire » et « Désanonymisation sélective involontaire » de l'article « Solutions réglementaires protégeant la vie privée utilisant des preuves sans connaissance : article complet - crypto a16z. "

Approfondissons. Pourquoi la clé d’affichage est-elle si sensible que les utilisateurs hésitent à la fournir aux régulateurs ?

1. Tout d’abord, il est crucial de préciser que la clé d’affichage n’est pas la clé privée utilisée pour les signatures de transactions ; il ne peut pas être utilisé pour signer directement des transactions et, par conséquent, il ne peut pas être utilisé pour voler les actifs des utilisateurs.

   
   

2. Une fois la clé d'affichage exposée, les régulateurs peuvent voir toutes les transactions privées initiées par un utilisateur en texte clair. Les utilisateurs doivent faire confiance aux régulateurs pour que : (1) la clé d'affichage ne soit pas divulguée ; et (2) les détails de la transaction ne seront pas divulgués.

   
   

3. Les utilisateurs aux intentions malveillantes ne seront bien sûr pas disposés à fournir leur clé d’affichage, laissant les régulateurs impuissants.

   
   

Sur la base de l’analyse ci-dessus, la solution de confidentialité idéale devrait :

1. Continuez à dissimuler le contenu de chaque transaction, en garantissant que la confidentialité des utilisateurs reste intacte.

   
   

2. Obtenez une traçabilité sans autorisation entre les transactions, ce qui signifie que la traçabilité peut être réalisée sans la fourniture obligatoire d'informations supplémentaires .

C’est la vision que s’efforce de réaliser Ola : une confidentialité programmable qui intègre nativement la traçabilité !

Comment Ola introduit-t-elle la traçabilité native dans la confidentialité programmable ?

Face aux défis réglementaires rencontrés par les solutions de confidentialité ci-dessus, Ola a osé tenter sa chance et a décrit une conception spécifique. Les points technologiques fondamentaux peuvent être résumés comme suit :

1. L'arbre d'annulation n'est plus introduit pour parvenir à l'intracabilité des transactions. Dans la conception d'Ola, les transactions sont traçables, mais cela se fait sous cryptage sans compromettre les attributs de confidentialité des transactions elles-mêmes.

   
   

2. L'arbre d'engagement restant passe du mode d'ajout uniquement d'origine à un mode pouvant être mis à jour en introduisant des instructions de preuve supplémentaires pour éviter les attaques à double dépense sur le même engagement. Ceci est illustré dans la figure 2 :

   
   

3. Incorporez un mécanisme de clé de vue pouvant être mis à jour. Cela signifie que lorsqu'une clé de vue est exposée, les utilisateurs peuvent mettre à jour la clé de vue pour garantir que les transactions privées ultérieures créées après la mise à jour de la clé ne peuvent pas être déchiffrées. Comme illustré dans la figure 3 :

   
   

zkDID/zkKYC équilibre efficacement confidentialité et réglementation

Les identifiants décentralisés sans connaissance (zkDID) jouent un rôle crucial dans les plateformes de confidentialité. Ils ont la capacité de transformer l'identité légale d'un utilisateur (Legal ID) en un zkDID. Par exemple, dans le projet PSE Anon Aadhaar , les personnes possédant une carte Aadhaar peuvent générer un zkDID.

Pour d'autres, un zkDID est anonyme et ne révèle pas les véritables informations d'identité de l'utilisateur. Cette double caractéristique constitue un outil puissant pour la protection de la vie privée.

Concernant les niveaux de mise en œuvre de zkDID, cela peut se produire à différents niveaux, en fonction de la conception et des exigences de la plateforme :

1. Implémentation au niveau de la plateforme : si une plateforme doit gérer et vérifier l'identité de tous les utilisateurs pour garantir la sécurité et la conformité, l'implémentation de zkDID au niveau de la plateforme pourrait être le choix le plus approprié. De cette manière, la plateforme peut intégrer directement zkDID dans le cadre de son système de gestion des identités, permettant la vérification et l'autorisation de l'identité des utilisateurs.

   
   

   Cette approche permet une protection cohérente de l’identité et un contrôle de la confidentialité sur l’ensemble de la plateforme.

   
   

2. Implémentation au niveau de l'application : si une plate-forme donne la priorité au contrôle et à la flexibilité des utilisateurs, il peut alors être préférable d'implémenter zkDID dans une application de couche supérieure sur la plate-forme. Cette méthode permet aux utilisateurs de choisir d'utiliser zkDID et de gérer leur identité selon leurs besoins.

   
   

   Les utilisateurs peuvent décider quand utiliser zkDID pour équilibrer confidentialité et commodité. Cette approche peut être plus adaptée aux utilisateurs qui souhaitent avoir un contrôle plus actif sur leur identité. (non natif).

Compte tenu de la conception ci-dessus, la solution de confidentialité d'Ola présente les avantages suivants :

1. Traçabilité : sur la base des informations CM contenues dans une transaction, tout tiers peut retracer le chemin de flux du CM, comme illustré dans la figure 2.

   
   

2. Confidentialité : La confidentialité de chaque transaction reste intacte ; les informations sur l’expéditeur, le destinataire et d’autres aspects restent confidentielles.

   
   

3. Efficacité : En entretenant moins d'arbres, les frais généraux du système zk-proof sont réduits.

   
   

4. Clé de vue pouvant être mise à jour : prend en charge les mises à jour de la clé de vue, garantissant que la confidentialité des transactions n'est pas compromise si la clé de vue est exposée.

   
   

5. Respectueux de la conformité : sans avoir besoin d'informations non exécutoires, les régulateurs peuvent retracer la lignée de la cible, par exemple, au sein de laquelle se trouvent les collections CM. Même si les régulateurs peuvent temporairement manquer de connaissances sur les propriétaires de ces CM, ils ont deux options :

   
   

6. un. Attendez que le CM soit consommé et transféré vers une adresse publique, ce qui est réalisable puisque, dans la conception d'Ola, tous les états privés doivent passer à des états publics avant de quitter l'écosystème.

   
   b. Obtenez des informations sur la clé d'affichage pour le décryptage, une méthode traditionnelle utilisée pour la traçabilité dans les solutions de protection de la vie privée, comme on le voit dans des systèmes comme Zcash, Aleo, Aztec, Miden et autres.

Au-delà de ces avantages techniques, Ola peut toujours s'intégrer à des papiers comme " Atteindre la confidentialité des cryptomonnaies et la conformité réglementaire - a16z crypto " et " Confidentialité de la blockchain et conformité réglementaire : vers un équilibre pratique " pour intégrer des mécanismes de liste noire et d'autres contraintes à un stade précoce, affinant ainsi la conception de l'ensemble du système de confidentialité programmable.

Également publié ici