Le dernier article de V God : Comment le protocole du pool de confidentialité protège-t-il la vie privée des utilisateurs et répond-il aux exigences de conformité ?
原文：《Confidentialité et conformité réglementaire de la blockchain : vers un équilibre pratique》
De : Vitalik Buterin, Jacob Illum, Matthias Nadler, Fabian Schar et Ameen Soleimani
Compilation : Comment Odaily Planet Daily Husband
Aujourd'hui, Buterin et d'autres ont rédigé conjointement un document de recherche sur les protocoles de confidentialité, intitulé « Confidentialité de la blockchain et conformité réglementaire : vers un équilibre pratique ».
Le document décrit un nouveau protocole améliorant la confidentialité basé sur des contrats intelligents - le pool de confidentialité, discute de ses avantages et inconvénients et montre comment il équilibre les utilisateurs honnêtes et les utilisateurs malhonnêtes. Le protocole vise à utiliser des preuves sans connaissance pour vérifier la légitimité des fonds des utilisateurs sans révéler l'historique complet de leurs transactions, en pesant les exigences en matière de confidentialité et de réglementation tout en filtrant les fonds associés à des activités criminelles.
Odaily Planet Daily compile désormais l'essentiel du document comme suit.
Introduction
Les blockchains publiques sont transparentes de par leur conception. L'idée de base est que n'importe qui peut choisir de vérifier les transactions sans avoir recours à un tiers centralisé ; en réduisant les dépendances, cela fournit une base neutre pour une variété d'applications, y compris, mais sans s'y limiter, la finance et l'identité autonome.
Cependant, du point de vue de la confidentialité, les ensembles de données publics possèdent chaque transaction contenant chaque adresse blockchain. Chaque fois que quelqu'un transfère un actif vers une autre adresse ou interagit avec un contrat intelligent, cette transaction sera toujours visible sur la blockchain. Cela n’est clairement pas conforme aux exigences en matière de confidentialité.
Par exemple : Alice paie un dîner dans un restaurant en utilisant un portefeuille blockchain. Le bénéficiaire connaît désormais l'adresse d'Alice et peut analyser toutes les activités passées et futures à cette adresse. De même, Alice connaît désormais l'adresse du portefeuille du restaurant et peut utiliser ces informations pour obtenir les adresses du portefeuille d'autres clients ou consulter les revenus du restaurant. Ou encore, un tiers (tel que les réseaux sociaux) qui connaît le restaurant et l'adresse du portefeuille d'Alice peut facilement déduire l'adresse résidentielle réelle d'Alice et étudier ses transactions passées et futures.
**La montée en puissance des protocoles améliorant la confidentialité vise à résoudre les problèmes ci-dessus. Il permet aux utilisateurs de déposer des fonds dans le protocole, en utilisant une adresse, et de retirer des fonds du protocole ultérieurement, en utilisant une autre adresse. Tous les dépôts et retraits sont toujours visibles sur la blockchain, mais la correspondance entre les transferts spécifiques entrants et sortants n'est plus publique. **
L'un des protocoles d'amélioration de la confidentialité les plus connus est Tornado Cash. Il résout avec succès les problèmes ci-dessus, permettant aux utilisateurs de conserver une certaine confidentialité. Cependant, outre les utilisateurs légitimes qui tentent de protéger leurs données, Tornado Cash est également utilisé par divers acteurs malveillants. Les données de dépôt montrent que le groupe de hackers a transféré des fonds via ce protocole. Il existe des preuves que ce protocole renforçant la confidentialité est également utilisé par des groupes de pirates informatiques nord-coréens, ce qui a finalement pour résultat que les adresses de contrats intelligents du protocole sont placées sur la liste des ressortissants spécialement désignés et des personnes bloquées tenue par l'Office américain de contrôle des avoirs étrangers (OFAC). (souvent appelée liste SDN)).
**Le principal problème de Tornado Cash est la frontière floue entre les utilisateurs légitimes et les utilisateurs criminels. **Par conséquent, Tornado Cash propose une fonctionnalité de conformité qui permet aux utilisateurs de créer une preuve du dépôt d'où provient un retrait donné. Si ce mécanisme permet effectivement aux individus de prouver leur innocence, il le fait au prix de devoir faire confiance à un intermédiaire centralisé et de créer des asymétries d’information. Au final, le mécanisme a été peu utilisé par les utilisateurs.
Cet article traite d'une extension de cette approche qui permet aux utilisateurs d'attester publiquement des informations sur les dépôts d'où peuvent provenir leurs retraits, mais sans perdre leur confidentialité. **Privacy Pools propose un concept général : permettre une preuve d'adhésion ("J'atteste que mon retrait provient d'un de ces dépôts") ou une preuve d'exclusion ("Je certifie que mon retrait ne provient d'aucun de ces dépôts"). **Cet article discute de cette proposition et explique comment elle peut être utilisée pour atteindre un équilibre entre les utilisateurs honnêtes et malhonnêtes.
Notez que les pools de confidentialité offrent des choix supplémentaires en étendant l'ensemble des actions de l'utilisateur. Ils peuvent toujours fournir une certification plus détaillée à des contreparties spécifiques si nécessaire. Toutefois, dans certains cas, un justificatif d’adhésion ou d’exclusion peut suffire. De plus, la possibilité de rendre publiques ces certifications offre un certain nombre d’avantages par rapport à une divulgation bilatérale.
2. Contexte technique
Dans cette section, nous fournissons un bref aperçu technique et discutons de la construction technique et des principes généraux des protocoles tels que les pools de confidentialité.
1. Confidentialité de la blockchain avant les ZK-SNARK
Historiquement, les partisans de la blockchain ont soutenu que même si toutes les transactions sont transparentes, les blockchains préservent la confidentialité car elles assurent l'anonymat.
Avec l’avènement des outils modernes de regroupement et d’analyse, cette protection de la vie privée est devenue insuffisante. Pour améliorer la confidentialité des blockchains publiques, des techniques plus puissantes telles que les jointures de jetons et Monero ont été introduites. Cependant, ces technologies comportent toujours un risque de fuite de données. **
Cela a été suivi par des technologies à usage général sans connaissance, telles que Zcash et Tornado Cash, qui peuvent rendre l'ensemble d'anonymat de chaque transaction égal à l'ensemble de toutes les transactions précédentes. Cette technique est souvent appelée ZK-SNARK.
2、 ZK-SNARK
ZK-SNARKs est une technique qui permet à un prouveur de prouver une certaine déclaration mathématique sur des données publiques et privées, **tout en satisfaisant deux propriétés clés : la connaissance nulle et la simplicité. **
● Zéro-connaissance : Aucune information sur les données privées ne sera révélée sauf pour prouver que lesdites données privées sont conformes aux affirmations.
● **Simplicité : **Les preuves sont courtes et peuvent être vérifiées rapidement, même si les affirmations prouvées nécessitent des calculs fastidieux.
Les ZK-SNARK ont reçu une large attention de la part de la communauté blockchain en raison de leur importance en termes d'évolutivité, comme les ZK-rollups. Pour les applications de confidentialité, la simplicité n’est pas particulièrement importante, mais l’absence de connaissances est essentielle.
La « déclaration » prouvée par les ZK-SNARK peut être considérée comme un type de programme appelé « circuit », qui calcule le résultat d'une fonction f(x, w) avec des entrées publiques et privées, puis prouve que pour un public donné input x , il existe une entrée privée w telle que le résultat de f(x, w) est True.
3. Application des ZK-SNARK dans des systèmes tels que Zcash et Tornado Cash
Il existe quelques différences mineures entre les différentes versions de Zcash et les systèmes qui s'en inspirent tels que Tornado Cash. Cependant, la logique sous-jacente sur laquelle ils s’appuient est très similaire. Cette section décrit une version simple qui correspond à peu près au fonctionnement de ces protocoles.
Les jetons sont constitués de secrets détenus par leurs propriétaires. Deux valeurs peuvent être dérivées de s :
● ID de jeton public L = hachage(s + 1)
● annulateurU = hachage(s + 2)
Parmi eux, le hachage fait référence à la fonction de hachage de mot de passe, telle que SHA 256. Étant donné s, l'ID du jeton et le zéroiseur peuvent être calculés. Cependant, étant donné un ensemble de zéroiseurs et un ID de jeton public, le comportement pseudo-aléatoire de la fonction de hachage garantit que vous ne pouvez pas déterminer quel zéroiseur est associé à quel ID de jeton à moins de connaître les secrets qui ont généré les deux.
La blockchain garde une trace de tous les identifiants de jetons qui ont été « créés » et de tous les annulateurs qui ont été « dépensés ». Les deux ensembles sont en croissance constante (à moins que le protocole ne veuille imposer le moment où les jetons doivent être dépensés).
Une collection d'ID de jeton est stockée dans une structure de données appelée arbre Merkle : si l'arbre contient N éléments, alors chaque élément adjacent est haché (ce qui donne ⌈ N/2 ⌉ hachages), et chaque élément adjacent. Ces hachages sont à nouveau hachés (ce qui donne en ⌈ N/4 ⌉ hachages), et ainsi de suite, jusqu'à ce que l'intégralité des données soit validée dans un seul « hachage racine ».
Étant donné une valeur spécifique dans un arbre et un hachage racine, vous pouvez fournir une branche Merkle : des "valeurs sœurs" qui sont hachées ensemble à chaque étape du chemin allant de cette valeur à la racine. Cette branche Merkle est très utile car il s'agit d'un petit morceau de données (hachages log 2(N)) qui peut être utilisé pour prouver qu'une valeur particulière se trouve réellement dans l'arborescence. La figure ci-dessous montre un exemple d'arbre Merkle d'une hauteur de 4.
Lorsque les utilisateurs envoient des pièces à d’autres, ils fournissent les éléments suivants :
● Annulateur U qui souhaite dépenser
● ID de jeton L' du nouveau jeton que vous souhaitez créer (le destinataire est invité à le fournir)
● Un ZK-SNARK.
ZK-SNARK contient les entrées privées suivantes :
● les secrets de l'utilisateur
● Branche Merkle dans l'arborescence des ID de jeton, prouvant que le jeton avec l'ID de jeton L = hash(s + 1) a effectivement été créé à un moment donné dans le passé.
Il contient également les contributions publiques suivantes :
● U, le zéroiseur des jetons dépensés
● R, le hachage racine contre lequel la preuve Merkle est dirigée
ZK-SNARK prouve deux propriétés :
● U = hachage(s + 2)
● Les succursales Merkle sont valides
En plus des ZK-SNARK, le protocole vérifie également les éléments suivants :
● R est le hachage racine actuel ou historique de l'arborescence des ID de jeton.
● U n'est pas dans l'ensemble des zéroiseurs épuisés
Si la transaction est valide, elle ajoute U à l'ensemble des zéroiseurs dépensés et L' à la liste des identifiants de jeton. Afficher U empêche qu’un seul jeton soit dépensé deux fois. Cependant, aucune autre information ne sera divulguée. **Le monde extérieur ne peut voir que quand les transactions sont envoyées ; il ne peut pas savoir qui envoie ou reçoit ces transactions et ne peut pas distinguer la source unifiée des jetons. **
Il existe deux exceptions au modèle ci-dessus : les dépôts et les retraits. Lors des dépôts, des identifiants de jeton peuvent être créés sans invalider un certain jeton précédent. Du point de vue de la préservation de la vie privée, les dépôts ne sont pas anonymes en raison de l'association entre un L donné et un événement externe qui permet d'ajouter L (dans Tornado Cash, le dépôt d'ETH dans le système ; dans Zcash, une nouvelle ZEC minière) est public.
En d’autres termes, les **dépôts sont liés à l’historique de leurs transactions passées. **Lors des retraits, un Zeroizer sera consommé sans ajouter de nouvel identifiant de jeton. Cela peut déconnecter les retraits des dépôts correspondants et indirectement de l’historique des transactions passées. Cependant, les retraits peuvent être liés à toute transaction future ayant lieu après l'événement de retrait.
La première version de Tornado Cash n'avait aucun concept de transferts internes, elle autorisait uniquement les dépôts et les retraits. Les versions ultérieures, encore au stade expérimental, autorisaient également les transferts internes et les pièces de diverses dénominations, y compris la prise en charge des opérations de « fractionnement » et de « fusion ». Nous discuterons de la manière d’étendre le système de transfert de pièces de confidentialité de base et le pool de confidentialité à des dénominations arbitraires dans les chapitres suivants.
4. ZK-SNARK dans le pool de confidentialité
** L'idée centrale du pool de confidentialité est que les utilisateurs prouvent non seulement que le retrait est associé à un dépôt précédent grâce à une preuve sans connaissance, mais prouvent également qu'il appartient à un ensemble d'associations plus strict. **La collection associée peut être un sous-ensemble de tous les dépôts effectués précédemment, une collection contenant uniquement les propres dépôts de l'utilisateur, ou quoi que ce soit entre les deux. L'utilisateur spécifie l'ensemble en fournissant la racine Merkle de l'ensemble associé comme entrée publique.
Comme le montre la figure ci-dessous, par souci de simplicité, nous ne prouvons pas directement que l'ensemble associé est bien un sous-ensemble des dépôts effectués précédemment ; au lieu de cela, nous demandons simplement à l'utilisateur d'utiliser le même identifiant de pièce comme nœud feuille pour prouver deux branches de Merkle grâce à une connaissance nulle :
● Entrez la branche Merkle de la racine R de l'ensemble total d'ID de pièces
● Entrez la branche Merkle de l'ensemble d'associations fourni RA racine
L'intention est de placer l'ensemble complet des associations quelque part (peut-être en chaîne). Le concept de base est le suivant : au lieu d'exiger des utilisateurs qu'ils précisent exactement de quel dépôt proviennent leurs retraits, ou à l'autre extrême, de ne fournir aucune autre information que la preuve qu'il n'y a pas eu de double dépense, nous permettons aux utilisateurs de proposer un ensemble d'options à partir desquelles les fonds peuvent être arrivés, et cet ensemble peut être aussi large ou étroit qu'ils le souhaitent.
Nous encourageons un écosystème qui permet aux utilisateurs de spécifier plus facilement un ensemble d'associations cohérentes avec leurs préférences. La suite de cet article décrira uniquement l’infrastructure basée sur ce mécanisme de base simple et ses conséquences.
3. Considérations pratiques et cas d'utilisation
Analysez la manière dont les protocoles améliorant la confidentialité sont utilisés dans la pratique du point de vue des applications.
1. Cas d'utilisation des collections associées
Pour illustrer la valeur de ce programme dans un environnement d’application de la loi, voici un exemple :
Supposons que nous ayons cinq utilisateurs : Alice, Bob, Carl, David, Eve. Les quatre premiers utilisateurs sont des utilisateurs honnêtes, respectueux des lois mais soucieux de leur vie privée, tandis qu'Eve est une voleuse. Parce que le public sait qu'Eve est une voleuse grâce à l'information selon laquelle les pièces de monnaie à l'adresse marquée « Eve » ont été volées. Dans la pratique, cela arrive assez souvent : sur les blockchains publiques, les fonds générés par les vulnérabilités exploitées dans les protocoles DeFi sont retracés pour identifier les fonds illicites entrant dans Tornado Cash.
Lorsque chacun des cinq utilisateurs effectue un retrait, il peut choisir quel ensemble associé spécifier. Leur ensemble d'associations doit inclure leurs propres dépôts, mais ils sont libres de choisir laquelle des autres adresses inclure. Les quatre premiers utilisateurs étaient motivés, d'une part, par le désir de protéger au maximum leur vie privée. Cela les motive à tendre à élargir leur ensemble d’associations. D’un autre côté, ils souhaitent réduire le risque que leurs pièces soient considérées comme suspectes par les commerçants ou les bourses. Il existe un moyen simple de procéder : ils n'incluent pas Eve dans leur collection associée. Par conséquent, pour eux quatre, le choix est clair : que leur ensemble d’associations soit {Alice, Bob, Carl, David}.
Bien entendu, Eve souhaite également maximiser son ensemble d’associations. Mais elle ne peut pas exclure ses propres dépôts, elle est donc obligée d'avoir son ensemble associé égal à l'ensemble des cinq dépôts. La sélection d’ensemble de participants associée est illustrée dans la figure ci-dessous.
Bien qu’Ève elle-même n’ait fourni aucune information, grâce à un simple processus d’élimination, nous pouvons tirer une conclusion claire : le retrait de la cinquième étape ne peut venir que d’Ève.
2. Construction des collections associées
La section précédente illustre une manière possible d'utiliser les collections associées dans un protocole de type pool de confidentialité et comment les participants honnêtes peuvent être séparés des mauvais. Notez que le système ne dépend pas de l'altruisme d'Alice, Bob, Carl et David ; ils ont des incitations claires pour justifier leur séparation. Regardons maintenant plus en détail la construction d'une collection associative. En général, il existe deux stratégies principales pour générer des collections associatives. Ils sont décrits ci-dessous et visualisés dans la figure ci-dessous.
● **Inclusion (ou adhésion) : **Identifier un ensemble spécifique de dépôts pour lesquels nous avons des preuves concluantes qu'ils présentent un faible risque, et créer un ensemble associé qui contient uniquement ces dépôts.
● Exclure : Identifiez un ensemble spécifique de dépôts que nous avons des preuves solides de considérer comme présentant un risque élevé et construisez un ensemble d'associations qui inclut tous les dépôts à l'exception de ces dépôts.
En pratique, les utilisateurs ne sélectionnent pas manuellement les dépôts à inclure dans leur collection associée. Au lieu de cela, les utilisateurs s'abonneront à des intermédiaires que nous appelons fournisseurs de collections d'associations (ASP), qui génèrent des collections d'associations avec des propriétés spécifiques. **Dans certains cas, les ASP peuvent être entièrement construits en chaîne, ne nécessitant aucune intervention humaine (ou IA). Dans d'autres cas, les ASP généreront indépendamment la collection associée et publieront la collection associée en chaîne ou ailleurs.
Nous recommandons fortement de publier au moins la racine Merkle de la collection d'associations sur la chaîne ; cela élimine la capacité des ASP malveillants à effectuer certains types d'attaques sur les utilisateurs (par exemple, donner à différents utilisateurs différentes collections d'associations dans le but de les désanonymiser). . L'ensemble de la collection doit être disponible via une API ou idéalement via un système de stockage décentralisé à faible coût tel que IPFS.
La possibilité de télécharger l'intégralité de l'ensemble associé est importante car elle permet aux utilisateurs de générer localement des preuves d'adhésion sans révéler aucune information supplémentaire à l'ASP, pas même les dépôts correspondant à leurs retraits.
Voici comment les ASP peuvent être créés en pratique :
● **Ajout différé pour exclure les mauvais acteurs : **Tout dépôt est automatiquement ajouté à la collection associée après un délai fixe (par exemple 7 jours), mais si le système détecte qu'un dépôt est associé à un mauvais comportement connu (par exemple un dépôt important -vol à grande échelle ou une adresse sur une liste de sanctions publiée par le gouvernement), la caution ne sera jamais ajoutée. En pratique, cela pourrait être réalisé grâce à des collections organisées par la communauté ou à des prestataires de services de filtrage de transactions existants qui ont déjà effectué le travail d'identification et de suivi des dépôts associés à un mauvais comportement.
● Frais mensuels par personne : Pour rejoindre un ensemble associé, la valeur du dépôt doit être inférieure à un certain maximum fixe, et le déposant doit prouver sans aucune connaissance qu'il détient un jeton d'identité (par exemple, par un gouvernement Pris en charge systèmes d’identification nationaux ou mécanismes légers tels que la vérification des comptes de réseaux sociaux). Mélangé avec un paramètre supplémentaire désignant le mécanisme de suppression pour le mois en cours afin de garantir que chaque identité ne peut engager des dépôts dans la collection associée qu'une fois par mois. La conception tente de mettre en œuvre l’esprit de nombreuses règles communes de lutte contre le blanchiment d’argent, selon lesquelles les petits paiements inférieurs à un certain seuil permettent un niveau plus élevé de confidentialité. Notez que cela peut être entièrement mis en œuvre sous forme de contrat intelligent, ne nécessitant aucune surveillance manuelle pour maintenir le fonctionnement continu.
● Frais mensuels pour membres de communauté de confiance : Similaires aux frais mensuels pour personne seule, mais plus restrictifs : les utilisateurs doivent prouver qu'ils sont membres d'une communauté hautement fiable. Les membres de la communauté, très confiants, acceptent de garantir mutuellement leur intimité.
● **Score en temps réel basé sur l'IA :**Le système AI ASP peut fournir un score de risque pour chaque dépôt en temps réel, et le système générera un ensemble associé contenant les dépôts dont le score de risque est inférieur à un certain seuil. Potentiellement, ASP pourrait générer plusieurs ensembles correspondant à plusieurs seuils de score de risque.
4. Description technique supplémentaire
Dans cette section, nous analysons la manière dont la proposition soutient les dénominations arbitraires et discutons de cas particuliers tels que la recertification, la certification directe bilatérale et la certification séquentielle.
1. Soutenez n'importe quelle confession
Le système monétaire simplifié de protection de la vie privée ci-dessus ne prend en charge que les transferts de devises de même dénomination. Zcash prend en charge les dénominations arbitraires en utilisant le modèle UTXO. Chaque transaction peut avoir plusieurs entrées (nécessité de publier un nilificateur pour chaque entrée) et plusieurs sorties (nécessité de publier un identifiant de jeton pour chaque sortie). Chaque ID de jeton créé doit être associé à une dénomination cryptographique. En plus de prouver la validité du zéroiseur, chaque transaction doit être accompagnée d'une preuve supplémentaire que la somme des dénominations des pièces créées n'excède pas la somme des dénominations des pièces dépensées. La figure ci-dessous illustre cette preuve supplémentaire.
Cette conception peut être étendue pour prendre en charge les dépôts et les retraits en traitant les dépôts comme des entrées (non cryptées) et les retraits comme des sorties (non cryptées). De plus, la conception peut être contrainte afin de simplifier l'analyse. Par exemple, seuls les retraits partiels pourraient être autorisés, de sorte que la transaction ait une entrée cryptée et deux sorties : une sortie non cryptée représentant le retrait, et une sortie cryptée « changement » représentant les fonds restants, qui pourront être utilisés pour de futurs retraits.
Une question naturelle est de savoir comment étendre cette conception pour prendre en charge les pools de confidentialité. L'insérer tel quel dans un pool de confidentialité n'est pas idéal car le graphique des transactions ne correspond pas à ce que nous attendons intuitivement : si un utilisateur dépose 10 jetons, puis dépense 1+2+3+4 en quatre jetons de retrait consécutifs, nous voulons traiter chacun des jetons. ces quatre retraits comme source du dépôt initial de 10 jetons. Mais le résultat réel est montré dans la figure ci-dessous : la source du premier retrait est le dépôt de 10 jetons, puis la source du deuxième retrait est la sortie de monnaie de 9 jetons créée par le premier retrait, et ainsi de suite par analogie. Cela pose des problèmes en pratique car cela nécessite qu'ASP valide le dépôt intermédiaire et l'ajoute à sa collection associée.
Pour que les quatre retraits de cet exemple aient comme source le dépôt initial de 10 pièces, nous devons résoudre deux problèmes :
● Assurez-vous que chaque retrait partiel n'est pas publiquement lié à d'autres retraits
● Autoriser chaque retrait partiel à inclure un dépôt en tant que membre de sa collection associée
Si nous ne prenons en charge que les retraits partiels, plutôt que les transactions MIMO plus complexes, et veillons à ce que chaque retrait ait un seul « dépôt original » correspondant défini, il existe plusieurs façons d'y parvenir directement. Une approche naturelle et évolutive consiste à diffuser la promesse de certaines informations par le biais de transactions. Par exemple, nous pouvons exiger que la transaction contienne un hachage d'engagement (coinID+hash®), ajouter une valeur aléatoire r pour assurer l'aveuglement et exiger que ZK-SNARK prouve que l'engagement dans la transaction est le même que sa transaction parent. Si la transaction parent elle-même est un retrait, l'engagement est le même que l'ID de pièce du dépôt d'origine, et si la transaction parent est un dépôt, l'engagement est le même que l'ID de pièce du dépôt d'origine. Par conséquent, chaque transaction de la chaîne doit contenir un engagement envers l'ID de pièce de dépôt d'origine et exiger la preuve que cette valeur fait partie de l'ensemble associé fourni par la transaction.
Pour améliorer la confidentialité contre les attaques d’agrégation de soldes, nous pouvons également prendre en charge la fusion de pièces. Par exemple, s’il me reste quelques pièces, je peux les fusionner avec celles-ci lors de mon prochain dépôt. Pour répondre à cela, nous pouvons exiger que les transactions s'engagent sur un ensemble d'identifiants de pièces et exiger que les transactions avec plusieurs entrées s'engagent sur l'union de leurs transactions parentes. Un retrait contiendra la preuve que tous ses identifiants de pièces engagés sont dans son ensemble associé.
2. Circonstances particulières
● **Recertification : **Les utilisateurs ont besoin d'informations de dépôt secrètes pour retirer des dépôts similaires aux protocoles de pool de confidentialité. Les mêmes informations secrètes sont également utilisées pour construire des preuves d’appartenance à un ensemble d’associations. La préservation des informations secrètes permet aux utilisateurs de générer de nouvelles preuves pour différents ensembles ou des ensembles associés mis à jour. Cela donne aux utilisateurs une plus grande flexibilité, mais peut également introduire des risques supplémentaires.
● Certification directe bilatérale : Dans certains cas, les utilisateurs peuvent être tenus de divulguer la source exacte du retrait à l'autre partie. Les utilisateurs peuvent créer une collection associée contenant uniquement leurs dépôts et générer des preuves par rapport à cette collection. Ces preuves sont généralement des exceptions et ne contribuent qu’à une confidentialité partielle lorsqu’elles sont partagées entre deux parties. Cependant, partager des preuves nécessite d’établir des hypothèses de confiance solides.
● Preuve de séquence : Dans une économie de transactions rapides utilisant un système de type pool de confidentialité, le protocole doit être modifié pour s'adapter à cet environnement. En plus des types de transactions de dépôt et de retrait, le protocole doit également prendre en charge les opérations d'envoi internes pour plus d'efficacité. De plus, en transmettant les fourchettes et les clés Merkle, les utilisateurs peuvent diffuser des informations relatives à l'historique des transactions afin que les destinataires puissent vérifier l'origine des fonds. Cela garantit que chaque utilisateur dispose du minimum d'informations requises pour avoir confiance dans les fonds reçus.
En pratique, un token peut avoir plusieurs « origines ». Par exemple, Bob est propriétaire d'un stand de café, il reçoit 5 jetons d'Alice, 4 jetons d'Ashley, 7 jetons d'Anne, et à la fin de la journée, il doit payer 15 jetons à Carl pour payer le dîner. Au lieu de cela, David a peut-être reçu 15 jetons de Carl, 25 jetons de Chris, et souhaite déposer 30 jetons à Emma (un échange). Dans ces cas plus complexes, nous suivons le même principe : l’histoire ajoutée à la collection associée depuis assez longtemps peut être ignorée, tandis qu’une histoire plus récente doit être transmise.
5. Plus de détails
Un système tel qu'un pool de confidentialité pourrait permettre aux utilisateurs d'obtenir une meilleure protection de la confidentialité de leurs données de transactions financières tout en conservant la capacité de prouver leur séparation des activités illégales connues. Nous espérons que les utilisateurs honnêtes seront incités à participer à un tel programme grâce à une combinaison de deux facteurs :
** ● Désir de confidentialité **
** ● Désir d'éviter d'éveiller les soupçons **
1. Consensus social et collecte associative
S’il y avait un consensus complet sur la question de savoir si les fonds sont bons ou mauvais, le système produirait un simple équilibre de séparation. Tous les utilisateurs possédant de « bons » actifs sont fortement incités et capables de prouver qu’ils appartiennent à un ensemble d’associations « uniquement bonnes ». En revanche, les mauvais acteurs ne seront pas en mesure de fournir une telle preuve. Ils peuvent toujours déposer de « mauvais » fonds dans le pool, mais cela ne leur rend aucun service. Tout le monde peut facilement déterminer que les fonds ont été retirés d'un protocole renforcé de confidentialité et voir que le retrait fait référence à une collection associée contenant des dépôts provenant de sources douteuses. De plus, la « mauvaise » monnaie n’entache pas la « bonne » monnaie. Lors du retrait de fonds de dépôts légitimes, leurs propriétaires peuvent simplement exclure tous les « mauvais » dépôts connus de leur collection associée.
Là où un consensus mondial existe et où les conclusions quant à savoir si le financement est considéré comme « bon » ou « mauvais » dépendent de la perspective sociale ou de la juridiction, l'ensemble des associations peut varier considérablement. Supposons qu'il existe deux juridictions avec des ensembles de règles différents. Les sujets des deux juridictions A et B peuvent utiliser le même protocole de renforcement de la confidentialité et choisir de délivrer des certifications qui répondent aux exigences de leurs juridictions respectives. Les deux peuvent facilement garantir la confidentialité de leurs propres collections associées et exclure les retraits qui ne sont pas conformes aux exigences de leurs juridictions respectives. Si nécessaire, une preuve d'adhésion peut être délivrée pour l'intersection de deux ensembles associés, prouvant ainsi de manière fiable que les dépôts correspondant à leurs retraits sont conformes aux exigences des deux juridictions.
La proposition est donc très flexible et doit être considérée comme une infrastructure neutre. D’une part, elle combat la censure. Il permet à quiconque de rejoindre une collection associée de son choix et de préserver la confidentialité au sein de sa propre communauté. D’un autre côté, des tiers peuvent exiger des preuves contre un ensemble particulier d’associations qui répondent à leurs exigences réglementaires. Ainsi, même s’il existe une communauté de mauvais acteurs dans un protocole renforçant la confidentialité, ils ne seront pas en mesure de dissimuler l’origine suspecte des dépôts tant que les informations sont reflétées avec précision dans la construction de l’ensemble associé.
2. Propriétés des collections associées
Les collections associatives doivent avoir certaines propriétés pour fonctionner. Les collectes doivent être précises afin que les utilisateurs puissent être sûrs qu'ils utilisent les fonds retirés en toute sécurité. De plus, les propriétés de chaque ensemble doivent être stables, c’est-à-dire moins susceptibles de changer dans le temps. Cela réduit le besoin de retraits de revalidation sur les nouvelles collections. Enfin, pour garantir une protection significative de la vie privée, l’ensemble d’associations doit être suffisamment grand et contenir différents types de dépôts. Cependant, ces propriétés s’opposent les unes aux autres. En général, les collections vastes et diversifiées peuvent avoir de meilleures propriétés de confidentialité, mais peuvent être moins précises et moins stables, tandis que les collections plus petites sont plus faciles à gérer mais offrent moins de confidentialité.
3. Considérations pratiques et concurrence
Les entités réglementées qui acceptent des crypto-actifs doivent s’assurer que les lois et réglementations auxquelles elles sont soumises permettent l’acceptation de tels fonds. Aujourd’hui, bon nombre de ces entités s’appuient sur ce que l’on appelle des outils de filtrage des transactions : des logiciels ou des services qui analysent la blockchain pour identifier des activités potentiellement suspectes, des liens vers des adresses illégitimes ou des transactions autrement non conformes. Les outils de filtrage expriment souvent le risque associé à chaque transaction via un score de risque. Cette note est basée sur la destination des fonds transférés et l'historique de leurs transactions. Les protocoles renforçant la confidentialité peuvent poser des défis à cet égard. Ils éliminent le lien visible entre les dépôts et les retraits. Par conséquent, en présence de protocoles améliorant la confidentialité, le score de risque doit prendre en compte l’attestation et attribuer un score basé sur l’ensemble des associations.
Les outils et services de filtrage des transactions sont principalement fournis par des sociétés professionnelles possédant une expertise dans l’analyse de la blockchain et les domaines juridiques connexes. Idéalement, ces entreprises (et toute autre personne) auraient accès à tous les certificats d’adhésion et aux collections associées correspondantes afin de fournir des scores de risque précis pour toutes les transactions. Par conséquent, nous recommandons que toutes les preuves soient stockées sur la blockchain ou sur un autre référentiel de preuves accessible au public. La seule exception est un certificat d’adhésion de taille unique partagé avec une contrepartie spécifique. Pour des raisons évidentes, ces témoignages ne devraient pas être rendus publics.
Le stockage des preuves directement sur la chaîne ajoute des coûts de transaction supplémentaires, mais réduit les efforts de coordination, rend la concurrence plus équitable et atténue les risques de quasi-monopole que les fournisseurs d'outils de filtrage peuvent créer en raison de la connaissance des preuves non publiques.
Les paramètres généraux d’un pool de confidentialité sont très flexibles. Le protocole peut être personnalisé pour différents cas d'utilisation en créant des collections spécifiques d'associations. Voici deux exemples de ces collections associatives particulières :
● **Les alliances de banques commerciales peuvent créer une collection associée contenant uniquement les dépôts de leurs clients. **Cela garantit que tous les retraits créés avec une preuve de collecte ont été soumis aux procédures de connaissance du client (KYC) et de lutte contre le blanchiment d'argent (AML) dans l'une des banques participantes, mais ne révèle pas quel retrait appartient à quel client.
● **Dans les cas où les intermédiaires financiers sont tenus de documenter clairement la source des fonds, ils peuvent exiger des utilisateurs qu'ils fournissent des preuves par rapport à un ensemble associé contenant uniquement les dépôts des utilisateurs. **Cette preuve sera ensuite échangée bilatéralement avec l'intermédiaire, lui permettant de suivre les fonds comme si l'utilisateur n'avait jamais utilisé le pool de confidentialité. Même si cela oblige les utilisateurs à faire confiance à l’intermédiaire pour ne pas révéler de preuves, cela permet idéalement aux utilisateurs de se conformer aux réglementations sans avoir à divulguer les informations au public.
4. Choix de conception et alternatives
Les configurations basées sur des ensembles d'associations, des preuves zk et des divulgations volontaires sont flexibles. Bien que cela soit très utile pour garantir que la proposition puisse être adaptée à différentes juridictions, il convient d'être très prudent en ce qui concerne les choix de conception spécifiques. Notamment deux aménagements potentiels auxquels nous nous opposons. Nous pensons qu'ils posent problème en termes d'exigences de confiance et peuvent créer des structures de marché quasi monopolistiques. Ci-dessous, nous décrivons et discutons brièvement de ces alternatives :
● Accès centralisé : les organismes chargés de l'application de la loi, les fournisseurs d'évaluation des risques cryptographiques ou des acteurs similaires peuvent accéder aux liens entre les transactions des utilisateurs tout en préservant la confidentialité des autres.
● **Liste blanche à l'échelle du système : **Les systèmes de confidentialité peuvent imposer des restrictions sur les types d'utilisateurs autorisés à déposer des pièces dans leurs pools, en les obligeant à fournir des preuves supplémentaires ou en exigeant que les dépôts attendent pendant une période de temps pendant laquelle la notation des risques est centralisée. le système peut refuser les dépôts.
Ces deux méthodes sont similaires dans la mesure où elles privilégient des entités spécifiques. Cela soulève des questions de gouvernance complexes : qui a accès à ces informations ? Qui a le pouvoir de gérer les autorisations ? Les entreprises privées ne semblent pas être une bonne option, car tout privilège peut créer une structure de marché oligopolistique, dans laquelle quelques entreprises ont accès aux données qui leur permettent de fournir ces services, tandis que d’autres ne sont pas en mesure de rivaliser.
De même, il existe de nombreux problèmes de gouvernance et politiques à résoudre lors de l’autonomisation des institutions publiques, en particulier dans un contexte international. Même si une institution est jusqu’à présent digne de confiance à 100 %, n’abusera pas de son pouvoir pour poursuivre un programme politique et ne dépend pas d’autres entités qui pourraient l’obliger à abuser de son pouvoir, cette situation est une manifestation de stagnation. Les organisations, les membres, les pays et les structures politiques au sein des organisations changent avec le temps. Il peut y avoir des pressions externes et l'existence de ces privilèges peut créer des incitations supplémentaires à perturber et à exercer une influence sur les systèmes de gouvernance de l'organisation.
De plus, les attaques à l’intérieur ou à l’extérieur de l’organisation, ou les erreurs de la part d’entités centralisées peuvent avoir des conséquences considérables. Nous pensons qu’il faut éviter la création de tels points de défaillance centralisés.
Cela dit, nous reconnaissons que différentes tailles de transactions et situations peuvent nécessiter différentes combinaisons de preuves. Par exemple, pour les transactions importantes, de nombreux utilisateurs peuvent finir par fournir une preuve d'exclusion de base en chaîne et fournir des informations plus détaillées sur la source des fonds à leurs contreparties.
5. L'orientation d'une recherche approfondie
Bien que cette étude donne un aperçu de la manière dont les protocoles d'amélioration de la confidentialité basés sur zkSNARK peuvent être utilisés dans des environnements réglementés, plusieurs aspects méritent des recherches plus approfondies.
Tout d’abord, il faut comprendre que la confidentialité obtenue grâce à ces protocoles dépend de nombreux facteurs différents. Les attaquants peuvent être en mesure d'associer les retraits à des dépôts spécifiques sur la base d'un ensemble d'associations insuffisamment grand, d'une mauvaise sélection de racine et d'une erreur de l'utilisateur.
De plus, les choix des autres utilisateurs peuvent nuire à votre propre vie privée. Dans des cas extrêmes, tous les autres membres du pool publieraient une preuve d’adhésion de taille un, révélant un lien direct entre leurs dépôts et leurs retraits. Évidemment, cela révélera implicitement le lien entre les seules transactions de dépôt et de retrait restantes. Dans un exemple plus subtil, les contraintes de diverses preuves d'adhésion pourraient être utilisées pour extraire des informations et potentiellement corréler les dépôts et les retraits avec une forte probabilité. Une fois ces informations attestées combinées aux métadonnées de transaction, les propriétés de confidentialité du protocole peuvent être compromises.
Enfin, les ASP malveillants peuvent choisir de compiler l'ensemble des associations proposées de manière à maximiser l'extraction d'informations ou à augmenter l'anonymat perçu en ajoutant des dépôts avec des retraits correspondants connus. Toutes ces questions nécessitent des recherches plus approfondies pour évaluer les propriétés de confidentialité fournies. Dans le même ordre d’idées, il serait intéressant d’étudier plus en détail les propriétés des équilibres de séparation, en modélisant le comportement des bons et des mauvais joueurs sous certaines hypothèses, et comment la preuve publique des premiers affecte la vie privée des seconds.
Les experts juridiques peuvent approfondir leurs recherches sur les exigences de divulgation spécifiques. Les scénarios présentés dans ce document sont flexibles et les conseils d'experts juridiques peuvent aider à adapter l'accord et l'écosystème construit autour de lui pour garantir la conformité dans diverses juridictions juridiques.
6. Conclusion
Dans de nombreux cas, la confidentialité et la conformité sont considérées comme étant en conflit. Cet article suggère que ce n'est pas nécessairement le cas si un protocole renforçant la confidentialité permet aux utilisateurs de prouver certaines propriétés de leur source de fonds. Par exemple, supposons que les utilisateurs puissent prouver que leurs fonds ne sont pas liés à des dépôts d’origine illicite connue, ou que les fonds font partie d’un ensemble spécifique de dépôts, sans divulguer d’autres informations.
Une telle configuration peut produire un équilibre de séparation dans lequel les utilisateurs honnêtes sont fortement incités à prouver qu'ils appartiennent à un ensemble associatif conforme et à préserver la confidentialité au sein de cet ensemble. A l’inverse, pour les utilisateurs malhonnêtes, ils ne peuvent pas fournir une telle preuve. Cela permet aux utilisateurs honnêtes de se dissocier des dépôts de tiers avec lesquels ils ne sont pas d'accord, ou de les empêcher d'utiliser leurs fonds dans un environnement conforme. Nous pensons que la proposition est très flexible et peut être ajustée en fonction de diverses exigences réglementaires potentielles.
Ce document doit être considéré comme une contribution à la potentielle coexistence future de la confidentialité et de la réglementation financières. Nous voulons faciliter les discussions et orienter la conversation dans une direction plus positive et constructive. Une collaboration entre praticiens, universitaires de diverses disciplines, décideurs politiques et régulateurs sera nécessaire pour élargir et réviser cette proposition ; le but ultime est de créer une infrastructure renforçant la confidentialité qui puisse être utilisée dans des environnements réglementés.
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Le dernier article de V God : Comment le protocole du pool de confidentialité protège-t-il la vie privée des utilisateurs et répond-il aux exigences de conformité ?
原文：《Confidentialité et conformité réglementaire de la blockchain : vers un équilibre pratique》
De : Vitalik Buterin, Jacob Illum, Matthias Nadler, Fabian Schar et Ameen Soleimani
Compilation : Comment Odaily Planet Daily Husband
Aujourd'hui, Buterin et d'autres ont rédigé conjointement un document de recherche sur les protocoles de confidentialité, intitulé « Confidentialité de la blockchain et conformité réglementaire : vers un équilibre pratique ».
Le document décrit un nouveau protocole améliorant la confidentialité basé sur des contrats intelligents - le pool de confidentialité, discute de ses avantages et inconvénients et montre comment il équilibre les utilisateurs honnêtes et les utilisateurs malhonnêtes. Le protocole vise à utiliser des preuves sans connaissance pour vérifier la légitimité des fonds des utilisateurs sans révéler l'historique complet de leurs transactions, en pesant les exigences en matière de confidentialité et de réglementation tout en filtrant les fonds associés à des activités criminelles.
Odaily Planet Daily compile désormais l'essentiel du document comme suit.
Introduction
Les blockchains publiques sont transparentes de par leur conception. L'idée de base est que n'importe qui peut choisir de vérifier les transactions sans avoir recours à un tiers centralisé ; en réduisant les dépendances, cela fournit une base neutre pour une variété d'applications, y compris, mais sans s'y limiter, la finance et l'identité autonome.
Cependant, du point de vue de la confidentialité, les ensembles de données publics possèdent chaque transaction contenant chaque adresse blockchain. Chaque fois que quelqu'un transfère un actif vers une autre adresse ou interagit avec un contrat intelligent, cette transaction sera toujours visible sur la blockchain. Cela n’est clairement pas conforme aux exigences en matière de confidentialité.
Par exemple : Alice paie un dîner dans un restaurant en utilisant un portefeuille blockchain. Le bénéficiaire connaît désormais l'adresse d'Alice et peut analyser toutes les activités passées et futures à cette adresse. De même, Alice connaît désormais l'adresse du portefeuille du restaurant et peut utiliser ces informations pour obtenir les adresses du portefeuille d'autres clients ou consulter les revenus du restaurant. Ou encore, un tiers (tel que les réseaux sociaux) qui connaît le restaurant et l'adresse du portefeuille d'Alice peut facilement déduire l'adresse résidentielle réelle d'Alice et étudier ses transactions passées et futures.
**La montée en puissance des protocoles améliorant la confidentialité vise à résoudre les problèmes ci-dessus. Il permet aux utilisateurs de déposer des fonds dans le protocole, en utilisant une adresse, et de retirer des fonds du protocole ultérieurement, en utilisant une autre adresse. Tous les dépôts et retraits sont toujours visibles sur la blockchain, mais la correspondance entre les transferts spécifiques entrants et sortants n'est plus publique. **
L'un des protocoles d'amélioration de la confidentialité les plus connus est Tornado Cash. Il résout avec succès les problèmes ci-dessus, permettant aux utilisateurs de conserver une certaine confidentialité. Cependant, outre les utilisateurs légitimes qui tentent de protéger leurs données, Tornado Cash est également utilisé par divers acteurs malveillants. Les données de dépôt montrent que le groupe de hackers a transféré des fonds via ce protocole. Il existe des preuves que ce protocole renforçant la confidentialité est également utilisé par des groupes de pirates informatiques nord-coréens, ce qui a finalement pour résultat que les adresses de contrats intelligents du protocole sont placées sur la liste des ressortissants spécialement désignés et des personnes bloquées tenue par l'Office américain de contrôle des avoirs étrangers (OFAC). (souvent appelée liste SDN)).
**Le principal problème de Tornado Cash est la frontière floue entre les utilisateurs légitimes et les utilisateurs criminels. **Par conséquent, Tornado Cash propose une fonctionnalité de conformité qui permet aux utilisateurs de créer une preuve du dépôt d'où provient un retrait donné. Si ce mécanisme permet effectivement aux individus de prouver leur innocence, il le fait au prix de devoir faire confiance à un intermédiaire centralisé et de créer des asymétries d’information. Au final, le mécanisme a été peu utilisé par les utilisateurs.
Cet article traite d'une extension de cette approche qui permet aux utilisateurs d'attester publiquement des informations sur les dépôts d'où peuvent provenir leurs retraits, mais sans perdre leur confidentialité. **Privacy Pools propose un concept général : permettre une preuve d'adhésion ("J'atteste que mon retrait provient d'un de ces dépôts") ou une preuve d'exclusion ("Je certifie que mon retrait ne provient d'aucun de ces dépôts"). **Cet article discute de cette proposition et explique comment elle peut être utilisée pour atteindre un équilibre entre les utilisateurs honnêtes et malhonnêtes.
Notez que les pools de confidentialité offrent des choix supplémentaires en étendant l'ensemble des actions de l'utilisateur. Ils peuvent toujours fournir une certification plus détaillée à des contreparties spécifiques si nécessaire. Toutefois, dans certains cas, un justificatif d’adhésion ou d’exclusion peut suffire. De plus, la possibilité de rendre publiques ces certifications offre un certain nombre d’avantages par rapport à une divulgation bilatérale.
2. Contexte technique
Dans cette section, nous fournissons un bref aperçu technique et discutons de la construction technique et des principes généraux des protocoles tels que les pools de confidentialité.
1. Confidentialité de la blockchain avant les ZK-SNARK
Historiquement, les partisans de la blockchain ont soutenu que même si toutes les transactions sont transparentes, les blockchains préservent la confidentialité car elles assurent l'anonymat.
Avec l’avènement des outils modernes de regroupement et d’analyse, cette protection de la vie privée est devenue insuffisante. Pour améliorer la confidentialité des blockchains publiques, des techniques plus puissantes telles que les jointures de jetons et Monero ont été introduites. Cependant, ces technologies comportent toujours un risque de fuite de données. **
Cela a été suivi par des technologies à usage général sans connaissance, telles que Zcash et Tornado Cash, qui peuvent rendre l'ensemble d'anonymat de chaque transaction égal à l'ensemble de toutes les transactions précédentes. Cette technique est souvent appelée ZK-SNARK.
2、 ZK-SNARK
ZK-SNARKs est une technique qui permet à un prouveur de prouver une certaine déclaration mathématique sur des données publiques et privées, **tout en satisfaisant deux propriétés clés : la connaissance nulle et la simplicité. **
● Zéro-connaissance : Aucune information sur les données privées ne sera révélée sauf pour prouver que lesdites données privées sont conformes aux affirmations.
● **Simplicité : **Les preuves sont courtes et peuvent être vérifiées rapidement, même si les affirmations prouvées nécessitent des calculs fastidieux.
Les ZK-SNARK ont reçu une large attention de la part de la communauté blockchain en raison de leur importance en termes d'évolutivité, comme les ZK-rollups. Pour les applications de confidentialité, la simplicité n’est pas particulièrement importante, mais l’absence de connaissances est essentielle.
La « déclaration » prouvée par les ZK-SNARK peut être considérée comme un type de programme appelé « circuit », qui calcule le résultat d'une fonction f(x, w) avec des entrées publiques et privées, puis prouve que pour un public donné input x , il existe une entrée privée w telle que le résultat de f(x, w) est True.
3. Application des ZK-SNARK dans des systèmes tels que Zcash et Tornado Cash
Il existe quelques différences mineures entre les différentes versions de Zcash et les systèmes qui s'en inspirent tels que Tornado Cash. Cependant, la logique sous-jacente sur laquelle ils s’appuient est très similaire. Cette section décrit une version simple qui correspond à peu près au fonctionnement de ces protocoles.
Les jetons sont constitués de secrets détenus par leurs propriétaires. Deux valeurs peuvent être dérivées de s :
● ID de jeton public L = hachage(s + 1)
● annulateurU = hachage(s + 2)
Parmi eux, le hachage fait référence à la fonction de hachage de mot de passe, telle que SHA 256. Étant donné s, l'ID du jeton et le zéroiseur peuvent être calculés. Cependant, étant donné un ensemble de zéroiseurs et un ID de jeton public, le comportement pseudo-aléatoire de la fonction de hachage garantit que vous ne pouvez pas déterminer quel zéroiseur est associé à quel ID de jeton à moins de connaître les secrets qui ont généré les deux.
La blockchain garde une trace de tous les identifiants de jetons qui ont été « créés » et de tous les annulateurs qui ont été « dépensés ». Les deux ensembles sont en croissance constante (à moins que le protocole ne veuille imposer le moment où les jetons doivent être dépensés).
Une collection d'ID de jeton est stockée dans une structure de données appelée arbre Merkle : si l'arbre contient N éléments, alors chaque élément adjacent est haché (ce qui donne ⌈ N/2 ⌉ hachages), et chaque élément adjacent. Ces hachages sont à nouveau hachés (ce qui donne en ⌈ N/4 ⌉ hachages), et ainsi de suite, jusqu'à ce que l'intégralité des données soit validée dans un seul « hachage racine ».
Étant donné une valeur spécifique dans un arbre et un hachage racine, vous pouvez fournir une branche Merkle : des "valeurs sœurs" qui sont hachées ensemble à chaque étape du chemin allant de cette valeur à la racine. Cette branche Merkle est très utile car il s'agit d'un petit morceau de données (hachages log 2(N)) qui peut être utilisé pour prouver qu'une valeur particulière se trouve réellement dans l'arborescence. La figure ci-dessous montre un exemple d'arbre Merkle d'une hauteur de 4.
Lorsque les utilisateurs envoient des pièces à d’autres, ils fournissent les éléments suivants :
● Annulateur U qui souhaite dépenser
● ID de jeton L' du nouveau jeton que vous souhaitez créer (le destinataire est invité à le fournir)
● Un ZK-SNARK.
ZK-SNARK contient les entrées privées suivantes :
● les secrets de l'utilisateur
● Branche Merkle dans l'arborescence des ID de jeton, prouvant que le jeton avec l'ID de jeton L = hash(s + 1) a effectivement été créé à un moment donné dans le passé.
Il contient également les contributions publiques suivantes :
● U, le zéroiseur des jetons dépensés
● R, le hachage racine contre lequel la preuve Merkle est dirigée
ZK-SNARK prouve deux propriétés :
● U = hachage(s + 2)
● Les succursales Merkle sont valides
En plus des ZK-SNARK, le protocole vérifie également les éléments suivants :
● R est le hachage racine actuel ou historique de l'arborescence des ID de jeton.
● U n'est pas dans l'ensemble des zéroiseurs épuisés
Si la transaction est valide, elle ajoute U à l'ensemble des zéroiseurs dépensés et L' à la liste des identifiants de jeton. Afficher U empêche qu’un seul jeton soit dépensé deux fois. Cependant, aucune autre information ne sera divulguée. **Le monde extérieur ne peut voir que quand les transactions sont envoyées ; il ne peut pas savoir qui envoie ou reçoit ces transactions et ne peut pas distinguer la source unifiée des jetons. **
Il existe deux exceptions au modèle ci-dessus : les dépôts et les retraits. Lors des dépôts, des identifiants de jeton peuvent être créés sans invalider un certain jeton précédent. Du point de vue de la préservation de la vie privée, les dépôts ne sont pas anonymes en raison de l'association entre un L donné et un événement externe qui permet d'ajouter L (dans Tornado Cash, le dépôt d'ETH dans le système ; dans Zcash, une nouvelle ZEC minière) est public.
En d’autres termes, les **dépôts sont liés à l’historique de leurs transactions passées. **Lors des retraits, un Zeroizer sera consommé sans ajouter de nouvel identifiant de jeton. Cela peut déconnecter les retraits des dépôts correspondants et indirectement de l’historique des transactions passées. Cependant, les retraits peuvent être liés à toute transaction future ayant lieu après l'événement de retrait.
La première version de Tornado Cash n'avait aucun concept de transferts internes, elle autorisait uniquement les dépôts et les retraits. Les versions ultérieures, encore au stade expérimental, autorisaient également les transferts internes et les pièces de diverses dénominations, y compris la prise en charge des opérations de « fractionnement » et de « fusion ». Nous discuterons de la manière d’étendre le système de transfert de pièces de confidentialité de base et le pool de confidentialité à des dénominations arbitraires dans les chapitres suivants.
4. ZK-SNARK dans le pool de confidentialité
** L'idée centrale du pool de confidentialité est que les utilisateurs prouvent non seulement que le retrait est associé à un dépôt précédent grâce à une preuve sans connaissance, mais prouvent également qu'il appartient à un ensemble d'associations plus strict. **La collection associée peut être un sous-ensemble de tous les dépôts effectués précédemment, une collection contenant uniquement les propres dépôts de l'utilisateur, ou quoi que ce soit entre les deux. L'utilisateur spécifie l'ensemble en fournissant la racine Merkle de l'ensemble associé comme entrée publique.
Comme le montre la figure ci-dessous, par souci de simplicité, nous ne prouvons pas directement que l'ensemble associé est bien un sous-ensemble des dépôts effectués précédemment ; au lieu de cela, nous demandons simplement à l'utilisateur d'utiliser le même identifiant de pièce comme nœud feuille pour prouver deux branches de Merkle grâce à une connaissance nulle :
● Entrez la branche Merkle de la racine R de l'ensemble total d'ID de pièces
● Entrez la branche Merkle de l'ensemble d'associations fourni RA racine
L'intention est de placer l'ensemble complet des associations quelque part (peut-être en chaîne). Le concept de base est le suivant : au lieu d'exiger des utilisateurs qu'ils précisent exactement de quel dépôt proviennent leurs retraits, ou à l'autre extrême, de ne fournir aucune autre information que la preuve qu'il n'y a pas eu de double dépense, nous permettons aux utilisateurs de proposer un ensemble d'options à partir desquelles les fonds peuvent être arrivés, et cet ensemble peut être aussi large ou étroit qu'ils le souhaitent.
Nous encourageons un écosystème qui permet aux utilisateurs de spécifier plus facilement un ensemble d'associations cohérentes avec leurs préférences. La suite de cet article décrira uniquement l’infrastructure basée sur ce mécanisme de base simple et ses conséquences.
3. Considérations pratiques et cas d'utilisation
Analysez la manière dont les protocoles améliorant la confidentialité sont utilisés dans la pratique du point de vue des applications.
1. Cas d'utilisation des collections associées
Pour illustrer la valeur de ce programme dans un environnement d’application de la loi, voici un exemple :
Supposons que nous ayons cinq utilisateurs : Alice, Bob, Carl, David, Eve. Les quatre premiers utilisateurs sont des utilisateurs honnêtes, respectueux des lois mais soucieux de leur vie privée, tandis qu'Eve est une voleuse. Parce que le public sait qu'Eve est une voleuse grâce à l'information selon laquelle les pièces de monnaie à l'adresse marquée « Eve » ont été volées. Dans la pratique, cela arrive assez souvent : sur les blockchains publiques, les fonds générés par les vulnérabilités exploitées dans les protocoles DeFi sont retracés pour identifier les fonds illicites entrant dans Tornado Cash.
Lorsque chacun des cinq utilisateurs effectue un retrait, il peut choisir quel ensemble associé spécifier. Leur ensemble d'associations doit inclure leurs propres dépôts, mais ils sont libres de choisir laquelle des autres adresses inclure. Les quatre premiers utilisateurs étaient motivés, d'une part, par le désir de protéger au maximum leur vie privée. Cela les motive à tendre à élargir leur ensemble d’associations. D’un autre côté, ils souhaitent réduire le risque que leurs pièces soient considérées comme suspectes par les commerçants ou les bourses. Il existe un moyen simple de procéder : ils n'incluent pas Eve dans leur collection associée. Par conséquent, pour eux quatre, le choix est clair : que leur ensemble d’associations soit {Alice, Bob, Carl, David}.
Bien entendu, Eve souhaite également maximiser son ensemble d’associations. Mais elle ne peut pas exclure ses propres dépôts, elle est donc obligée d'avoir son ensemble associé égal à l'ensemble des cinq dépôts. La sélection d’ensemble de participants associée est illustrée dans la figure ci-dessous.
Bien qu’Ève elle-même n’ait fourni aucune information, grâce à un simple processus d’élimination, nous pouvons tirer une conclusion claire : le retrait de la cinquième étape ne peut venir que d’Ève.
2. Construction des collections associées
La section précédente illustre une manière possible d'utiliser les collections associées dans un protocole de type pool de confidentialité et comment les participants honnêtes peuvent être séparés des mauvais. Notez que le système ne dépend pas de l'altruisme d'Alice, Bob, Carl et David ; ils ont des incitations claires pour justifier leur séparation. Regardons maintenant plus en détail la construction d'une collection associative. En général, il existe deux stratégies principales pour générer des collections associatives. Ils sont décrits ci-dessous et visualisés dans la figure ci-dessous.
● **Inclusion (ou adhésion) : **Identifier un ensemble spécifique de dépôts pour lesquels nous avons des preuves concluantes qu'ils présentent un faible risque, et créer un ensemble associé qui contient uniquement ces dépôts.
● Exclure : Identifiez un ensemble spécifique de dépôts que nous avons des preuves solides de considérer comme présentant un risque élevé et construisez un ensemble d'associations qui inclut tous les dépôts à l'exception de ces dépôts.
En pratique, les utilisateurs ne sélectionnent pas manuellement les dépôts à inclure dans leur collection associée. Au lieu de cela, les utilisateurs s'abonneront à des intermédiaires que nous appelons fournisseurs de collections d'associations (ASP), qui génèrent des collections d'associations avec des propriétés spécifiques. **Dans certains cas, les ASP peuvent être entièrement construits en chaîne, ne nécessitant aucune intervention humaine (ou IA). Dans d'autres cas, les ASP généreront indépendamment la collection associée et publieront la collection associée en chaîne ou ailleurs.
Nous recommandons fortement de publier au moins la racine Merkle de la collection d'associations sur la chaîne ; cela élimine la capacité des ASP malveillants à effectuer certains types d'attaques sur les utilisateurs (par exemple, donner à différents utilisateurs différentes collections d'associations dans le but de les désanonymiser). . L'ensemble de la collection doit être disponible via une API ou idéalement via un système de stockage décentralisé à faible coût tel que IPFS.
La possibilité de télécharger l'intégralité de l'ensemble associé est importante car elle permet aux utilisateurs de générer localement des preuves d'adhésion sans révéler aucune information supplémentaire à l'ASP, pas même les dépôts correspondant à leurs retraits.
Voici comment les ASP peuvent être créés en pratique :
● **Ajout différé pour exclure les mauvais acteurs : **Tout dépôt est automatiquement ajouté à la collection associée après un délai fixe (par exemple 7 jours), mais si le système détecte qu'un dépôt est associé à un mauvais comportement connu (par exemple un dépôt important -vol à grande échelle ou une adresse sur une liste de sanctions publiée par le gouvernement), la caution ne sera jamais ajoutée. En pratique, cela pourrait être réalisé grâce à des collections organisées par la communauté ou à des prestataires de services de filtrage de transactions existants qui ont déjà effectué le travail d'identification et de suivi des dépôts associés à un mauvais comportement.
● Frais mensuels par personne : Pour rejoindre un ensemble associé, la valeur du dépôt doit être inférieure à un certain maximum fixe, et le déposant doit prouver sans aucune connaissance qu'il détient un jeton d'identité (par exemple, par un gouvernement Pris en charge systèmes d’identification nationaux ou mécanismes légers tels que la vérification des comptes de réseaux sociaux). Mélangé avec un paramètre supplémentaire désignant le mécanisme de suppression pour le mois en cours afin de garantir que chaque identité ne peut engager des dépôts dans la collection associée qu'une fois par mois. La conception tente de mettre en œuvre l’esprit de nombreuses règles communes de lutte contre le blanchiment d’argent, selon lesquelles les petits paiements inférieurs à un certain seuil permettent un niveau plus élevé de confidentialité. Notez que cela peut être entièrement mis en œuvre sous forme de contrat intelligent, ne nécessitant aucune surveillance manuelle pour maintenir le fonctionnement continu.
● Frais mensuels pour membres de communauté de confiance : Similaires aux frais mensuels pour personne seule, mais plus restrictifs : les utilisateurs doivent prouver qu'ils sont membres d'une communauté hautement fiable. Les membres de la communauté, très confiants, acceptent de garantir mutuellement leur intimité.
● **Score en temps réel basé sur l'IA :**Le système AI ASP peut fournir un score de risque pour chaque dépôt en temps réel, et le système générera un ensemble associé contenant les dépôts dont le score de risque est inférieur à un certain seuil. Potentiellement, ASP pourrait générer plusieurs ensembles correspondant à plusieurs seuils de score de risque.
4. Description technique supplémentaire
Dans cette section, nous analysons la manière dont la proposition soutient les dénominations arbitraires et discutons de cas particuliers tels que la recertification, la certification directe bilatérale et la certification séquentielle.
1. Soutenez n'importe quelle confession
Le système monétaire simplifié de protection de la vie privée ci-dessus ne prend en charge que les transferts de devises de même dénomination. Zcash prend en charge les dénominations arbitraires en utilisant le modèle UTXO. Chaque transaction peut avoir plusieurs entrées (nécessité de publier un nilificateur pour chaque entrée) et plusieurs sorties (nécessité de publier un identifiant de jeton pour chaque sortie). Chaque ID de jeton créé doit être associé à une dénomination cryptographique. En plus de prouver la validité du zéroiseur, chaque transaction doit être accompagnée d'une preuve supplémentaire que la somme des dénominations des pièces créées n'excède pas la somme des dénominations des pièces dépensées. La figure ci-dessous illustre cette preuve supplémentaire.
Cette conception peut être étendue pour prendre en charge les dépôts et les retraits en traitant les dépôts comme des entrées (non cryptées) et les retraits comme des sorties (non cryptées). De plus, la conception peut être contrainte afin de simplifier l'analyse. Par exemple, seuls les retraits partiels pourraient être autorisés, de sorte que la transaction ait une entrée cryptée et deux sorties : une sortie non cryptée représentant le retrait, et une sortie cryptée « changement » représentant les fonds restants, qui pourront être utilisés pour de futurs retraits.
Une question naturelle est de savoir comment étendre cette conception pour prendre en charge les pools de confidentialité. L'insérer tel quel dans un pool de confidentialité n'est pas idéal car le graphique des transactions ne correspond pas à ce que nous attendons intuitivement : si un utilisateur dépose 10 jetons, puis dépense 1+2+3+4 en quatre jetons de retrait consécutifs, nous voulons traiter chacun des jetons. ces quatre retraits comme source du dépôt initial de 10 jetons. Mais le résultat réel est montré dans la figure ci-dessous : la source du premier retrait est le dépôt de 10 jetons, puis la source du deuxième retrait est la sortie de monnaie de 9 jetons créée par le premier retrait, et ainsi de suite par analogie. Cela pose des problèmes en pratique car cela nécessite qu'ASP valide le dépôt intermédiaire et l'ajoute à sa collection associée.
Pour que les quatre retraits de cet exemple aient comme source le dépôt initial de 10 pièces, nous devons résoudre deux problèmes :
● Assurez-vous que chaque retrait partiel n'est pas publiquement lié à d'autres retraits
● Autoriser chaque retrait partiel à inclure un dépôt en tant que membre de sa collection associée
Si nous ne prenons en charge que les retraits partiels, plutôt que les transactions MIMO plus complexes, et veillons à ce que chaque retrait ait un seul « dépôt original » correspondant défini, il existe plusieurs façons d'y parvenir directement. Une approche naturelle et évolutive consiste à diffuser la promesse de certaines informations par le biais de transactions. Par exemple, nous pouvons exiger que la transaction contienne un hachage d'engagement (coinID+hash®), ajouter une valeur aléatoire r pour assurer l'aveuglement et exiger que ZK-SNARK prouve que l'engagement dans la transaction est le même que sa transaction parent. Si la transaction parent elle-même est un retrait, l'engagement est le même que l'ID de pièce du dépôt d'origine, et si la transaction parent est un dépôt, l'engagement est le même que l'ID de pièce du dépôt d'origine. Par conséquent, chaque transaction de la chaîne doit contenir un engagement envers l'ID de pièce de dépôt d'origine et exiger la preuve que cette valeur fait partie de l'ensemble associé fourni par la transaction.
Pour améliorer la confidentialité contre les attaques d’agrégation de soldes, nous pouvons également prendre en charge la fusion de pièces. Par exemple, s’il me reste quelques pièces, je peux les fusionner avec celles-ci lors de mon prochain dépôt. Pour répondre à cela, nous pouvons exiger que les transactions s'engagent sur un ensemble d'identifiants de pièces et exiger que les transactions avec plusieurs entrées s'engagent sur l'union de leurs transactions parentes. Un retrait contiendra la preuve que tous ses identifiants de pièces engagés sont dans son ensemble associé.
2. Circonstances particulières
● **Recertification : **Les utilisateurs ont besoin d'informations de dépôt secrètes pour retirer des dépôts similaires aux protocoles de pool de confidentialité. Les mêmes informations secrètes sont également utilisées pour construire des preuves d’appartenance à un ensemble d’associations. La préservation des informations secrètes permet aux utilisateurs de générer de nouvelles preuves pour différents ensembles ou des ensembles associés mis à jour. Cela donne aux utilisateurs une plus grande flexibilité, mais peut également introduire des risques supplémentaires.
● Certification directe bilatérale : Dans certains cas, les utilisateurs peuvent être tenus de divulguer la source exacte du retrait à l'autre partie. Les utilisateurs peuvent créer une collection associée contenant uniquement leurs dépôts et générer des preuves par rapport à cette collection. Ces preuves sont généralement des exceptions et ne contribuent qu’à une confidentialité partielle lorsqu’elles sont partagées entre deux parties. Cependant, partager des preuves nécessite d’établir des hypothèses de confiance solides.
● Preuve de séquence : Dans une économie de transactions rapides utilisant un système de type pool de confidentialité, le protocole doit être modifié pour s'adapter à cet environnement. En plus des types de transactions de dépôt et de retrait, le protocole doit également prendre en charge les opérations d'envoi internes pour plus d'efficacité. De plus, en transmettant les fourchettes et les clés Merkle, les utilisateurs peuvent diffuser des informations relatives à l'historique des transactions afin que les destinataires puissent vérifier l'origine des fonds. Cela garantit que chaque utilisateur dispose du minimum d'informations requises pour avoir confiance dans les fonds reçus.
En pratique, un token peut avoir plusieurs « origines ». Par exemple, Bob est propriétaire d'un stand de café, il reçoit 5 jetons d'Alice, 4 jetons d'Ashley, 7 jetons d'Anne, et à la fin de la journée, il doit payer 15 jetons à Carl pour payer le dîner. Au lieu de cela, David a peut-être reçu 15 jetons de Carl, 25 jetons de Chris, et souhaite déposer 30 jetons à Emma (un échange). Dans ces cas plus complexes, nous suivons le même principe : l’histoire ajoutée à la collection associée depuis assez longtemps peut être ignorée, tandis qu’une histoire plus récente doit être transmise.
5. Plus de détails
Un système tel qu'un pool de confidentialité pourrait permettre aux utilisateurs d'obtenir une meilleure protection de la confidentialité de leurs données de transactions financières tout en conservant la capacité de prouver leur séparation des activités illégales connues. Nous espérons que les utilisateurs honnêtes seront incités à participer à un tel programme grâce à une combinaison de deux facteurs :
** ● Désir de confidentialité **
** ● Désir d'éviter d'éveiller les soupçons **
1. Consensus social et collecte associative
S’il y avait un consensus complet sur la question de savoir si les fonds sont bons ou mauvais, le système produirait un simple équilibre de séparation. Tous les utilisateurs possédant de « bons » actifs sont fortement incités et capables de prouver qu’ils appartiennent à un ensemble d’associations « uniquement bonnes ». En revanche, les mauvais acteurs ne seront pas en mesure de fournir une telle preuve. Ils peuvent toujours déposer de « mauvais » fonds dans le pool, mais cela ne leur rend aucun service. Tout le monde peut facilement déterminer que les fonds ont été retirés d'un protocole renforcé de confidentialité et voir que le retrait fait référence à une collection associée contenant des dépôts provenant de sources douteuses. De plus, la « mauvaise » monnaie n’entache pas la « bonne » monnaie. Lors du retrait de fonds de dépôts légitimes, leurs propriétaires peuvent simplement exclure tous les « mauvais » dépôts connus de leur collection associée.
Là où un consensus mondial existe et où les conclusions quant à savoir si le financement est considéré comme « bon » ou « mauvais » dépendent de la perspective sociale ou de la juridiction, l'ensemble des associations peut varier considérablement. Supposons qu'il existe deux juridictions avec des ensembles de règles différents. Les sujets des deux juridictions A et B peuvent utiliser le même protocole de renforcement de la confidentialité et choisir de délivrer des certifications qui répondent aux exigences de leurs juridictions respectives. Les deux peuvent facilement garantir la confidentialité de leurs propres collections associées et exclure les retraits qui ne sont pas conformes aux exigences de leurs juridictions respectives. Si nécessaire, une preuve d'adhésion peut être délivrée pour l'intersection de deux ensembles associés, prouvant ainsi de manière fiable que les dépôts correspondant à leurs retraits sont conformes aux exigences des deux juridictions.
La proposition est donc très flexible et doit être considérée comme une infrastructure neutre. D’une part, elle combat la censure. Il permet à quiconque de rejoindre une collection associée de son choix et de préserver la confidentialité au sein de sa propre communauté. D’un autre côté, des tiers peuvent exiger des preuves contre un ensemble particulier d’associations qui répondent à leurs exigences réglementaires. Ainsi, même s’il existe une communauté de mauvais acteurs dans un protocole renforçant la confidentialité, ils ne seront pas en mesure de dissimuler l’origine suspecte des dépôts tant que les informations sont reflétées avec précision dans la construction de l’ensemble associé.
2. Propriétés des collections associées
Les collections associatives doivent avoir certaines propriétés pour fonctionner. Les collectes doivent être précises afin que les utilisateurs puissent être sûrs qu'ils utilisent les fonds retirés en toute sécurité. De plus, les propriétés de chaque ensemble doivent être stables, c’est-à-dire moins susceptibles de changer dans le temps. Cela réduit le besoin de retraits de revalidation sur les nouvelles collections. Enfin, pour garantir une protection significative de la vie privée, l’ensemble d’associations doit être suffisamment grand et contenir différents types de dépôts. Cependant, ces propriétés s’opposent les unes aux autres. En général, les collections vastes et diversifiées peuvent avoir de meilleures propriétés de confidentialité, mais peuvent être moins précises et moins stables, tandis que les collections plus petites sont plus faciles à gérer mais offrent moins de confidentialité.
3. Considérations pratiques et concurrence
Les entités réglementées qui acceptent des crypto-actifs doivent s’assurer que les lois et réglementations auxquelles elles sont soumises permettent l’acceptation de tels fonds. Aujourd’hui, bon nombre de ces entités s’appuient sur ce que l’on appelle des outils de filtrage des transactions : des logiciels ou des services qui analysent la blockchain pour identifier des activités potentiellement suspectes, des liens vers des adresses illégitimes ou des transactions autrement non conformes. Les outils de filtrage expriment souvent le risque associé à chaque transaction via un score de risque. Cette note est basée sur la destination des fonds transférés et l'historique de leurs transactions. Les protocoles renforçant la confidentialité peuvent poser des défis à cet égard. Ils éliminent le lien visible entre les dépôts et les retraits. Par conséquent, en présence de protocoles améliorant la confidentialité, le score de risque doit prendre en compte l’attestation et attribuer un score basé sur l’ensemble des associations.
Les outils et services de filtrage des transactions sont principalement fournis par des sociétés professionnelles possédant une expertise dans l’analyse de la blockchain et les domaines juridiques connexes. Idéalement, ces entreprises (et toute autre personne) auraient accès à tous les certificats d’adhésion et aux collections associées correspondantes afin de fournir des scores de risque précis pour toutes les transactions. Par conséquent, nous recommandons que toutes les preuves soient stockées sur la blockchain ou sur un autre référentiel de preuves accessible au public. La seule exception est un certificat d’adhésion de taille unique partagé avec une contrepartie spécifique. Pour des raisons évidentes, ces témoignages ne devraient pas être rendus publics.
Le stockage des preuves directement sur la chaîne ajoute des coûts de transaction supplémentaires, mais réduit les efforts de coordination, rend la concurrence plus équitable et atténue les risques de quasi-monopole que les fournisseurs d'outils de filtrage peuvent créer en raison de la connaissance des preuves non publiques.
Les paramètres généraux d’un pool de confidentialité sont très flexibles. Le protocole peut être personnalisé pour différents cas d'utilisation en créant des collections spécifiques d'associations. Voici deux exemples de ces collections associatives particulières :
● **Les alliances de banques commerciales peuvent créer une collection associée contenant uniquement les dépôts de leurs clients. **Cela garantit que tous les retraits créés avec une preuve de collecte ont été soumis aux procédures de connaissance du client (KYC) et de lutte contre le blanchiment d'argent (AML) dans l'une des banques participantes, mais ne révèle pas quel retrait appartient à quel client.
● **Dans les cas où les intermédiaires financiers sont tenus de documenter clairement la source des fonds, ils peuvent exiger des utilisateurs qu'ils fournissent des preuves par rapport à un ensemble associé contenant uniquement les dépôts des utilisateurs. **Cette preuve sera ensuite échangée bilatéralement avec l'intermédiaire, lui permettant de suivre les fonds comme si l'utilisateur n'avait jamais utilisé le pool de confidentialité. Même si cela oblige les utilisateurs à faire confiance à l’intermédiaire pour ne pas révéler de preuves, cela permet idéalement aux utilisateurs de se conformer aux réglementations sans avoir à divulguer les informations au public.
4. Choix de conception et alternatives
Les configurations basées sur des ensembles d'associations, des preuves zk et des divulgations volontaires sont flexibles. Bien que cela soit très utile pour garantir que la proposition puisse être adaptée à différentes juridictions, il convient d'être très prudent en ce qui concerne les choix de conception spécifiques. Notamment deux aménagements potentiels auxquels nous nous opposons. Nous pensons qu'ils posent problème en termes d'exigences de confiance et peuvent créer des structures de marché quasi monopolistiques. Ci-dessous, nous décrivons et discutons brièvement de ces alternatives :
● Accès centralisé : les organismes chargés de l'application de la loi, les fournisseurs d'évaluation des risques cryptographiques ou des acteurs similaires peuvent accéder aux liens entre les transactions des utilisateurs tout en préservant la confidentialité des autres.
● **Liste blanche à l'échelle du système : **Les systèmes de confidentialité peuvent imposer des restrictions sur les types d'utilisateurs autorisés à déposer des pièces dans leurs pools, en les obligeant à fournir des preuves supplémentaires ou en exigeant que les dépôts attendent pendant une période de temps pendant laquelle la notation des risques est centralisée. le système peut refuser les dépôts.
Ces deux méthodes sont similaires dans la mesure où elles privilégient des entités spécifiques. Cela soulève des questions de gouvernance complexes : qui a accès à ces informations ? Qui a le pouvoir de gérer les autorisations ? Les entreprises privées ne semblent pas être une bonne option, car tout privilège peut créer une structure de marché oligopolistique, dans laquelle quelques entreprises ont accès aux données qui leur permettent de fournir ces services, tandis que d’autres ne sont pas en mesure de rivaliser.
De même, il existe de nombreux problèmes de gouvernance et politiques à résoudre lors de l’autonomisation des institutions publiques, en particulier dans un contexte international. Même si une institution est jusqu’à présent digne de confiance à 100 %, n’abusera pas de son pouvoir pour poursuivre un programme politique et ne dépend pas d’autres entités qui pourraient l’obliger à abuser de son pouvoir, cette situation est une manifestation de stagnation. Les organisations, les membres, les pays et les structures politiques au sein des organisations changent avec le temps. Il peut y avoir des pressions externes et l'existence de ces privilèges peut créer des incitations supplémentaires à perturber et à exercer une influence sur les systèmes de gouvernance de l'organisation.
De plus, les attaques à l’intérieur ou à l’extérieur de l’organisation, ou les erreurs de la part d’entités centralisées peuvent avoir des conséquences considérables. Nous pensons qu’il faut éviter la création de tels points de défaillance centralisés.
Cela dit, nous reconnaissons que différentes tailles de transactions et situations peuvent nécessiter différentes combinaisons de preuves. Par exemple, pour les transactions importantes, de nombreux utilisateurs peuvent finir par fournir une preuve d'exclusion de base en chaîne et fournir des informations plus détaillées sur la source des fonds à leurs contreparties.
5. L'orientation d'une recherche approfondie
Bien que cette étude donne un aperçu de la manière dont les protocoles d'amélioration de la confidentialité basés sur zkSNARK peuvent être utilisés dans des environnements réglementés, plusieurs aspects méritent des recherches plus approfondies.
Tout d’abord, il faut comprendre que la confidentialité obtenue grâce à ces protocoles dépend de nombreux facteurs différents. Les attaquants peuvent être en mesure d'associer les retraits à des dépôts spécifiques sur la base d'un ensemble d'associations insuffisamment grand, d'une mauvaise sélection de racine et d'une erreur de l'utilisateur.
De plus, les choix des autres utilisateurs peuvent nuire à votre propre vie privée. Dans des cas extrêmes, tous les autres membres du pool publieraient une preuve d’adhésion de taille un, révélant un lien direct entre leurs dépôts et leurs retraits. Évidemment, cela révélera implicitement le lien entre les seules transactions de dépôt et de retrait restantes. Dans un exemple plus subtil, les contraintes de diverses preuves d'adhésion pourraient être utilisées pour extraire des informations et potentiellement corréler les dépôts et les retraits avec une forte probabilité. Une fois ces informations attestées combinées aux métadonnées de transaction, les propriétés de confidentialité du protocole peuvent être compromises.
Enfin, les ASP malveillants peuvent choisir de compiler l'ensemble des associations proposées de manière à maximiser l'extraction d'informations ou à augmenter l'anonymat perçu en ajoutant des dépôts avec des retraits correspondants connus. Toutes ces questions nécessitent des recherches plus approfondies pour évaluer les propriétés de confidentialité fournies. Dans le même ordre d’idées, il serait intéressant d’étudier plus en détail les propriétés des équilibres de séparation, en modélisant le comportement des bons et des mauvais joueurs sous certaines hypothèses, et comment la preuve publique des premiers affecte la vie privée des seconds.
Les experts juridiques peuvent approfondir leurs recherches sur les exigences de divulgation spécifiques. Les scénarios présentés dans ce document sont flexibles et les conseils d'experts juridiques peuvent aider à adapter l'accord et l'écosystème construit autour de lui pour garantir la conformité dans diverses juridictions juridiques.
6. Conclusion
Dans de nombreux cas, la confidentialité et la conformité sont considérées comme étant en conflit. Cet article suggère que ce n'est pas nécessairement le cas si un protocole renforçant la confidentialité permet aux utilisateurs de prouver certaines propriétés de leur source de fonds. Par exemple, supposons que les utilisateurs puissent prouver que leurs fonds ne sont pas liés à des dépôts d’origine illicite connue, ou que les fonds font partie d’un ensemble spécifique de dépôts, sans divulguer d’autres informations.
Une telle configuration peut produire un équilibre de séparation dans lequel les utilisateurs honnêtes sont fortement incités à prouver qu'ils appartiennent à un ensemble associatif conforme et à préserver la confidentialité au sein de cet ensemble. A l’inverse, pour les utilisateurs malhonnêtes, ils ne peuvent pas fournir une telle preuve. Cela permet aux utilisateurs honnêtes de se dissocier des dépôts de tiers avec lesquels ils ne sont pas d'accord, ou de les empêcher d'utiliser leurs fonds dans un environnement conforme. Nous pensons que la proposition est très flexible et peut être ajustée en fonction de diverses exigences réglementaires potentielles.
Ce document doit être considéré comme une contribution à la potentielle coexistence future de la confidentialité et de la réglementation financières. Nous voulons faciliter les discussions et orienter la conversation dans une direction plus positive et constructive. Une collaboration entre praticiens, universitaires de diverses disciplines, décideurs politiques et régulateurs sera nécessaire pour élargir et réviser cette proposition ; le but ultime est de créer une infrastructure renforçant la confidentialité qui puisse être utilisée dans des environnements réglementés.