Le développeur ameen.eth combine le concept de “Preuve d’Innocence” avec Tornado Cash pour donner une autre direction que “la vie privée n’est pas égale au crime”.
Écrit par : Albert Lin
Préface
TornadoCash est un service de transaction anonyme bien connu dans le monde de la crypto-monnaie. TornadoCash utilise la technologie ZKP (Zero-Knowledge Proof) pour masquer la source des fonds. Le gouvernement américain a fait valoir qu’un tel mécanisme facilitait les activités de flux financiers illicites et a finalement été sanctionné par le département du Trésor américain en août 2022 et contraint de le retirer des étagères. La protection de la vie privée et le blanchiment d’argent semblent toujours aller de pair dans de nombreux cas. Tout en recherchant la confidentialité, les criminels utilisent souvent ces fonctionnalités de confidentialité pour blanchir des fonds illégaux. Peut-on trouver un moyen qui permette aux gens d’avoir une vie privée tout en freinant efficacement le blanchiment d’argent ? Privacy-Pools par ameen.eth, l’un des premiers développeurs de TornadoCash, peut donner une direction. (Seuls le site Web frontal et le référentiel GitHub sont affectés pour la partie de suppression, et la partie contractuelle n’est pas affectée car elle se trouve sur la blockchain. Enfin, GitHub a restauré le référentiel sous les efforts de l’Electronic Frontier Foundation. Pour plus de détails, veuillez voir ici)
Introduction Principe de TornadoCash
Avant d’introduire Privacy-Pools, vous devez comprendre les principes de conception liés à TornadoCash. Pour une introduction détaillée, veuillez vous référer à mon article précédent “Breaking Down TornadoCash : Un guide du débutant pour expliquer sa fonctionnalité aux amis”. Voici un bref aperçu des principes de conception de TornadoCash.
TornadoCash utilise des reçus (engagements) pour contrôler l’accès. Le reçu est généré en hachant le secret (valeur secrète) et l’annulateur (code de déconnexion), et chaque reçu ne peut être retiré qu’une seule fois. Utilisez Merkle Tree (arbre de hachage) pour enregistrer les informations de dépôt, utilisez le reçu comme nœud feuille et calculez Merkle Root (racine de l’arbre de hachage). L’utilisateur n’a qu’à fournir les données de la feuille à la racine pour prouver si les données sont l’une des feuilles de l’arbre Merkle, et prouver indirectement qu’il y a eu des dépôts de fonds sur TornadoCash auparavant. Utilisez Zero-Knowledge Proof pour masquer la source du dépôt et utilisez l’annulateur pour empêcher l’attaque Double Retrait.
Le reçu de TornadoCash a deux significations
- Preuve que l’expéditeur a déposé des fonds avant
- Assurez-vous que chaque destinataire ne peut réclamer des fonds qu’une seule fois
「Preuve-d’innocence」
Selon le principe de conception de TornadoCash, on peut seulement savoir que les fonds reçus doivent provenir d’un dépôt précédent, mais on ne sait pas de quel dépôt ils proviennent. C’est le but principal des criminels qui utilisent TornadoCash pour des activités illégales de blanchiment d’argent, et c’est aussi la raison pour laquelle le gouvernement américain réglemente TornadoCash. Si nous pouvons proposer une autre preuve (ZKP) pour prouver que les fonds reçus ne proviennent pas des dépôts sur la liste de rejet, s’il peut prouver que le paiement ne provient pas de criminels, c’est la “preuve d’innocence” ("preuve de innocence ») concept de base.
Le concept de “Preuve d’Innocence” peut être divisé en deux directions
- Preuve que les fonds reçus proviennent de la collecte des fonds déposés dans la liste autorisée (liste autorisée)
- Preuve que les fonds retirés ne proviennent pas de l’ensemble des fonds de dépôt sur la liste de rejet (liste de rejet)
Ces deux méthodes peuvent prouver que les fonds de retrait ne proviennent pas des dépôts de la liste de rejet. L’approche dans la figure ci-dessous consiste à utiliser la liste de rejet pour prouver que les fonds reçus ne proviennent pas du dépôt (rouge) dans la liste de rejet.
source:
Principe de conception des piscines privées
Privacy-Pools ajoute le concept de “Preuve d’Innocence” à TornadoCash. En plus de la signification originale du reçu TorandoCash, le reçu de paiement Privacy-Pools a une troisième signification : “prouver que les fonds reçus proviennent des dépôts de la liste autorisée”.
Le reçu de Privacy-Pools signifie :
- Preuve que l’expéditeur a déposé des fonds avant
- Assurez-vous que chaque destinataire ne peut réclamer des fonds qu’une seule fois
- Preuve que les fonds à retirer proviennent de dépôts dans la liste autorisée
Ici, nous utilisons Autoriser Merkle Tree pour expliquer comment Privacy-Pools utilise la “preuve d’innocence” dans ce système (Autoriser Merkle Tree est le concept d’utilisation de la liste d’autorisation). Tout d’abord, Allow Merkle Tree a plusieurs caractéristiques
- Autoriser l’arbre Merkle comme son nom l’indique est un arbre Merkle
- La hauteur de l’arbre et le nombre de nœuds sont les mêmes que ceux de l’arbre de dépôt Merkle des pools de confidentialité.
*Toutes les feuilles de l’arbre Autoriser Merkle correspondent à la position de la feuille Dépôt de l’arbre Merkle (dépôt).
Autoriser les données de feuilles de Merkle Tree peuvent être divisées en deux catégories :
- autorisé : Indique que le dépôt à cet endroit est autorisé. (Les positions qui n’ont pas encore été déposées sont également autorisées par défaut)
- bloqué : Indique que le dépôt à cet emplacement est rejeté.
Comme le montre la figure ci-dessous, les positions des index 0 et 1 sont toutes deux des fonds légaux dans l’arborescence de dépôt Merkle, et les positions correspondantes de la feuille Autoriser l’arborescence Merkle sont également autorisées.
En supposant qu’aujourd’hui un criminel veuille mener des activités de blanchiment d’argent, il dépose les fonds illégaux obtenus après l’attaque dans Privacy-Pools, et le lieu de dépôt est l’indice Deposit Merkle Tree : 2. Nous savons qu’il s’agit de fonds illégaux, nous le mettons donc à jour pour qu’il soit bloqué à la position correspondante de l’indice Allow Merkle Tree : 2.
### Situation de collecte de la liste des autorisations
En supposant qu’aujourd’hui, un utilisateur qui dépose dans la liste autorisée du gouvernement américain souhaite retirer des fonds, il doit fournir “la preuve que le dépôt est dans l’arbre Dposit Merkle” et “la preuve que celui de la liste autorisée des États-Unis est autorisé”. La preuve correspondant à la liste blanche américaine comprend la racine Allow Merkle (fournie par l’utilisateur, subetRoot dans le code) et la valeur du nœud qui sera transmise en cours de route. Lorsque Privacy-Pools vérifie l’étape ZKP, il utilise la valeur feuille autorisée (keccak256 (autorisé) dans le code réel) et la valeur de nœud donnée à traverser pour construire une racine Merkle. Vérifiez que cette racine Merkle est identique à la racine Merkle autorisée fournie par l’utilisateur. Si la vérification du même représentant est réussie, cela signifie que le fonds pour le retrait provient d’un dépôt qui existe dans la liste d’autorisation du gouvernement américain.
Situation de collecte de la liste de rejet
Aujourd’hui, un utilisateur qui ne figure pas sur la liste autorisée du gouvernement américain souhaite retirer des fonds, et le lieu de dépôt correspondant est marqué comme bloqué dans la liste autorisée du gouvernement américain. Cela empêchera l’utilisateur d’utiliser la liste d’autorisation Autoriser Merkle Root du gouvernement américain pour retirer des fonds, car la preuve correspondante ne peut pas être générée et la vérification échouera (car Privacy-Pools utilise la valeur de allow for leaf to do calculs, et la liste des autorisations du gouvernement américain sera L’emplacement est marqué comme bloqué, de sorte que la même racine de Merkle ne peut pas être calculée).
Une telle conception oblige l’utilisateur à fournir une autre racine Autoriser Merkle à retirer des fonds (d’autres arbres Autoriser Merkle doivent marquer l’emplacement du dépôt comme autorisé afin de calculer la même racine Autoriser Merkle à passer la vérification). Cet autre arbre Autoriser Merkle peut être maintenu par d’autres gouvernements ou institutions, ou même généré par cet utilisateur lui-même. Aujourd’hui, le gouvernement américain peut utiliser la racine Allow Merkle utilisée lors du retrait pour déterminer si les fonds de l’utilisateur sont conformes aux lois et réglementations du gouvernement américain, afin d’atteindre l’objectif de suivi. Si l’utilisateur utilise l’arbre Autoriser Merkle généré par lui-même ou non crédible, le fonds de retrait est très susceptible de provenir d’un dépôt problématique (chaque tiers crédible Autoriser Merkle Arbre marque l’emplacement du dépôt comme bloqué).
Questions fréquemment posées
**Q : Si l’Allowroot est fourni par le retraiteur, est-il possible de falsifier une fausse racine d’Allow Merkle pour prouver que la feuille est un dépôt dans la liste autorisée, cela signifie-t-il que l’argent peut toujours être retiré ? **
R : La réponse est oui, il est en effet possible de retirer l’argent. L’auteur a spécifiquement souligné qu’un tel mécanisme n’est pas d’interdire aux criminels de retirer l’argent, mais même s’ils peuvent le retirer, on saura que les fonds sont des fonds sur la liste de rejet. Lorsque le retraiteur fournit une racine d’autorisation Merkle peu convaincante, il peut fondamentalement être considéré comme se retirant de la liste de rejet. L’auteur suppose que la raison de cette autorisation est de maintenir la nature décentralisée de ce service. Parce que chaque arbre Allow Merkle a besoin d’une certaine gestion d’autorité pour mettre à jour le statut de chaque feuille. Si une certaine racine d’arbre d’autorisation est obligatoire, cela signifie que quelqu’un a une certaine autorité pour contrôler le retrait des fonds, ce qui n’est pas conforme à l’esprit de la décentralisation.
**Q : Qui décidera si la transaction provient des fonds de la liste de rejet ? **
R : La partie que j’ai vue n’a pas été spécifiquement mentionnée, et je crois comprendre que cette partie devrait être effectuée par chaque agence de réglementation. En supposant qu’aujourd’hui le gouvernement américain veuille vérifier l’argent sale de Privacy-Pools, il peut vérifier s’il s’agit d’argent sale en vérifiant la racine d’autorisation Merkle de chaque transaction. Quant au type d’Autoriser Merkle Root autorisé, c’est à chaque organisme de réglementation de juger par lui-même.
Code de confidentialité des piscines
Le code principal et les propres commentaires de l’auteur sont joints ici, dans l’espoir d’aider tout le monde à comprendre la logique principale à travers le code.
// circuits/retrait_de_sous-ensemble.circom
modèle Retirer du sous-ensemble (niveaux, valeur attendue) {
// public
racine d’entrée de signal ;
sous-ensembleRoot d’entrée de signal ;
annuleur d’entrée de signal ;
entrée de signal assetMetadata ; // abi.encode(jeton, montant).snarkHash();
signal d’entrée retirer les métadonnées ; // abi.encode(destinataire, remboursement, relais, frais).snarkHash();
// privé
secret d’entrée de signal ;
chemin d’entrée du signal ; // Indique si les données représentent la feuille gauche ou la feuille droite.
entrée de signal mainProof [levels] ; // Construire les données requises pour la racine du dépôt.
sous-ensemble d’entrée de signalProof [levels] ; // Construire les données requises pour allow root.
// Calcule l’annulateur et l’engagement.
hacheur de composant = CommitmentNullifierHasher();
hasher.secret <== secret ;
hash.path <== chemin ;
hasher.assetMetadata <== assetMetadata;
nullifier === hasher.nullifier;
// valeur attendue : keccak256(“autorisé”) % p
composant doubleTree = DoubleMerkleProof (niveaux, valeur attendue);
doubleTree.leaf <== hasher.commitment;
// Convertit le chemin en bits pour spécifier s’il s’agit de la feuille gauche ou de la feuille droite.
// On peut observer que l’arbre de dépôt et l’arbre d’autorisation partagent le même chemin.
doubleTree.path <== chemin ;
pour ( je = 0; je < niveaux; je++) {
doubleTree.mainProof [i] <== mainPreuve [i] ;
doubleTree.subsetProof [i] <== sous-ensemblePreuve [i] ;
}
root === doubleTree.root; // Vérifiez la racine du dépôt.
subsetRoot === doubleTree.subsetRoot ; // Vérifiez la racine autorisée.
signal retireMetadataSquare ;
retireMetadonnéesCarré <== retireMetadonnées * retireMetadonnées;
}
##TLDR
- “Preuve d’innocence” consiste à utiliser une autre preuve pour prouver que le paiement provient du dépôt dans la liste autorisée. La « preuve d’innocence » peut être construite à partir de deux perspectives : la liste d’autorisation et la liste de refus.
- Privacy-Pools superpose le concept de “Preuve-d’Innocence” sur la base de TornadoCash.Le reçu original représente une troisième signification : “Preuve que les fonds reçus proviennent des dépôts dans la liste autorisée.”
- L’existence de l’arbre Allow Merkle peut prouver que le retrait de fonds existe dans la liste autorisée. La position de la feuille de l’arbre Merkle autorisé correspond à la position de la feuille de dépôt de l’arbre Merkle de dépôt. Autoriser les données de feuilles de Merkle Tree est autorisé et bloqué.
- En plus des informations requises pour construire la racine de dépôt Merkle, le destinataire doit également fournir les informations de racine d’autorisation de merkle et de construction d’autorisation de racine de merkle pour prouver que le retrait de fonds existe dans la liste autorisée.
- Étant donné que la racine Autoriser Merkle est fournie par le destinataire, les criminels ont toujours un moyen de retirer les fonds illégaux via la fausse racine Autoriser Merkle. Le faux Allow Merkle Root apparaîtra toujours sur la chaîne et sera considéré par d’autres comme douteux quant au paiement, afin de suivre le flux de fonds illégaux.
Le développeur ameen.eth combine le concept de “preuve d’innocence” avec TornadoCash pour fournir une autre direction selon laquelle “la vie privée n’est pas égale au crime”. L’auteur trouve intéressant d’utiliser un autre ZKP pour prouver un autre fait, qui ressemble un peu à l’addition de ZKP. Ce mode d’utilisation sera plus simple et plus efficace que la construction d’un ZKP plus grand et plus complexe. En ce qui concerne le choix de Allow Merkle Tree, je pense qu’il sera construit par une unité plus juste à l’avenir, qui sera plus persuasive pour les autres.
Enfin, merci à Chih-Cheng Liang et Ping Chen pour leur aide à la révision de l’article et leurs précieux avis !
Référence :
Adresse furtive
Analyse des instances de Tornado Cash
Introduction au développement des ZKP et des contrats intelligents
[Club de lecture ZKP] TornadoCash
Tornado Cash — Comment ça marche | DeFi + Preuve de connaissance zéro
Compréhension approfondie des détails techniques de TornadoCash
0xhhh Thread présentant les nouvelles fonctionnalités et leurs principes
vidéo de démonstration
L’exposé de Vitalik sur la façon d’améliorer Tornadov2
pools de confidentialité v0tweet
Présentation de la preuve d’innocence basée sur TornadoCash
