Introduction : Récemment, Vitalik et certains chercheurs ont co-publié un nouvel article, mentionnant comment Tornado Cash met en œuvre un schéma de lutte contre le blanchiment d'argent (permettant essentiellement au retraitant de prouver que son enregistrement de dépôt appartient à un ensemble qui ne contient pas d'argent sale), mais l'article manque d'une interprétation détaillée de la logique commerciale et des principes de Tornado Cash, laissant certains lecteurs perplexes.

Il convient de mentionner que les projets axés sur la confidentialité représentés par Tornade sont ceux qui exploitent véritablement la propriété de connaissance nulle de l'algorithme ZK-SNARK, tandis que la plupart des projets étiquetés ZK n'utilisent que la concision de ZK-SNARK. Les gens confondent souvent la différence entre la Preuve de validité et ZK, et Tornade sert d'excellent exemple pour comprendre l'application de ZK. L'auteur de cet article avait écrit sur les principes de Tornade en 2022 pour Web3Caff Research, et sélectionne aujourd'hui et développe certaines sections de cet article, les organisant dans cet article pour comprendre systématiquement Tornade Cash.

Lien de l'article original : https://research.web3caff.com/zh/archives/2663?ref=157

Le principe de « Tornado »

Tornado Cash utilise un protocole de mélange de pièces basé sur des preuves de connaissance nulle, sa version plus ancienne ayant été lancée en 2019 et une nouvelle version bêta ayant été publiée vers la fin de 2021. La version plus ancienne de Tornado a atteint un haut niveau de décentralisation, avec ses contrats on-chain étant open source et non contrôlés par un mécanisme de multisignature, et son code frontend étant également open source et sauvegardé sur le réseau IPFS. En raison de la structure plus simple et plus compréhensible de l'ancienne version de Tornado, cet article se concentre sur l'expliquer. L'idée principale derrière Tornado est de mélanger un grand nombre d'actions de dépôt et de retrait ensemble. Après avoir déposé des jetons dans Tornado, les déposants présentent une preuve de ZK pour prouver qu'ils ont effectué un dépôt, puis effectuent un retrait vers une nouvelle adresse, rompant ainsi le lien entre les adresses de dépôt et de retrait.

Plus précisément, Tornado agit comme une boîte en verre remplie de pièces déposées par de nombreuses personnes. Nous pouvons voir qui a déposé les pièces, mais comme les pièces sont très homogénéisées, il est difficile de retracer quelle pièce a été déposée par qui si une personne non familière retire une pièce.

(Source: rareskills)Ce scénario est assez courant; par exemple, lorsque nous échangeons de l'ETH dans une pool Uniswap, nous ne pouvons pas savoir de qui nous recevons l'ETH car de nombreuses personnes ont fourni de la liquidité à Uniswap. Cependant, la différence est que chaque fois que vous échangez des jetons sur Uniswap, vous devez utiliser d'autres jetons comme coût équivalent, et vous ne pouvez pas transférer des fonds de manière “privée” à quelqu'un d'autre; tandis qu'avec un mélangeur, vous avez seulement besoin de montrer une preuve de dépôt pour retirer. Pour rendre les actions de dépôt et de retrait homogènes, chaque dépôt dans un pool Tornado et chaque retrait de celui-ci est maintenu à un montant constant. Par exemple, s'il y a 100 déposants et 100 retraitants dans un pool, bien qu'ils soient visibles, ils semblent non liés, et le montant déposé et retiré par chacun est le même.

Cela peut obscurcir la traçabilité des transferts de fonds, offrant une commodité naturelle pour anonymiser les transactions. La question clé est : comment un retraitant prouve-t-il qu'il a effectué un dépôt ?

L'adresse à partir de laquelle le retrait est effectué n'est liée à aucune adresse de dépôt, donc comment peut-on déterminer leur éligibilité au retrait? La méthode la plus directe semble être que le retraitant divulgue quel enregistrement de dépôt est le leur, mais cela révélerait directement leur identité. C'est là que les preuves à divulgation nulle entrent en jeu. En présentant une preuve à divulgation nulle qu'ils ont un enregistrement de dépôt dans le contrat Tornado qui n'a pas encore été retiré, un retraitant peut initier un retrait avec succès. Les preuves à divulgation nulle protègent intrinsèquement la vie privée, ne révélant que le fait que la personne a effectivement effectué un dépôt dans le fonds commun, sans divulguer à quel déposant elle correspond.

Pour prouver que « J’ai effectué un dépôt dans le pool de fonds Tornado » peut être traduit par « Mon historique de dépôt se trouve dans le contrat Tornado ». Si nous utilisons Cn pour représenter un enregistrement de dépôt, le problème devient : étant donné que l’ensemble des enregistrements de dépôt de Tornado est {C1, C2, ... C100...}, le retrait, Bob, prouve qu’il a utilisé sa clé pour générer du Cn dans les enregistrements de dépôt sans révéler de quel Cn il s’agit. Il s’agit de la propriété spéciale de Merkle Proof. Tous les enregistrements de gisement de Tornado sont incorporés dans un arbre de Merkle construit sur la chaîne, avec ces enregistrements comme nœuds de feuille de niveau inférieur. Le nombre total de feuilles est d’environ 2^20 > 1 million, dont la plupart sont à l’état vide (une valeur initiale leur est attribuée). Chaque fois qu’un nouveau dépôt se produit, le contrat enregistre sa valeur unique, l’engagement, dans une feuille, puis met à jour la racine de l’arbre de Merkle.

Par exemple, si le dépôt de Bob était le 10 000e dans l'histoire de Tornado, la valeur caractéristique Cn associée à ce dépôt serait entrée dans le 10 000e nœud feuille de l'arbre de Merkle, c'est-à-dire C10000 = Cn. Le contrat calcule alors automatiquement une nouvelle racine et la met à jour. Pour économiser des ressources de calcul, le contrat Tornado met en cache les données d'un lot de nœuds modifiés précédemment, tels que Fs1, Fs2 et Fs0 dans le diagramme ci-dessous.

(Source: RareSkills)

La preuve de Merkle, par sa nature, est concise et légère, exploitant la simplicité des structures de données arborescentes dans les processus de recherche/tracé. Pour prouver de manière externe qu'une transaction TD existe dans un arbre de Merkle, il suffit de fournir une preuve de Merkle correspondant à la racine, ce qui est assez simple. Si l'arbre de Merkle est particulièrement grand, avec 2^20 feuilles au niveau inférieur (c'est-à-dire 1 million d'enregistrements de dépôt), une preuve de Merkle ne nécessiterait que les valeurs de 21 nœuds, ce qui est très court.

Pour prouver que la transaction H3 est effectivement contenue dans un arbre de Merkle, il faut démontrer qu'en utilisant H3 et d'autres parties de données sur l'arbre de Merkle, la Racine peut être générée, et que les données nécessaires à la génération de la Racine (y compris Td) constituent la Preuve de Merkle. Lorsque Bob effectue un retrait, il doit prouver que son certificat correspond à un hachage de dépôt Cn enregistré sur l'arbre de Merkle dans le grand livre de Tornado. En d'autres termes, il doit prouver deux choses : Cn existe dans l'arbre de Merkle fictif de Tornado sur la chaîne, en construisant spécifiquement une Preuve de Merkle contenant Cn ; Cn est associé au certificat de dépôt de Bob.

La logique commerciale de Tornado expliquée

Dans le code frontend de l'interface utilisateur Tornado, de nombreuses fonctionnalités sont pré-implementées. Lorsqu'un déposant ouvre la page web Tornado Cash et clique sur le bouton de dépôt, le code frontend accompagnant génère localement deux nombres aléatoires, K et r. Il calcule ensuite la valeur de Cn=Hash(K, r) et transmet Cn (appelé engagement dans le diagramme ci-dessous) au contrat Tornado, qui l'insère dans l'Arbre de Merkle enregistré par ce dernier. Essentiellement, K et r agissent comme des clés privées. Ils sont cruciaux, et le système incite les utilisateurs à les sauvegarder de manière sécurisée. K et r sont à nouveau nécessaires lors du retrait.

(L'option encryptedNote permet aux utilisateurs de chiffrer le certificat K et r avec une clé privée et de le stocker sur la blockchain pour éviter tout oubli) Il est important de noter que toutes ces opérations se déroulent hors chaîne, ce qui signifie que le contrat Tornado et les observateurs externes sont inconscients de K et r. Si K et r sont divulgués, c'est semblable au vol des clés privées du portefeuille.

À la réception d’un dépôt de la part d’un utilisateur et de la soumission de Cn=Hash(K, r), le contrat Tornado enregistre Cn dans la couche inférieure de l’arbre de Merkle en tant que nouveau nœud feuille, mettant également à jour la valeur Root. Par conséquent, Cn est directement lié à l’action de dépôt de l’utilisateur, ce qui permet aux personnes extérieures de savoir quel utilisateur correspond à chaque Cn, qui a déposé des jetons dans le mélangeur et les enregistrements de dépôt Cn de chaque déposant.

Lors du processus de retrait, le retraitant saisit la clé d'authentification/clé privée (les nombres aléatoires K et r générés lors du dépôt) sur la page web frontend. Le programme dans le code frontend de Tornado Cash utilise K et r, Cn=Hash(K, r), et la Preuve de Merkle correspondant à Cn en tant que paramètres d'entrée pour générer une Preuve de Connaissance Zero-Knowledge (ZK). Cela prouve que Cn existe dans l'Arbre de Merkle en tant qu'enregistrement de dépôt, et que K et r sont les clés correspondant à Cn. Cette étape prouve essentiellement : Je connais la clé correspondant à un enregistrement de dépôt sur l'Arbre de Merkle. Lorsque la Preuve de ZK est soumise au contrat Tornado, ces quatre paramètres sont cachés, protégeant la vie privée. La génération de la Preuve de ZK implique des paramètres supplémentaires, y compris la racine de Merkle enregistrée dans le contrat Tornado au moment du retrait, une adresse de destinataire personnalisée A, et un identifiant nf pour empêcher les attaques de rejeu. Ces trois paramètres sont publiés sur la blockchain, ce qui ne compromet pas la vie privée.

Un détail à noter est l'utilisation de deux nombres aléatoires, K et r, pour générer Cn au lieu d'un seul nombre aléatoire, offrant une sécurité accrue contre les collisions. A représente l'adresse du destinataire du retrait, choisie par le retirant. L'identifiant nf, conçu pour prévenir les attaques de rejeu, est calculé comme nf=Hash(K), où K est l'un des deux nombres aléatoires utilisés à l'étape du dépôt pour générer Cn. Cela lie nf directement à Cn, établissant une corrélation un à un entre chaque Cn et son nf correspondant. Le but de prévenir les attaques de rejeu est dû à la fonctionnalité de conception du mélangeur, qui garde l'association entre les montants de retrait et les feuilles spécifiques de l'arbre de Merkle (Cn) inconnue, permettant l'abus potentiel de retraits répétés jusqu'à ce que le fonds soit épuisé.

L'identifiant nf fonctionne de manière similaire au nonce associé à chaque adresse Ethereum, empêchant les relectures de transaction. Lorsqu'un retrait se produit, une vérification assure que le nf soumis n'a pas été utilisé auparavant ; s'il est inutilisé, le retrait est valide et le nf est enregistré. Toute tentative de générer un nf non associé à un dépôt enregistré Cn échouera à produire une preuve ZK valide, rendant le retrait infructueux.

Si quelqu'un génère aléatoirement un contrat non fongible (nf) non enregistré, cela fonctionnerait-il ? Bien sûr que non. Lorsque le retraitant génère une Preuve de Connaissance Zéro (ZK Proof), il doit s'assurer que nf est égal au Hash (K), où le nombre aléatoire K est associé à l'enregistrement de dépôt Cn. Cela signifie que nf est lié à un enregistrement de dépôt enregistré Cn. Si quelqu'un fabrique arbitrairement un nf, ce nf ne correspondra à aucun enregistrement de dépôt, rendant impossible la génération d'une ZK Proof valide. Par conséquent, le processus de retrait ne peut pas être complété avec succès, et l'opération de retrait échouera. Certains pourraient demander : Est-il possible de procéder sans nf ? Puisque le retraitant doit soumettre une preuve ZK lors du retrait pour prouver son association avec un certain Cn, pourquoi ne pas simplement vérifier si la preuve ZK correspondante a été soumise à la blockchain à chaque fois qu'un retrait se produit ? Cependant, cette approche est très coûteuse car le contrat Tornado Cash ne stocke pas de manière permanente les preuves ZK passées en raison d'un gaspillage important d'espace de stockage. Comparer chaque nouvelle preuve ZK soumise à la blockchain avec les preuves existantes est moins efficace que de définir un petit identifiant comme nf et de le stocker de manière permanente.

Selon l'exemple de code de la fonction de retrait, les paramètres requis et la logique métier sont les suivants : L'utilisateur soumet une preuve ZK et nf (NullifierHash) = Hash (K), spécifie une adresse du destinataire pour le retrait, et la preuve ZK dissimule les valeurs de Cn, K, et r, rendant impossible pour les étrangers de déterminer l'identité de l'utilisateur. Le destinataire utilise souvent une nouvelle adresse propre qui ne révèle pas d'informations personnelles.

Cependant, il y a un problème mineur : lorsque les utilisateurs effectuent des retraits pour rester anonymes, ils initient souvent la transaction de retrait à partir d'une adresse nouvellement créée. À ce moment-là, la nouvelle adresse ne contient pas d'ETH pour payer les frais de gaz. Par conséquent, lors de l'initiation d'un retrait, l'adresse de retrait doit explicitement déclarer un relais pour payer les frais de gaz en son nom. Ensuite, le contrat de mixage déduit une partie du retrait de l'utilisateur pour compenser le relais.

En résumé, Tornado Cash peut obscurcir la connexion entre les personnes effectuant des retraits et les déposants. Dans des situations avec une grande base d'utilisateurs, c'est comme un criminel se fondant dans la foule dans une zone animée, ce qui rend difficile pour la police de suivre. Le processus de retrait implique l'utilisation de ZK-SNARKs, la partie témoin cachée contenant des informations critiques sur le retraitant, ce qui est un aspect clé de l'ensemble du mélangeur. Actuellement, Tornado semble être l'un des projets de couche d'application les plus ingénieux liés à ZK.

Avertissement：

1. Cet article est repris de [GateGeek Web3]Tous les droits d'auteur appartiennent à l'auteur original [Faust, geek web3]. Si des objections sont soulevées concernant cette reproduction, veuillez contacter le Porte Apprendreéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, il est interdit de copier, distribuer ou plagier les articles traduits.