Introduction :

Récemment, Vitalik et plusieurs chercheurs ont publié conjointement un nouvel article qui aborde la façon dont Tornado Cash met en œuvre son système de lutte contre le blanchiment d'argent (permettant essentiellement au destinataire de prouver que son historique de dépôt appartient à un ensemble qui n'inclut pas de fonds souillés). Cependant, l'article manquait d'une explication détaillée de la logique commerciale et des principes de Tornado Cash, laissant ainsi certains lecteurs avec une compréhension superficielle.

Il convient de noter que des projets comme Tornado, qui représentent des entreprises axées sur la confidentialité, utilisent véritablement l'aspect de connaissance nulle de l'algorithme ZK-SNARK. Pendant ce temps, la plupart des solutions arborant le drapeau ZK, telles que les Rollups, exploitent simplement la concision de ZK-SNARK. Souvent, les gens ont tendance à confondre la Preuve de Validité avec ZK, et Tornado sert d'excellent exemple pour clarifier l'application du monde réel de ZK.

L'auteur de cet article avait rédigé un article sur les principes de Tornado en 2022 pour la recherche Web3Caff. Aujourd'hui, nous avons extrait et développé certaines sections de ce travail original pour fournir une compréhension systématique de Tornado Cash.

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

Le principe de "Tornado"

Tornado Cash utilise la preuve de connaissance nulle comme protocole de mélange. Alors que sa version plus ancienne a été lancée en 2019, une version bêta du modèle mis à jour a été déployée à la fin de 2021. La version antérieure de Tornado a atteint un bon niveau de décentralisation avec des contrats on-chain étant open-source et exempts de contrôles de signature multiple. De plus, le code frontend était open-source et sauvegardé sur le réseau IPFS. En raison de la simplicité de l'ancienne version de Tornado, cet article se concentre sur son explication.

L'approche principale de Tornado est de mélanger de nombreuses 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 ZK pour vérifier leur dépôt précédent, puis effectuent un retrait en utilisant une nouvelle adresse, rompant ainsi le lien entre les adresses de dépôt et de retrait.

Pour le dire plus succinctement, imaginez Tornado comme une boîte en verre remplie de pièces (Coins) déposées par de nombreuses personnes. Nous pouvons voir qui a déposé les pièces, mais ces pièces sont très homogènes. Si une personne non familière devait prendre une pièce dans la boîte, il serait difficile de retracer qui a initialement mis cette pièce là.

(Source de l'image: rareskills)

De tels scénarios semblent courants. Lorsque nous ÉCHANGEONS quelques ETHs d'un pool Uniswap, il est impossible de déterminer quels ETH nous avons reçus, étant donné les nombreux fournisseurs de liquidités à Uniswap. Cependant, la différence réside dans le processus. Avec Uniswap, l'échange de jetons nécessite un autre jeton de valeur équivalente, et les fonds ne peuvent pas être transférés de manière "privée". En revanche, un mélangeur nécessite simplement que le demandeur présente son reçu de dépôt.

Pour rendre les actions de dépôt et de retrait homogènes, le pool Tornado maintient la cohérence dans les montants de dépôt et de retrait. Par exemple, si un pool a 100 déposants et 100 retraits, même si les actions sont publiquement visibles, il semble n'y avoir aucun lien entre eux. Tout le monde dépose et retire le même montant, ce qui rend difficile de retracer le mouvement des fonds. De toute évidence, cela offre un avantage inné pour le blanchiment d'argent.

La question clé se pose : lors du retrait, comment prouver son dépôt antérieur ? L'adresse initiant le retrait n'est pas liée à une adresse de dépôt, alors comment vérifier le droit de retirer ? La méthode la plus directe serait que le retraitant révèle son historique de dépôt, mais cela exposerait son identité. C'est là que les preuves de connaissance nulle entrent en jeu.

Avec une preuve de connaissance nulle, un retraitant peut confirmer qu'il a un enregistrement de dépôt dans le contrat Tornado et que ce dépôt n'a pas encore été retiré. La beauté des preuves de connaissance nulle est qu'elles préservent la confidentialité. Le public sait seulement que le retraitant a effectivement fait un dépôt mais ne peut pas déterminer son identité spécifique.

Pour prouver que “J'ai déposé dans le pool Tornado” peut être traduit par “Mon historique de dépôts peut être trouvé dans le contrat Tornado.” Si Cn représente un historique de dépôts, alors étant donné l'ensemble des historiques de dépôts de Tornado comme {C1, C2,…C100…}, Bob doit prouver qu'il a utilisé sa clé privée pour générer un historique dans cet ensemble sans révéler lequel des Cn spécifiques il s'agit. Cela utilise les propriétés uniques de la Preuve de Merkle.

Tous les enregistrements de dépôt de Tornado sont agrégés dans un Arbre de Merkle construit on-chain. La majorité de ces feuilles (environ 2^20, plus de 1 million) restent vierges (avec une valeur initiale). Chaque nouveau dépôt met à jour une feuille d'engagement correspondante, puis la racine de l'arbre.

Par exemple, si le dépôt de Bob était le 10 000e dans l'histoire de Tornado, la valeur associée Cn serait la 10 000e feuille de l'arbre, c'est-à-dire C10000 = Cn. Le contrat calculerait alors automatiquement la nouvelle racine.

（Source de l'image : RareSkills）

La preuve de Merkle elle-même est concise et efficace. Pour prouver qu'une transaction TD existe dans un arbre de Merkle, il suffit de fournir la preuve de Merkle associée, qui reste compacte même si l'arbre de Merkle est vaste.

Pour valider qu'une transaction, disons H3, est effectivement incluse dans l'arbre de Merkle, il faut prouver que l'utilisation de H3 et d'autres données de l'arbre de Merkle peut générer la Racine. Ces données (y compris Td) constituent la Preuve de Merkle. Lorsque Bob souhaite effectuer un retrait, il doit vérifier deux choses :

·Cn est dans l'arbre de Merkle construit on-chain par Tornado, pour lequel il peut construire une preuve de Merkle contenant Cn；

·Cn est lié au bon de dépôt de Bob.

Explication de la logique commerciale de Tornado

Dans le code frontend de l'interface utilisateur de Tornado, de nombreuses fonctionnalités ont été pré-implementées. Lorsqu'un déposant ouvre la page web de Tornado Cash et clique sur le bouton de dépôt, le code frontend attaché génère localement deux nombres aléatoires, K et r. Il calcule ensuite la valeur de Cn=Hash(K, r), transmettant Cn (appelé engagement dans le schéma ci-dessous) au contrat Tornado pour être incorporé dans son Arbre de Merkle. En d'autres termes, K et r agissent comme des clés privées. Ils sont critiques, et il est conseillé aux utilisateurs de les conserver en toute sécurité, car ils seront à nouveau requis lors du processus de retrait.

Une “encryptedNote” est une fonctionnalité optionnelle qui permet aux utilisateurs de chiffrer les identifiants K et r avec une clé privée et de les stocker sur la chaîne pour éviter de les oublier.

Il est à noter que toutes les opérations ci-dessus ont lieu hors chaîne, ce qui signifie que ni le contrat Tornado ni aucun observateur externe ne sont conscients de K et r. Si K et r sont exposés, c'est semblable à se faire voler la clé privée de son portefeuille.

À la réception du dépôt d'un utilisateur et du calcul de Cn=Hash(K, r), le contrat Tornado place Cn au niveau de base de l'Arbre de Merkle, le transformant en un nouveau nœud feuille et mettant ensuite à jour la valeur de la racine. Cependant, il est important de comprendre que les feuilles de cet Arbre de Merkle ne sont pas consignées dans l'état du contrat mais sont uniquement enregistrées en tant que paramètres d'événement dans les blocs passés. Le contrat Tornado ne consigne que la racine de Merkle. Lors du retrait, les utilisateurs peuvent prouver, via une Preuve de Merkle, que l'enregistrement du dépôt correspond à la racine de Merkle actuelle, un concept quelque peu similaire aux retraits de pont inter-chaînes pour clients légers. Cette conception révèle l'ingéniosité de Tornado : pour économiser sur les coûts de gaz, l'arbre de Merkle complet n'est pas consigné dans l'état du contrat, seule sa racine l'est. Les feuilles de l'arbre sont simplement enregistrées dans les enregistrements de blocs historiques, un mécanisme quelque peu analogue au principe d'économie de gaz de Rollup (bien que les détails diffèrent).

Pendant le processus de retrait, le retraitant saisit les informations d'identification/les clés privées (nombres aléatoires K et r générés lors du dépôt) sur la page web frontend. Le code frontend de Tornado Cash utilise K et r, Cn=Hash(K, r), et la preuve de Merkle correspondant à Cn pour générer une preuve ZK, confirmant ainsi que Cn correspond à un enregistrement de dépôt sur l'arbre de Merkle et que K et r sont les informations d'identification valides pour Cn. Cette étape prouve essentiellement la connaissance des clés d'un enregistrement de dépôt sur l'arbre de Merkle. Lorsque la preuve ZK est soumise au contrat Tornado, les quatre paramètres sont dissimulés, garantissant que les tiers, y compris le contrat Tornado lui-même, restent inconscients, et ainsi protégeant la vie privée de l'utilisateur.

Un détail intéressant est que l'opération de dépôt utilise deux nombres aléatoires, K et r, pour générer Cn au lieu d'un seul car un seul nombre aléatoire pourrait ne pas être assez sécurisé et pourrait éventuellement être forcé de manière brutale.

Concernant le symbole "A" dans l'illustration, il représente l'adresse recevant le retrait et est fourni par le retraitant. Pendant ce temps, "nf" est un identifiant mis en place pour empêcher les attaques de rejeu, sa valeur étant déterminée comme nf=Hash(K), où K est l'un des deux nombres aléatoires (K et r) utilisés lors du dépôt pour générer Cn. Ainsi, chaque Cn a un nf correspondant, et les deux sont liés de manière unique.

Pourquoi la nécessité de prévenir les attaques de rejeu ? En raison des caractéristiques de conception du mélangeur, lors du retrait, il n'est pas clair quel dépôt dans l'arbre de Merkle correspond aux fonds retirés. Comme le lien entre le déposant et les montants retirés reste obscur, les utilisateurs malveillants pourraient en profiter et retirer à plusieurs reprises du mélangeur, vidant le pool de jetons.

Ici, l'identifiant nf fonctionne de manière similaire au compteur de transactions "nonce" inhérent à chaque adresse Ethereum, établi pour éviter les relectures de transactions. Lors d'une demande de retrait, les utilisateurs doivent soumettre un nf. Le système vérifie si ce nf a déjà été utilisé : s'il a été utilisé, le retrait est invalidé ; sinon, le retrait est effectué, et le nf est enregistré, garantissant que son utilisation ultérieure entraînerait une invalidation.

Certains pourraient se demander : Est-il possible de fabriquer un nf que le contrat n'a pas enregistré ? C'est improbable. Lors de la génération de la preuve de ZK, il est essentiel de s'assurer que nf=Hash(K), et le nombre aléatoire K est lié à l'enregistrement du dépôt Cn. Si quelqu'un crée arbitrairement un nf, il ne correspondra à aucun des dépôts enregistrés, rendant ainsi la génération d'une preuve de ZK valide impossible, bloquant par la suite le processus de retrait.

D'autres pourraient se demander : Y a-t-il un moyen de contourner l'utilisation de nf ? Étant donné que les retraits doivent soumettre une preuve ZK, qui atteste leur connexion à un Cn spécifique, ne suffirait-il pas de vérifier si une preuve ZK correspondante a déjà été enregistrée on-chain ? Cependant, les coûts associés à une telle approche sont exorbitants car le contrat Tornado Cash ne stocke pas en permanence les preuves ZK déjà soumises pour éviter le gaspillage de stockage. Comparer chaque nouvelle preuve ZK avec les preuves existantes pour garantir la cohérence est bien plus gourmand en ressources que de simplement enregistrer un identifiant compact comme nf.

Selon l'exemple de code de la fonction de retrait, les paramètres requis et la logique métier sont les suivants: les utilisateurs soumettent la preuve ZK, nf (NullifierHash) = Hash(K), et désignent une adresse de destinataire pour le retrait. La preuve ZK cache les valeurs de Cn, K et r, garantissant que le monde extérieur ne peut pas déterminer l'identité de l'utilisateur. En général, les destinataires spécifieront une adresse propre et nouvelle pour éviter de révéler des informations personnelles.

Cependant, un petit défi émerge : lorsque les utilisateurs effectuent un retrait, pour des raisons de non traçabilité, ils utilisent souvent des adresses fraîchement générées pour initier la transaction de retrait. À ces moments-là, ces nouvelles adresses manquent d'ETH pour couvrir les frais de gaz. Par conséquent, lors du retrait, l'adresse doit déclarer explicitement un relais pour couvrir les frais de gaz. Ensuite, le contrat de mixage déduit une partie du retrait de l'utilisateur pour compenser le relais.

En conclusion, Tornado Cash peut obscurcir le lien entre les déposants et les retireurs. Lorsqu’il y a une grande base d’utilisateurs, c’est comme si un criminel se fondait dans une foule animée, ce qui rendait difficile le suivi par les autorités. Le processus de retrait utilise ZK-SNARK, avec la partie « témoin » cachée contenant des informations cruciales sur le retrait. C’est sans doute la caractéristique la plus vitale de la table de mixage. À l’heure actuelle, Tornado est peut-être l’une des applications les plus intelligentes liées à ZK.

Avis de non-responsabilité：

1. Cet article est repris de [moyen]. Tous les droits d'auteur appartiennent à l'auteur original [Faust, web3 geek]. If there are objections to this reprint, please contact the Gate Learn team（gatelearn@gate.io) et ils s'en occuperont rapidement.
2. Avertissement de 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, la copie, la distribution ou le plagiat des articles traduits est interdit.