論文が「プライバシー保護」と主張していても、漏洩面の見落としは頻繁にある。
correlated-output-dp-darkpool-2023 はその典型例 — 「入力は秘匿したのに出力の相関で情報が漏れる」。
システムを評価する際は「どのフェーズで、誰に対して、何が見えるか」を構造的に整理する必要がある。
クリックで各フェーズの漏洩リスク詳細を表示：
高リスク：注文をネットワークに送信する際、IPアドレス・タイムスタンプ・トランザクション形式がオペレーターまたはネットワーク監視者に漏洩しうる。
中リスク：コミットメントのサイズ・ガス消費量からシステムの登録者数や注文の種別が推測可能。
低リスク：適切に設計されたシステムでは、注文内容（価格・量・方向）はオンチェーン観察者に対して秘匿される。
高リスク：IoI（Indication of Interest）モードを使うシステムでは、取引方向（買い/売り）が相手に通知される。これは Direction Leakage の最も直接的な形。
中リスク：バッチ型システムでは待機時間の分布から注文数・更新頻度が統計的に推測可能。
低リスク：バッチ終了まで何も公開しない設計（FairTraDEX型）では、この時点での漏洩はほぼゼロ。
高リスク：出力相関リーク。「注文AとBが同時に消えた＝マッチした」ことから価格・量の範囲が逆算できる（全システムに潜在する問題）。
中リスク：Relayerはマッチング候補の存在を知る。どの注文がどの注文と競合しているかが分かれば大きな情報となる。
低リスク：MPC内で完結するシステム（Renegade等）では、マッチング計算自体は外部に漏れない。ただしrelayerへの信頼問題は残る。
中リスク：チェーン上の取引が「何かが起きた」ことを示す。ZKP証明のサイズ・ガス消費・タイムスタンプから取引の種類が類推されうる。
中リスク：AMMプール型では reserve の変化量から「大きなスワップがあった」ことは明らか。
高リスク（一部システム）：Indifferential Privacy 方式では、完全マッチした注文の真の量 x が開示される設計。
中リスク：Nullifier のチェーン上の出現タイミングから取引パターンが推測可能。定期的な取引者は識別されうる。
中リスク：長期的な参加パターン（バッチへの出入り頻度）から大口トレーダーが統計的に特定される可能性。
低リスク：適切に設計されたシステムでは、ウォレットの総資産は最も保護される情報。
「秘匿が難しい順」に上から並べた情報階層。上位ほど暗号技術的に守りにくく、実装上の見落としが発生しやすい。
設計: MPC (2-party garbled circuit) + Collaborative ZK-SNARK
デプロイ: Arbitrum One mainnet（2024年）
モデル: オーダーブック型ダークプール。ユーザー同士がMPCで直接マッチング計算を行う。
| フェーズ | 公開される情報 | 漏洩リスク | リスク度 |
|---|---|---|---|
| Phase 1: 注文提出 | ウォレットコミットメント C(W)（内容非公開） | コミットメントの更新頻度から「注文変更の頻度」が推測可能。頻繁な更新 = アクティブなトレーダー。 | 低 |
| Phase 2: 待機 | IoI（Indication of Interest）使用時 → 取引方向（買い/売り）が相手に一部漏洩 | IoIモード使用時のみ発生。Renegadeの任意機能だが、使用すると Direction Leakage が発生する。 | 高（IoI時） |
| Phase 3: マッチング | なし（MPC内で完結。双方の入力は秘匿されたまま計算） | Relayerはマッチング候補の「存在」を知る。pk_matchを保持するrelayerは、どの注文同士が候補か把握できる。 | 中 |
| Phase 4: 決済 | ZKP証明（正しさのみを証明）、トークンプール総量の変化 | 「何かの取引が起きた」こと自体はチェーン観察者に可視。ZKP証明のガスパターンから取引種別の推測も可能。 | 低 |
| Phase 5: 事後 | Nullifier（コイン使用済みの証明。内容は公開されない） | Nullifierのタイミング分析。定期的にNullifierを発行するウォレットは取引パターンとして識別されうる。 | 中 |
Renegadeでは pk_match（マッチングに使われる公開鍵）をrelayerが保持する。
これにより、relayerはどの注文がマッチング候補になっているかを知りうる。
Renegadeはrelayerを完全に信頼しない設計を目指しているが、 relayerが悪意を持つ（またはデータを記録する）場合、以下の情報が推測されうる：
マッチング計算が正しく行われたことを、注文内容を明かさずに証明する。 両当事者が「証人（witness）」を秘密に保ちながら共同でZK証明を生成（Collaborative ZK-SNARK）。
証明生成の計算量が大きい。また、証明サイズや生成ガスのパターンから、 使われた回路の複雑さ（= 取引の種類）がある程度推測される可能性がある。
Renegadeのアノニミティセットは「現在アクティブな注文の総数」に依存する。 流動性が低い市場では、マッチング候補が数件しかなく、アノニミティセットが急速に縮小する。 これは Nullifierのタイミングと相まって、取引の逆推測リスクを高める。
設計: バッチオークション + ZK set-membership proof
特徴: バッチ内の全注文を「同時」に処理。個別注文の識別を防ぐためのコミットメント＋ZK証明方式。
| フェーズ | 公開される情報 | 漏洩リスク | リスク度 |
|---|---|---|---|
| Phase 1: 注文提出 | コミットメント（内容非公開）+ ZK set-membership proof | set-membership proof のサイズ・形式からシステムの登録者数・コレクション規模が推測可能。 | 低 |
| Phase 2: 待機 | バッチ終了まで何も公開されない | なし。バッチ終了まで外部から一切観察不能。 | なし |
| Phase 3: マッチング | バッチ全体のクリアリング価格（単一値として公開） | 「このバッチで均衡価格がPだった」= 参加者の注文が概ねこの価格帯に集中していたと推測可能。 | 中 |
| Phase 4: 決済 | 各プレイヤーがいくら受け取ったか（誰かは分からない） | Relayerはユーザーの代わりにコミットメントをオンチェーンに提出するため、IPアドレス等を知りうる。 | 中（relayer対） |
| Phase 5: 事後 | なし | バッチ内の注文数から参加者数が推測されうる。 | 低 |
FairTraDEXの「プライバシー」はチェーン上の観察者（他のユーザー含む）に対するもの。 Relayerに対しては限定的。Relayerはユーザーのコミットメントを代理提出するため、 少なくともIPアドレス・注文タイミングを知る。
設計: 差分プライバシー（DP）を注文量にノイズとして適用。バイパルタイトグラフでマッチング。
特徴: 「量」をDPで保護するが、「完全マッチした場合は真の量を開示してよい」という設計的妥協点を含む。
| フェーズ | 公開される情報 | 漏洩リスク | リスク度 |
|---|---|---|---|
| Phase 1: 注文提出 | 量 x + ノイズ（価格 p は公開） | ノイズの統計分布からxの範囲が推測可能（εに依存）。εが大きいほどプライバシーは弱くなる。 | 中 |
| Phase 2: 待機 | バイパルタイトグラフの構造（一部） | グラフエッジから価格帯の分布が推測可能。どの価格レンジに注文が集中しているかが見える。 | 中 |
| Phase 3: マッチング | マッチング結果（どのペアが約定したか） | 出力相関の問題（→ Tab 4参照）。マッチされた双方の注文量が推測されうる。 | 高 |
| Phase 4: 決済 | 完全マッチした注文の真の量 x（Indifferential Privacy により公開可） | 設計上の意図的開示。完全マッチ後は量が開示される。大口機関投資家には受け入れがたい。 | 高（設計選択） |
| Phase 5: 事後 | 開示された量から逆算 | 長期的な参加パターンから大口トレーダーを統計的に特定可能。 | 中 |
「完全にマッチした注文の量は開示してよい」という設計。部分マッチの場合は残量が非公開。 これは標準的な差分プライバシーの適用方法とは異なる（通常のDPはクエリ結果にノイズを加えるが、 ここでは「完全マッチ」という条件付きで真の量を開示する）。
設計: シールドプール + プライベートAMM。ノートベースの資産管理とNullifierによる二重使用防止。
特徴: オーダーブック型ではなくAMM型。個別注文のマッチングではなくプール全体との取引。
| フェーズ | 公開される情報 | 漏洩リスク | リスク度 |
|---|---|---|---|
| Phase 1: 注文提出 | ZKP（ノート消費の証明）、Nullifier | Nullifierのタイミング。提出時刻からアクティブな取引者を識別可能。 | 中 |
| Phase 2: 待機 | なし（シールドプール内） | なし。 | なし |
| Phase 3: マッチング | AMMプールのreserve変化量 | 「大きなスワップがあった」ことはプール状態から推測可能。個別取引者は不明だが取引規模は見える。 | 中 |
| Phase 4: 決済 | ノートのコミットメント（内容非公開） | なし。コミットメントからは内容不明。 | なし |
| Phase 5: 事後 | Nullifier | Nullifierのタイミング分析（Phase 1と同様）。 | 中 |
AMMのプール状態（reserve_A / reserve_B の比率）は常にオンチェーンに公開される。 個別取引は見えなくても、reserveの変化量から「大きなスワップがあったこと」は明らか。 これはdark-pool-trilemmaの「価格発見とプライバシーのトレードオフ」の具体的な現れ。
論文: Chiang, David, Gama, Lebeda (AFT 2023)
発見: 入力（注文内容）を秘匿していても、マッチング出力の相関から情報が漏れる問題を定式化した。
「direction（買い/売り）」は最も基本的な注文情報だが、 多くの初期MPCダークプールではこれが漏洩していた。 2020年にJPM系統が初めて閉じ、2022年にBristol系へ波及したことがこのジャンルの転換点。
漏洩バグではなく、設計トレードオフとして明示的に諦めた漏洩面の一覧。 実用化を考える際の現実的な指標となる。
| 論文 | 諦めた漏洩面（明示的選択） | 理由 |
|---|---|---|
prime-match-2023 |
価格（外部固定）/ 銀行片方がaxeを知る | Semi-honestモデルの限界。計算コスト削減のために片方に情報を許容。 |
atlas-x-aamas2024 |
DPノイズ越しに統計的情報 / 隣接dataset定義の曖昧さ | 実用的な流動性確保のために ε が大きめになる。DPの「隣接」の定義が厳密でない部分がある。 |
block-auction-2021 |
reveal phaseでオペレーターが全注文を平文で見る | 事後監査モデル。取引後にoperatorが全注文を検証するため、暗号的秘匿は取引前のみ。 |
futuresmex-sp2018 |
匿名性が破られた場合のprice discriminationはex-post法執行に委任 | アノニミティ保証は確率的。悪用が発覚した場合は事後的な法的対応で対処する設計方針。 |
turquoise-plato-2020 |
TPU商用仕様の一部簡略化（direction漏洩を許容） | 商用システムとの互換性維持。学術的な最適解よりも実装可能性を優先。 |
プライバシーDEXを設計・評価する際に確認すべき漏洩面。クリックでチェック。
現在の研究・実装コミュニティで未解決として認識されている問題。
| 論文（wiki slug） | 主な貢献 | 漏洩面への含意 |
|---|---|---|
correlated-output-dp-darkpool-2023 |
Correlated-Output DP / Round DP の定式化 | 全システムに潜む出力相関リークを初めて形式化 |
renegade-darkpool |
MPC + Collab ZK-SNARK のデプロイ | Relayerへの信頼とIoIモードが残る漏洩面 |
fairtraDEX-2022 |
バッチオークション + ZK set-membership | Relayer対のプライバシー限界、参加者数推測 |
indifferential-privacy-darkpool-2025 |
DPを量に適用、完全マッチ後開示の設計 | 量の意図的開示という設計トレードオフ |
kicking-the-bucket-2022 |
Bristol系でdirection秘匿を達成 | Direction漏洩問題の業界的転換点 |
pp-dark-pools-aamas-2020 |
FHEでdirection秘匿を最初に達成 | JPMラインのオリジン、Cartlidgeラインへの反証 |
mpc-dark-side-2019 |
初期MPCダークプールの漏洩面を体系化 | Direction漏洩を業界全体の問題として記述 |
penumbra-dex |
シールドプール + プライベートAMM | AMM特有のreserve可視性という漏洩面 |
「プライバシーDEX」は単一のプロパティではなく、 フェーズ × 観察者 × 情報種別の三次元マトリクスで評価する必要がある。 すべての軸で完全なプライバシーを達成したシステムは2026年時点では存在しない。 実用的なシステムはどこかで設計トレードオフを受け入れており、 それを明示的にドキュメント化しているかどうかが評価の重要な指標となる。