紹介：最近、Vitalikといくつかの学者が共同で新しい論文を発表し、Tornado Cashが反マネーロンダリングスキームを実装している方法について言及しています（基本的には引き出し側が自分の預入れ記録が汚れたお金を含まないセットに属していることを証明できるようにする）。しかし、その論文にはTornado Cashのビジネスロジックや原則の詳細な解釈が欠けており、一部の読者を困惑させています。

プライバシープロジェクトはTornadoに代表されるものであり、ZK-SNARKアルゴリズムのゼロ知識特性を実際に利用しています。一方、ZKとラベル付けされたほとんどのプロジェクトはZK-SNARKの簡潔さのみを利用しています。人々はしばしば有効性証明とZKの違いを混同し、TornadoはZKの応用を理解するための優れた例となっています。この記事の著者は、2022年にWeb3Caff ResearchのためにTornadoの原則について執筆し、今日はその記事からいくつかのセクションを選択し、本稿に整理してTornado Cashを体系的に理解するためのものです。

元の記事リンク: https://research.web3caff.com/zh/archives/2663?ref=157

"Tornado"の原則

Tornado Cashは、2019年にリリースされた古いバージョンと2021年末にリリースされた新しいベータバージョンを持つ、ゼロ知識証明に基づいたコインミキシングプロトコルを利用しています。古いバージョンのTornadoは、オンチェーン契約がオープンソースであり、どのマルチシグネチャメカニズムにも制御されておらず、フロントエンドコードもオープンソースでIPFSネットワークでバックアップされています。古いバージョンのTornadoの構造がよりシンプルで理解しやすいため、この記事ではその説明に焦点を当てています。Tornadoの主なアイデアは、多数の入金と出金アクションを混ぜ合わせることです。Tornadoにトークンを預け入れた後、預金者はZKプルーフを提示して預金を行ったことを証明し、その後新しいアドレスに引き出して、預入と引き出しのアドレス間のリンクを切断します。

さらに具体的には、トルネードは多くの人々によって預けられたコインで満たされたガラス箱のように機能します。コインを預けた人が誰であるかはわかりますが、コインが非常に均質化されているため、誰かがコインを引き出すと、どのコインが誰によって預けられたものかを遡るのは難しいです。

(出典: rareskills)このシナリオはある程度一般的です。たとえば、UniswapプールでETHをスワップするとき、Uniswapに多くの人が流動性を提供しているため、私たちはどのETHを取得するかを知ることはできません。しかし、異なるのは、Uniswapでトークンをスワップするたびに、同等のコストとして他のトークンを使用する必要があり、他の人に資金を「プライベートに」送金することはできないことです。一方、ミキサーを使用すると、引き出すために預金証明を示すだけで済みます。預金と引き出しのアクションを均質に見せるために、Tornadoプールに入金するたび、それから引き出すたびに、金額は一定に保たれます。たとえば、プールに100人の預金者と100人の引き出し者がいる場合、見えるかもしれませんが、それらはリンクされていないように見え、それぞれが預金および引き出しした金額は同じです。

これにより、資金の送金の追跡が曖昧になり、取引の匿名化に自然な利便性が提供されます。重要な問題は、引き出し者がどのようにして入金を証明するのかということです。

出金を行うアドレスは、いかなる入金アドレスにもリンクされていないため、出金の資格をどのように決定すればよいのでしょうか？ 最も直接的な方法は、出金者が自分の入金記録がどれかを明らかにすることですが、これにより直接的に自分の身元が明らかになります。ここでゼロ知識証明が重要になります。Tornado契約にまだ引き出されていない入金記録を持っていることを示すZK Proofを提示することで、出金者は正常に出金を開始することができます。ゼロ知識証明は、本質的にプライバシーを保護し、その人が実際にファンドプールに入金したことを明らかにし、どの預金者に対応するかを開示しません。

「「ハリケーン契約書」に入金記録が見つかることを証明するためには、「私の入金記録はハリケーン契約書にあります」と翻訳できます。入金記録を表すためにCnを使用すると、問題は次のようになります。ハリケーンの入金記録セットが{C1、C2、…C100…}であるとき、引き出し人のボブは、特定のCnが何であるかを明らかにせずに、そのCnを生成するために鍵を使用したことを証明します。これはMerkle Proofの特別な性質に関わります。ハリケーンのすべての入金記録は、オンチェーン上に構築されたMerkle Treeに組み込まれており、これらの記録がその最下位の葉ノードとなっています。葉の総数はおよそ2^20＞100万であり、そのうちのほとんどは空白の状態（初期値が割り当てられた状態）です。新しい入金が発生するたびに、契約はそのユニークな値、Commitment、を葉に記録し、その後Merkle Treeのルートを更新します。

たとえば、Bobの預入れがTornadoの歴史で10,000番目だった場合、この預入れに関連する特性値Cnは、Merkle Treeの10,000番目の葉ノードに入力されます。すなわち、C10000 = Cnとなります。その後、契約は自動的に新しいRootを計算して更新します。計算リソースを節約するために、Tornado契約は、以下の図におけるFs1、Fs2、およびFs0のような以前に変更されたノードのバッチからデータをキャッシュします。

(出典:RareSkills)

マークルプルーフは、その性質上、検索/トレースプロセスで木構造の単純さを活用し、簡潔で軽量です。トランザクションTDがマークルツリーに存在することを外部で証明するには、対応するルートにマークルプルーフを提供するだけで十分です。マークルツリーが特に大きい場合、2^20乗のボトムレベルの葉（つまり、100万の入金記録）がある場合、マークルプルーフには21ノードの値だけを含めれば十分です。非常に短いです。

トランザクションH3が実際にMerkle Tree内に含まれていることを証明するには、H3およびMerkle Tree上の他のデータの一部を使用してRootを生成でき、Rootを生成するために必要なデータ（Tdを含む）がMerkle Proofを構成することを示す必要があります。 Bobが引き出しを行うとき、彼はTornadoの台帳に記録された預入れハッシュCnに対応する証明が必要です。 言い換えれば、次の2つのことを証明する必要があります。 CnがオンチェーンのTornadoの架空のMerkle Tree内に存在し、特にCnを含むMerkle Proofを構築することにより；CnがBobの預入れ証明書に関連付けられていること

トルネードのビジネスロジックの説明

Tornadoユーザーインターフェースのフロントエンドコードでは、多くの機能が事前に実装されています。預入者がTornado Cashウェブページを開き、預入ボタンをクリックすると、それに付随するフロントエンドコードは2つのランダムな数値Kとrをローカルで生成します。その後、Cn=Hash(K, r)の値を計算し、この値（以下の図でコミットメントと呼ばれます）をTornado契約に渡します。Tornado契約はこれを後者によって記録されたMerkle Treeに挿入します。基本的に、Kとrはプライベートキーとして機能します。これらは重要であり、システムはユーザーにこれらを安全に保存するよう促します。Kとrは引き出し時に再度必要とされます。

(暗号化されたノートのオプションにより、ユーザーは秘密鍵を使って資格情報Kとrを暗号化し、ブロックチェーンに保存して忘れるのを防ぎます) 重要なのは、これらのすべての操作がオフチェーンで行われるということで、Tornado契約および外部の観察者はKとrを知りません。 Kとrが漏洩した場合、それはウォレットの秘密鍵が盗まれたのと同じです。

ユーザーからの入金を受け取り、Cn=Hash(K, r)の提出後、トルネード契約は新しい葉ノードとしてCnをMerkle Treeの最下層に記録し、またRoot値を更新します。したがって、Cnはユーザーの入金アクションに直接リンクされており、外部の人々は各Cnに対応するユーザーを知ることができ、誰がトークンをミキサーに入金したか、および各預金者の預金記録Cnを知ることができます。

出金プロセス中に、出金者はフロントエンドのWebページにクレデンシャル/秘密鍵(入金中に生成された乱数Kとr)を入力します。Tornado Cashフロントエンドコードのプログラムは、Kとr、Cn=Hash(K, r)、およびCnに対応するマークルプルーフを入力パラメータとして使用して、ZKプルーフを生成します。これは、Cnが堆積物レコードとしてマークルツリーに存在し、KとrがCnに対応するクレデンシャルであることを証明しています。このステップは、基本的に証明します:私はマークルツリーの預金記録に対応する鍵を知っています。ZKプルーフがトルネードコントラクトに提出されると、これら4つのパラメータが隠蔽され、プライバシーが保護されます。ZK Proofの生成には、引き出し時にTornadoコントラクトに記録されたマークルルート、カスタム受信者アドレスA、リプレイ攻撃を防ぐための識別子nfなどの追加パラメータが含まれます。これら3つのパラメータはブロックチェーンに公開されており、プライバシーを損なうことはありません。

注意すべき詳細は、単一のランダムな数値ではなく、2つのランダムな数値Kとrを使用してCnを生成することで、衝突に対する増加したセキュリティを提供しています。 Aは引き出し受取人アドレスを表し、引き出し者が選択します。再生攻撃を防止するために設計された識別子nfは、nf=Hash(K)として計算され、KはCnを生成するために預金段階で使用される2つのランダムな数値の1つです。これにより、nfがCnに直接リンクし、各Cnとそれに対応するnfの間に一対一の相関が確立されます。再生攻撃を防止する目的は、ミキサーの設計機能に起因しています。この機能により、引き出し金額と特定のMerkleツリーの葉（Cn）との関連性が不明のままになり、資金プールが枯渇するまで繰り返し引き出しを悪用する可能性があります。

nf識別子は、各Ethereumアドレスに関連付けられたnonceと同様に機能し、トランザクションのリプレイを防ぎます。引き出しが発生すると、送信されたnfが以前に使用されていないことを確認するチェックが行われます。未使用の場合、引き出しは有効となり、nfが記録されます。記録された入金Cnに関連付けられていないnfを生成しようとする試みは、有効なZKプルーフを生成できず、引き出しが失敗します。

もし誰かが記録されていない非代替性（nf）契約を無作為に生成した場合、それは機能しますか？もちろん、そうではありません。引き出し側がZero-Knowledge Proof（ZK Proof）を生成する際には、nfがHash（K）に等しいことを確認する必要があります。ここで、ランダムな数値Kは預入れ記録Cnに関連付けられています。つまり、nfは記録された預入れCnにリンクされています。誰かがnfを恣意的に作成した場合、そのnfはいかなる預入れ記録にも一致せず、有効なZK Proofを生成することができません。その結果、引き出しプロセスは正常に完了せず、引き出し操作は失敗します。一部の人はこう尋ねるかもしれません。nfなしで進めることは可能でしょうか？引き出し側は引き出し時に特定のCnとの関連を証明するためにZK Proofを提出する必要がありますが、なぜ各引き出しが発生するたびにブロックチェーンに対応するZK Proofが提出されたかどうかを確認しないのでしょうか？しかし、この方法は非常にコストがかかります。Tornado Cash契約は過去のZK Proofを永久に保存しないため、著しいストレージスペースの無駄遣いが発生します。ブロックチェーンに提出された新しいZK Proofを既存のProofと比較することは、nfのような小さな識別子を設定して永久に保存するよりも効率的ではありません。

出金機能のコード例によると、必要なパラメーターとビジネスロジックは次のとおりです：ユーザーはZKプルーフとnf（NullifierHash）= Hash（K）を提出し、出金のための受取人アドレスを指定し、ZKプルーフはCn、K、およびrの値を隠し、外部の者がユーザーの身元を特定することを不可能にします。 受取人はしばしば個人情報を明らかにしない新しいクリーンなアドレスを使用します。

しかし、小さな問題があります。ユーザーが追跡不可能にするために引き出しを行うとき、しばしば新しく作成したアドレスから引き出しトランザクションを開始します。このとき、新しいアドレスにはガス料金を支払うETHが不足しています。したがって、引き出しを開始する際に、引き出しアドレスはガス料金を代わりに支払うリレーヤーを明示的に宣言する必要があります。その後、ミキサー契約はユーザーの引き出しから一部を差し引いて、リレーヤーに補償します。

要約すると、Tornado Cashは引き出し者と預け入れ者の間の接続を不明瞭にすることができます。大規模なユーザーベースが存在する状況では、それは犯罪者が混雑したエリアで群衆に紛れ込むようなものであり、警察が追跡するのが困難になります。引き出しプロセスにはZK-SNARKsの使用が含まれ、隠れた証人部分には引き出し者に関する重要な情報が含まれており、これは全体的なミキサーの重要な側面です。現時点では、TornadoはZKに関連する最も独創的なアプリケーションレイヤープロジェクトの1つであるようです。

免責事項：

1. この記事は[から転載されましたギークWeb3], すべての著作権は元の著者に帰属します [Faust、geek web3]. If there are objections to this reprint, please contact the Gate Learnチームが promptly を処理します。
2. 責任の免責事項：この記事で表現されている意見は、著者個人のものであり、投資アドバイスを構成するものではありません。
3. 記事の翻訳は、Gate Learnチームによって行われます。特に記載がない限り、翻訳された記事のコピー、配布、または盗用は禁止されています。