開発者 ameen.eth は、「無罪証明」の概念と Tornado Cash を組み合わせて、「プライバシーは犯罪と同等ではない」という別の方向性を提供します。
著者: アルバート リン
TornadoCash は、暗号通貨の世界でよく知られた匿名トランザクション サービスです。 TornadoCash は、ZKP (Zero-Knowledge Proof) テクノロジーを使用して資金源を隠します。米政府は、こうした仕組みが違法な資金移動活動を促進したと主張し、最終的に2022年8月に米財務省から制裁を受け、棚から撤去することを余儀なくされた。多くの場合、プライバシー保護とマネーロンダリングは常に密接に関係しているようです。犯罪者はプライバシーを追求する一方で、これらのプライバシー機能を違法な資金洗浄に使用することがよくあります。マネーロンダリングを効果的に抑制しながら、人々のプライバシーを確保できる方法は見つかるでしょうか? TornadoCash の初期開発者である ameen.eth による Privacy-Pools が方向性を与えるかもしれません。 （上場廃止部分はフロントエンドWebサイトとGitHubリポジトリのみが影響を受け、コントラクト部分はブロックチェーン上にあるため影響を受けません。最終的には電子フロンティア財団の尽力によりGitHubがリポジトリを復旧しました。詳細はこちらをご覧ください）ここを参照してください）
Privacy-Pools を導入する前に、TornadoCash に関連する設計原則を理解する必要があります。詳しい紹介については、以前の記事「TornadoCash の解説: 友人にその機能を説明するための初心者ガイド」を参照してください。ここでは、TornadoCash の設計原則を簡単に説明します。
TornadoCash はレシート (コミットメント) を使用してアクセスを制御します。レシートはシークレット (秘密の値) とヌルファイア (ログアウト コード) をハッシュすることによって生成され、各レシートは 1 回だけ引き出すことができます。マークル ツリー (ハッシュ ツリー) を使用して入金情報を記録し、レシートをリーフ ノードとして使用し、マークル ルート (ハッシュ ツリーのルート) を計算します。ユーザーは、リーフからルートまでのデータを提供するだけで、そのデータがマークル ツリーのリーフの 1 つであるかどうかを証明し、以前に TornadoCash に入金資金があったことを間接的に証明できます。 Zero-Knowledge Proof を使用して入金元を隠し、Nullifier を使用して二重引き出し攻撃を防ぎます。
TornadoCash のレシートには 2 つの意味があります
*送金者が以前に資金を入金したことを証明するもの
TornadoCash の設計原則によれば、受け取った資金が以前の預金から来ている必要があることだけがわかりますが、どの預金から来たのかは不明です。これが犯罪者が違法なマネーロンダリング活動に TornadoCash を使用する主な目的であり、米国政府が TornadoCash を規制する理由でもあります。受け取った資金が拒否リストにある預金からのものではないことを証明するための別の証明 (ZKP) を提案できれば、それが支払いが犯罪者からのものではないことを証明できるかどうかにかかわらず、これは「無実の証明」です。イノセンス」）のコアコンセプト。
「無実の証明」の概念は 2 つの方向に分類できます
これらの方法はどちらも、引き出し資金が拒否リストにある預金からのものではないことを証明できます。以下の図のアプローチは、拒否リストを使用して、受け取った資金が拒否リストの預金 (赤) からのものではないことを証明することです。
ソース：
Privacy-Pools は、TornadoCash に「無罪証明」の概念を追加します。 TorandoCash の領収書の本来の意味に加えて、Privacy-Pools の支払い領収書には「受け取った資金が許可リストにある預金からのものであることを証明する」という 3 番目の意味があります。
プライバシー プールの受領書は次のことを意味します。
ここでは、Allow Merkle Tree を使用して、Privacy-Pools がこのシステムで「Proof-of-Innocence」をどのように使用するかを説明します (Allow Merkle Tree は、許可リストを使用する概念です)。まず、Allow Merkle Tree にはいくつかの特徴があります。
許可マークル ツリー リーフ データは、次の 2 つのカテゴリに分類できます。
以下の図に示すように、インデックス 0 と 1 のポジションは両方とも Deposit Merkle ツリー内の法定資金であり、Allow Merkle Tree リーフの対応するポジションも許可されています。
今日、犯罪者がマネー ロンダリング活動を実行しようとしていると仮定します。犯罪者は攻撃後に得た違法資金をプライバシー プールに預けます。その預け先は Deposit Merkle Tree インデックス: 2 です。これが違法な資金であることがわかっているため、対応する許可マークル ツリー インデックス: 2 の位置でブロックされるように更新します。
今日、米国政府の許可リストに入金しているユーザーが資金を引き出したいと仮定すると、「その入金が Dposit Merkle Tree にあることの証明」と「米国の許可リストにあるものが許可されていることの証明」を提供する必要があります。米国の許可リストに対応する証明には、Allow Merkle Root (ユーザーによって提供される、コード内の subetRoot) と途中で渡されるノード値が含まれます。 Privacy-Pools が ZKP ステージを検証するとき、許可されているリーフ値 (実際のコードでは keccak256(allowed)) と指定されたノード値を使用してマークル ルートを構築します。このマークル ルートが、ユーザーが指定した許可マークル ルートと同じであることを確認します。同一の代表者の認証に合格した場合、出金資金は米国政府の許可リストに存在する預金からのものであることを意味します。
現在、米国政府の許可リストに載っていないユーザーが資金を引き出したいと考えており、対応する入金場所は米国政府の許可リストでブロックされているとマークされています。これにより、ユーザーは資金を引き出すために米国政府の許可リストの許可マークル ルートを使用できなくなります。これは、対応する証明が生成できず、検証が失敗するためです (プライバシー プールがリーフに許可の値を使用するため)。計算され、米国政府の許可リストは次のようになります。その場所はブロックされているとしてマークされているため、同じマークル ルートを計算することはできません)。
このような設計では、ユーザーは資金を引き出すために別の許可マークル ルートを提供する必要があります (他の許可マークル ツリーは、同じ許可マークル ルートが検証に合格することを計算するために、入金場所を許可済みとしてマークする必要があります)。この他の許可マークル ツリーは、他の政府や機関によって維持されている場合もあれば、このユーザー自身によって生成されている場合もあります。現在、米国政府は、追跡の目的を達成するために、出金時に使用される許可マークルルートを使用して、ユーザーの資金が米国政府の法律および規制に準拠しているかどうかを判断できます。ユーザーが自分で生成した許可マークル ツリーを使用している場合、または信頼性の低い許可マークル ツリーを使用している場合、基本的に出金資金は問題のある預金から出ている可能性が非常に高くなります (信頼できるすべてのサードパーティの許可マークル ツリーは、その預金場所をブロック済みとしてマークします)。
＃＃ よくある質問
**Q:Allowroot が引き出し者によって提供されている場合、リーフが許可リスト内の預金であることを証明するために偽の Allow Merkle Root を偽造することは可能ですか。つまり、お金はまだ持ち出せるということですか? **
A: 答えは「はい」です。確かにお金を奪うことは可能です。著者は、このような仕組みは犯罪者がお金を持ち出すことを禁止するものではないが、たとえ持ち出すことができたとしても、その資金が拒否リストに載っている資金であることが知られてしまうと具体的に指摘した。撤退者が説得力のない許可マークル ルートを提供した場合、それは基本的に拒否リストから撤退したと見なされます。これを許可する理由は、このサービスの分散性を維持するためであると著者は推測しています。これは、各許可マークル ツリーが各リーフのステータスを更新するために特定の権限管理を必要とするためです。特定の許可ツリーのルートが必須である場合、誰かが資金の引き出しを制御する一定の権限を持っていることを意味し、これは分散化の精神に反します。
**Q: 取引が拒否リストのファンドからのものかどうかは誰が判断するのでしょうか? **
A: 私が見た部分は特に言及されておらず、この部分は各監督官庁が行うべきものであると理解しています。今日、米国政府がプライバシー プールのダーティ マネーをチェックしたいと仮定すると、各トランザクションの許可マークル ルートをチェックすることで、彼がダーティ マネーであるかどうかを確認できます。どのような許可マークルルートが許可されるかについては、各規制当局が自ら判断することになります。
メイン コードと作成者自身のコメントがここに添付されており、コードを通じて誰もがメイン ロジックを理解できるようにしたいと考えています。
// 回路/withdraw_from_subset.circom
template WithdrawFromSubset(levels, ExpectValue) {
// 公共
信号入力ルート。
信号入力サブセットルート;
信号入力無効化器。
信号入力アセットメタデータ; // abi.encode(トークン, 金額).snarkHash();
信号入力drawMetadata; // abi.encode(受信者、返金、中継者、料金).snarkHash();
// プライベート
信号入力の秘密。
信号入力パス。 // データが左の葉を表すか右の葉を表すかを示します。
信号入力メインプルーフ [levels] ; // デポジットルートに必要なデータを構築します。
信号入力サブセット証明 [levels] ; // root を許可するために必要なデータを構築します。
// 無効化子とコミットメントを計算します。
コンポーネントハッシュ = CommitmentNullifierHasher();
hasher.secret <== シークレット;
ハッシュ.パス <== パス;
hasher.assetMetadata <==assetMetadata;
nullifier === hasher.nullifier;
// ExpectValue: keccak256("allowed") % p
コンポーネント doubleTree = DoubleMerkleProof(レベル、期待値);
doubleTree.leaf <== hasher.commitment;
// パスをビットに変換して、それが左の葉であるか右の葉であるかを指定します。
// デポジット ツリーと許可ツリーが同じパスを共有していることがわかります。
doubleTree.path <== パス;
for ( i = 0; i < レベル; i++) {
doubleTree.mainProof [i] <== メイン証明 [i] ;
doubleTree.subsetProof [i] <== サブセット証明 [i] ;
}
ルート === doubleTree.root; // デポジットルートを確認します。
サブセットルート === doubleTree.subsetRoot; // 許可ルートを確認します。
シグナルwithdrawMetadataSquare;
drawMetadataSquare <==drawMetadata *drawMetadata;
開発者 ameen.eth は、「無罪証明」の概念と TornadoCash を組み合わせて、「プライバシーは犯罪と同等ではない」という別の方向性を提供します。著者は、別の ZKP を使用して別の事実を証明することに興味を持っています。これは、ZKP の追加に似ています。この使用方法は、大規模で複雑な ZKP を構築するよりも簡単で効率的です。 「Allow Merkle Tree」の選択については、将来的にはより公平な単位で構築され、他の人にとってより説得力のあるものになると感じています。
最後に、記事のレビューに協力し、貴重な意見を提供してくれた Chih-Cheng Liang と Ping Chen に感謝します。
参考：
ステルスアドレス
Tornado Cash インスタンスの分析
ZKP とスマート コントラクトの開発の概要
[ZKP読書クラブ] TornadoCash
トルネード キャッシュ — 仕組み | DeFi + ゼロ知識証明
TornadoCash の技術詳細についての深い理解
0xhh 新機能とその原理を紹介するスレッド
デモビデオ
Tornadov2 を改善する方法についての Vitalik の講演
プライバシー プール v0tweet
TornadoCash に基づいて構築された Proof of Innocence の紹介
254k 人気度
42k 人気度
35k 人気度
38k 人気度
Tornado Cash V2の設計原理を詳しく説明
著者: アルバート リン
序文
TornadoCash は、暗号通貨の世界でよく知られた匿名トランザクション サービスです。 TornadoCash は、ZKP (Zero-Knowledge Proof) テクノロジーを使用して資金源を隠します。米政府は、こうした仕組みが違法な資金移動活動を促進したと主張し、最終的に2022年8月に米財務省から制裁を受け、棚から撤去することを余儀なくされた。多くの場合、プライバシー保護とマネーロンダリングは常に密接に関係しているようです。犯罪者はプライバシーを追求する一方で、これらのプライバシー機能を違法な資金洗浄に使用することがよくあります。マネーロンダリングを効果的に抑制しながら、人々のプライバシーを確保できる方法は見つかるでしょうか? TornadoCash の初期開発者である ameen.eth による Privacy-Pools が方向性を与えるかもしれません。 （上場廃止部分はフロントエンドWebサイトとGitHubリポジトリのみが影響を受け、コントラクト部分はブロックチェーン上にあるため影響を受けません。最終的には電子フロンティア財団の尽力によりGitHubがリポジトリを復旧しました。詳細はこちらをご覧ください）ここを参照してください）
はじめに TornadoCash の原則
Privacy-Pools を導入する前に、TornadoCash に関連する設計原則を理解する必要があります。詳しい紹介については、以前の記事「TornadoCash の解説: 友人にその機能を説明するための初心者ガイド」を参照してください。ここでは、TornadoCash の設計原則を簡単に説明します。
TornadoCash はレシート (コミットメント) を使用してアクセスを制御します。レシートはシークレット (秘密の値) とヌルファイア (ログアウト コード) をハッシュすることによって生成され、各レシートは 1 回だけ引き出すことができます。マークル ツリー (ハッシュ ツリー) を使用して入金情報を記録し、レシートをリーフ ノードとして使用し、マークル ルート (ハッシュ ツリーのルート) を計算します。ユーザーは、リーフからルートまでのデータを提供するだけで、そのデータがマークル ツリーのリーフの 1 つであるかどうかを証明し、以前に TornadoCash に入金資金があったことを間接的に証明できます。 Zero-Knowledge Proof を使用して入金元を隠し、Nullifier を使用して二重引き出し攻撃を防ぎます。
TornadoCash のレシートには 2 つの意味があります
*送金者が以前に資金を入金したことを証明するもの
「無実の証明」
TornadoCash の設計原則によれば、受け取った資金が以前の預金から来ている必要があることだけがわかりますが、どの預金から来たのかは不明です。これが犯罪者が違法なマネーロンダリング活動に TornadoCash を使用する主な目的であり、米国政府が TornadoCash を規制する理由でもあります。受け取った資金が拒否リストにある預金からのものではないことを証明するための別の証明 (ZKP) を提案できれば、それが支払いが犯罪者からのものではないことを証明できるかどうかにかかわらず、これは「無実の証明」です。イノセンス」）のコアコンセプト。
「無実の証明」の概念は 2 つの方向に分類できます
これらの方法はどちらも、引き出し資金が拒否リストにある預金からのものではないことを証明できます。以下の図のアプローチは、拒否リストを使用して、受け取った資金が拒否リストの預金 (赤) からのものではないことを証明することです。
プライバシー プールの設計原則
Privacy-Pools は、TornadoCash に「無罪証明」の概念を追加します。 TorandoCash の領収書の本来の意味に加えて、Privacy-Pools の支払い領収書には「受け取った資金が許可リストにある預金からのものであることを証明する」という 3 番目の意味があります。
プライバシー プールの受領書は次のことを意味します。
*送金者が以前に資金を入金したことを証明するもの
ここでは、Allow Merkle Tree を使用して、Privacy-Pools がこのシステムで「Proof-of-Innocence」をどのように使用するかを説明します (Allow Merkle Tree は、許可リストを使用する概念です)。まず、Allow Merkle Tree にはいくつかの特徴があります。
許可マークル ツリー リーフ データは、次の 2 つのカテゴリに分類できます。
以下の図に示すように、インデックス 0 と 1 のポジションは両方とも Deposit Merkle ツリー内の法定資金であり、Allow Merkle Tree リーフの対応するポジションも許可されています。
今日、犯罪者がマネー ロンダリング活動を実行しようとしていると仮定します。犯罪者は攻撃後に得た違法資金をプライバシー プールに預けます。その預け先は Deposit Merkle Tree インデックス: 2 です。これが違法な資金であることがわかっているため、対応する許可マークル ツリー インデックス: 2 の位置でブロックされるように更新します。
権限リストの収集状況
今日、米国政府の許可リストに入金しているユーザーが資金を引き出したいと仮定すると、「その入金が Dposit Merkle Tree にあることの証明」と「米国の許可リストにあるものが許可されていることの証明」を提供する必要があります。米国の許可リストに対応する証明には、Allow Merkle Root (ユーザーによって提供される、コード内の subetRoot) と途中で渡されるノード値が含まれます。 Privacy-Pools が ZKP ステージを検証するとき、許可されているリーフ値 (実際のコードでは keccak256(allowed)) と指定されたノード値を使用してマークル ルートを構築します。このマークル ルートが、ユーザーが指定した許可マークル ルートと同じであることを確認します。同一の代表者の認証に合格した場合、出金資金は米国政府の許可リストに存在する預金からのものであることを意味します。
拒否リストの収集状況
現在、米国政府の許可リストに載っていないユーザーが資金を引き出したいと考えており、対応する入金場所は米国政府の許可リストでブロックされているとマークされています。これにより、ユーザーは資金を引き出すために米国政府の許可リストの許可マークル ルートを使用できなくなります。これは、対応する証明が生成できず、検証が失敗するためです (プライバシー プールがリーフに許可の値を使用するため)。計算され、米国政府の許可リストは次のようになります。その場所はブロックされているとしてマークされているため、同じマークル ルートを計算することはできません)。
このような設計では、ユーザーは資金を引き出すために別の許可マークル ルートを提供する必要があります (他の許可マークル ツリーは、同じ許可マークル ルートが検証に合格することを計算するために、入金場所を許可済みとしてマークする必要があります)。この他の許可マークル ツリーは、他の政府や機関によって維持されている場合もあれば、このユーザー自身によって生成されている場合もあります。現在、米国政府は、追跡の目的を達成するために、出金時に使用される許可マークルルートを使用して、ユーザーの資金が米国政府の法律および規制に準拠しているかどうかを判断できます。ユーザーが自分で生成した許可マークル ツリーを使用している場合、または信頼性の低い許可マークル ツリーを使用している場合、基本的に出金資金は問題のある預金から出ている可能性が非常に高くなります (信頼できるすべてのサードパーティの許可マークル ツリーは、その預金場所をブロック済みとしてマークします)。
＃＃ よくある質問
**Q:Allowroot が引き出し者によって提供されている場合、リーフが許可リスト内の預金であることを証明するために偽の Allow Merkle Root を偽造することは可能ですか。つまり、お金はまだ持ち出せるということですか? **
A: 答えは「はい」です。確かにお金を奪うことは可能です。著者は、このような仕組みは犯罪者がお金を持ち出すことを禁止するものではないが、たとえ持ち出すことができたとしても、その資金が拒否リストに載っている資金であることが知られてしまうと具体的に指摘した。撤退者が説得力のない許可マークル ルートを提供した場合、それは基本的に拒否リストから撤退したと見なされます。これを許可する理由は、このサービスの分散性を維持するためであると著者は推測しています。これは、各許可マークル ツリーが各リーフのステータスを更新するために特定の権限管理を必要とするためです。特定の許可ツリーのルートが必須である場合、誰かが資金の引き出しを制御する一定の権限を持っていることを意味し、これは分散化の精神に反します。
**Q: 取引が拒否リストのファンドからのものかどうかは誰が判断するのでしょうか? **
A: 私が見た部分は特に言及されておらず、この部分は各監督官庁が行うべきものであると理解しています。今日、米国政府がプライバシー プールのダーティ マネーをチェックしたいと仮定すると、各トランザクションの許可マークル ルートをチェックすることで、彼がダーティ マネーであるかどうかを確認できます。どのような許可マークルルートが許可されるかについては、各規制当局が自ら判断することになります。
プライバシー プール コード
メイン コードと作成者自身のコメントがここに添付されており、コードを通じて誰もがメイン ロジックを理解できるようにしたいと考えています。
// 回路/withdraw_from_subset.circom
template WithdrawFromSubset(levels, ExpectValue) {
// 公共
信号入力ルート。
信号入力サブセットルート;
信号入力無効化器。
信号入力アセットメタデータ; // abi.encode(トークン, 金額).snarkHash();
信号入力drawMetadata; // abi.encode(受信者、返金、中継者、料金).snarkHash();
// プライベート
信号入力の秘密。
信号入力パス。 // データが左の葉を表すか右の葉を表すかを示します。
信号入力メインプルーフ [levels] ; // デポジットルートに必要なデータを構築します。
信号入力サブセット証明 [levels] ; // root を許可するために必要なデータを構築します。
// 無効化子とコミットメントを計算します。
コンポーネントハッシュ = CommitmentNullifierHasher();
hasher.secret <== シークレット;
ハッシュ.パス <== パス;
hasher.assetMetadata <==assetMetadata;
nullifier === hasher.nullifier;
// ExpectValue: keccak256("allowed") % p
コンポーネント doubleTree = DoubleMerkleProof(レベル、期待値);
doubleTree.leaf <== hasher.commitment;
// パスをビットに変換して、それが左の葉であるか右の葉であるかを指定します。
// デポジット ツリーと許可ツリーが同じパスを共有していることがわかります。
doubleTree.path <== パス;
for ( i = 0; i < レベル; i++) {
doubleTree.mainProof [i] <== メイン証明 [i] ;
doubleTree.subsetProof [i] <== サブセット証明 [i] ;
}
ルート === doubleTree.root; // デポジットルートを確認します。
サブセットルート === doubleTree.subsetRoot; // 許可ルートを確認します。
シグナルwithdrawMetadataSquare;
drawMetadataSquare <==drawMetadata *drawMetadata;
}
TLDR
開発者 ameen.eth は、「無罪証明」の概念と TornadoCash を組み合わせて、「プライバシーは犯罪と同等ではない」という別の方向性を提供します。著者は、別の ZKP を使用して別の事実を証明することに興味を持っています。これは、ZKP の追加に似ています。この使用方法は、大規模で複雑な ZKP を構築するよりも簡単で効率的です。 「Allow Merkle Tree」の選択については、将来的にはより公平な単位で構築され、他の人にとってより説得力のあるものになると感じています。
最後に、記事のレビューに協力し、貴重な意見を提供してくれた Chih-Cheng Liang と Ping Chen に感謝します。