Dark Pool 三重ジレンマ · Adversaryモデル

The Dark Pool 三重ジレンマ

Core claim: A ダークプール cannot simultaneously maximize Liquidity, Privacy, and 価格発見. Every real system occupies a different position inside the triangle — optimizing two requires sacrificing the third.

deep-ocean-2019 — size-only secret, chain-independent

FairTraDEX-2022 — FBA batch, MEV=0

MPC-100party-2022 — UC-secure, no operator

Common OB-2023 — unified ZK orderbook

IndifDP-JPM-2025 — DP noise on aggregates

Renegade — P2P + collaborative SNARK

Per-Paper 三重ジレンマ Positions

Paper	Prioritizes	Sacrifices	Mechanism
deep-ocean-2019	Partial プライバシー	Strong anonymity	Size-only secret; chain-independent relay
FairTraDEX-2022	Price discovery MEV prevention	Full order secrecy	Frequent Batch Auction (FBA) clearing
MPC-100party-2022	Strong プライバシー	Scale & throughput	100-party MPC; no trusted operator
Common OB-2023	Liquidity agg.	分散化	Unified orderbook + ZK membership proof
IndifDP-2025 (JPM)	Price discovery	Individual order secrecy	DP noise on aggregate stats (ε,δ)
Renegade	Full プライバシー	Liquidity discovery cost	P2P + collaborative SNARK matching

4th problem (orthogonal to trilemma): Correlated-Output DP (2023) showed that even when inputs are perfectly secret, matching outputs — who matched with whom — can be statistically correlated to reconstruct order contents. This attack is independent of which trilemma corner a system inhabits.

Privacy vs 価格発見 — Detailed Breakdown

Why the tension exists

Traditional price discovery requires observable order flow: limit order books show pending demand and supply, enabling fair clearing. But in a プライバシー-preserving ダークプール, orders are hidden — no participant can verify the clearing price is fair without an external reference.

Classical solution Use external reference price (NBBO / oracle) →
New problem Oracle dependency / manipulation surface

The FBA approach (FairTraDEX)

Frequent Batch Auction batches all orders in a fixed interval and clears at a uniform price. Ordering within a batch is irrelevant → frontrunning profit = 0. Price is determined by aggregated supply/demand, not a single oracle.

Clearing price = argmin |supply(p) - demand(p)| Fixed fee per order regardless of size → no slippage signal

Price discovery: good Privacy: partial — relayer sees all orders

IndifDP: The New Approach (JPMorgan 2025)

Key insight: Instead of hiding everything (kills price discovery) or revealing everything (kills プライバシー), reveal noisy aggregates using Differential Privacy. Individual orders stay hidden; the market can still estimate supply/demand curves.

The ε Tradeoff

Small ε (strong プライバシー)

ε → 0 Large Laplace noise added Aggregate: "~X ETH ± very large range" → Price discovery: poor → Individual order: very protected

High プライバシー Poor price signal

Large ε (weaker プライバシー)

ε → ∞ Small noise, aggregate ≈ true value Aggregate: "~26.1 ETH in $2980-$3000" → Price discovery: good → Individual order: partially reconstructable

Weaker プライバシー Good price signal

Comparison: Three 価格発見 Strategies

Strategy	Price Source	Privacy Cost	Oracle Risk	Example
External Reference	NBBO / Chainlink oracle	None (orders hidden)	High — oracle manipulation	Renegade (mid-price from Hyperliquid)
Batch Auction (FBA)	Aggregated submitted orders	Relayer sees all orders	None	FairTraDEX
IndifDP Aggregates	Noisy aggregate order stats	(ε,δ)-DP bound on leakage	None	JPMorgan IndifDP 2025

Adversary Taxonomy — 5 Types（敵対者分類 — 5つのタイプ）

ブロックビルダー / Validator

Controls transaction ordering in a block. Source of classic frontrunning and MEV extraction. Can sandwich, displace, or delay orders on-chain.

Strongest on-chain

Operator / Relayer

Runs the matching server or relay node. May see plaintext order contents before execution. Semi-honest = follows protocol but records everything. Malicious = actively cheats.

Most common threat

悪意ある参加者

A trader or liquidity provider that deviates from the protocol to learn other participants' orders. May submit probe orders, abort mid-protocol, or replay partial state.

Active insider

外部観測者

Reads only public blockchain data. Infers order contents from timing patterns, match outputs, gas usage, or settlement amounts. No privileged access.

Passive, on-chain

Colluding Group

Multiple parties (e.g., n-1 servers, operator + trader) combine partial information to deanonymize individual orders that each party could not reconstruct alone.

Combinatorial threat

Per-System Security Analysis

P2DEX (ACNS 2021) — Strongest adversary assumption

Protected against

E n-1 malicious servers → UC-secure MPC handles
C Malicious clients → UC-safety guaranteed
B Individual operators → Insured MPC (misbehavior = deposit loss)
D External observers → all orders committed before reveal

Not protected against

E Full server collusion (n-of-n) — impossible to handle
— DoS / liveness attacks

Reality check: Proving overhead makes production throughput impractical (~5 orders/sec estimated)

FairTraDEX (2022) — Game-theoretic protection

Protected against

A Block builder — FBA makes ordering irrelevant; frontrunning profit = 0
C Malicious market maker — Nash equilibrium forces fair pricing
D External observer — orders committed before clearing

Not protected against

B Relayer sees all orders in plaintext
C Non-rational attacker breaks Nash equilibrium

Fixed fee regardless of order size → no slippage signal leakage

Indifferential Privacy — JPMorgan 2025 (Weakest assumption, fastest)

Protected against

D External observers — (ε,δ)-DP bound on info leakage from aggregates
Individual order content → hidden behind DP noise

Not protected against

B Malicious operator — only semi-honest assumed
C Malicious participants — not addressed
E Colluding groups — not addressed

Full match quantity still revealed; clearing price is public — only aggregate stats are noisy

Rialto (2021)

Protected against

A Block builders → on-chain settlement only after MPC
D External observers → commitments before reveal
E Up to minority collusion among broker nodes

Not protected against

B/C Broker + trader collusion
B Top-K order rate visible to brokers (partial leak)

Claims 1000 orders/min but Top-K order rate is partially visible to brokers

Renegade — Design goal vs reality

Design goal

Hide all order information from external parties
ZK-protected order matching
P2P discovery, no central operator

Known limitations

B Relayer holds pk_match → semi-trusted Type B
IoI mode Indication-of-Interest reveals trade direction to relayer

No IoI = can't find counterparty. IoI = direction leaks. Fundamental tension.

Prime Match (JPMorgan 2021+) — Institutional trust model

Security model

Bank-to-client: semi-honest bank + malicious clients
Client-to-client: bank as honest intermediary
2-3 round MPC for quantity computation

Not protected against

B Bank itself being adversarial — institutional trust assumed

Institutional trust replaces cryptographic guarantees — works in TradFi, not in permissionless DeFi

Security Matrix Summary（セキュリティマトリックス概要）

System	A: ブロックビルダー	B: Operator	C: Malicious User	D: 外部観測者	E: 結託者
P2DEX	Protected	n-1 malicious OK	UC-safe	Protected	Up to n-1
FairTraDEX	Nash eq. → profit=0	Relayer trusted	Game-theoretic	Protected	Limited
IndifDP	N/A	Semi-honest only	Not addressed	(ε,δ)-DP bound	Not addressed
Rialto	Protected	Honest-majority	Partial	Protected	Up to majority
Renegade	Design goal	IoI leaks direction	ZK-protected	Protected	Not addressed
Prime Match	N/A	Bank trusted	2-3 round MPC	N/A	N/A

Security Strength（セキュリティ強度） vs Throughput（スループット）

Key insight: Security assumption strength and performance are inversely correlated. The system with the strongest cryptographic guarantees (P2DEX, UC-secure) is essentially impractical. The system that ships at production scale (IndifDP) makes the weakest security assumptions.

Security Assumption Strength（セキュリティ仮説強度） vs Throughput（スループット）

System	Adversary Coverage	Throughput (est.)	Security Cost	Ships Today?
P2DEX	n-1 malicious servers	~5 orders/sec	Full UC-MPC proving overhead	No
MPC-100party	Strongest — no operator	<1 orders/sec	100-party communication rounds	No
Renegade	ZK-protected, IoI tradeoff	~20 (est.)	Collaborative SNARK generation	Beta
Prime Match	Bank semi-honest	~10-20	2-3 round MPC, institutional trust	Yes (TradFi only)
Rialto	Honest-majority brokers	~17 (1000/min)	Threshold MPC	Prototype
FairTraDEX	Game-theoretic only	~100 (batch)	FBA interval latency	Proposal
IndifDP	Semi-honest operator only	600-850	DP noise computation (lightweight)	Proposal (JPM)

"数桁のスループット改善はそれぞれ、ほぼ1段階弱いセキュリティ仮説に対応する。これは偶然ではなく、分散信頼計算の基本的なコストを反映している。"

Production Gap（本番化ギャップ）: Why Only Prime Match Works

The gap: Academic ダークプール designs have existed since at least 2019. As of 2025, only Prime Match (JPMorgan 2021+) is in production use — and it operates only in TradFi with institutional trust replacing many cryptographic guarantees.

4 構造的障壁

計算コスト

ZK回路証明時間は注文複雑性とともに増加する。MPCはn者間で複数の通信ラウンドが必要。どちらも集約化された取引所マッチングエンジン（毎秒数百万注文）より数桁遅い。

Prime Match ソリューション：min(x,y) 数量のみが必要 → 純線形演算 → 極端に安い悪意あるセキュリティ。ホットパスに ZK 証明なし。

カウンターパーティーディスカバリー

注文をマッチングするには、当事者は互いを見つける必要がある。ただし、完全にプライベートなシステムでは、情報を明かさずに「ETH を売りたい」とブロードキャストできない。プライベート集合交差 (PSI) は非マッチ注文を明かさずにマッチを見つけることができるが、大規模なオーダーブックの PSI は高コスト。

Prime Match ソリューション：事前共有「斧リスト」 — 機関投資家クライアントが銀行に概略の関心を事前宣言し、リアルタイム検索をバッチ照合に変換。問題の性質が根本的に変わる。

オペレーター集約化

マッチングプロセスを調整する必要がある。中央リレーはすべての注文を見る信頼できる当事者になる（FairTraDEX問題）。MPC経由で分散化すると通信ラウンドとオーバーヘッドが追加される。FairTraDEXリレーは情報漏えいの単一ポイント — ただし削除するとパフォーマンスが死ぬ。

Prime Match ソリューション：銀行がオペレーター — 機関信頼がこの緊張を完全に排除。銀行がライセンスされて監査される規制金融環境で機能。

出力相関リークセージ

Correlated-Output DP (2023) discovery: even with perfect input プライバシー, matching outputs — who matched with whom, at what time, for what quantity — can be statistically correlated across trades to reconstruct order book contents. This is distinct from the trilemma and was not addressed in most pre-2023 designs.

Prime Match solution: only the bank sees results. Limited publication of match confirmation avoids the correlation attack surface. Result: not a cryptographic solution, but a policy solution.

Prime Match Anatomy（Prime Match解剖学）

DeFi Roadmap: Overcoming Each Barrier Without Institutional Trust

Barrier	Best Known Approach	Maturity	Key Paper / System
Computation cost	Indifferential Privacy (DP) — avoid ZK/MPC in hot path entirely	Proposal	JPM IndifDP 2025
Counterparty discovery	Private Set Intersection (PSI) over intent hashes	Research	Renegade IoI / PSI literature
Operator centralization	100-party MPC with no single operator (e.g., dark-pool-mpc-2022)	Experimental	All-for-One ダークプール 2022
Output correlation leak	Correlated-Output DP — add noise to match output disclosure	Theory	Correlated-Output DP 2023

Hard truth: Even the combination of all four "best approaches" above does not yield a production-ready permissionless ダークプール in 2025. Each approach is at proposal or research stage individually; their combination has not been demonstrated. The production gap is structural, not just an engineering delay.

設計チェックリスト — Building a Dark Pool

Use this checklist when evaluating or designing a ダークプール system. Check off decisions as you make them — your choices in early sections constrain later options.

Checklist progress 0 / 24

Step 1 — Choose 三重ジレンマ Position

I accept that I cannot maximize all three: Liquidity, Privacy, 価格発見

Explicitly decide which two to optimize. Document the sacrifice.

Liquidity is primary — I will reveal some order information to attract participants

→ Consider: Common OB approach (unified orderbook + ZK membership), FairTraDEX batch

Privacy is primary — I accept reduced liquidity discovery and oracle dependency

→ Consider: Renegade P2P model, MPCベース approaches

価格発見 is primary — I will reveal aggregate stats or use FBA batch clearing

→ Consider: IndifDP (DP aggregates), FairTraDEX (FBA), external oracle reference

Step 2 — Define Adversary Model

Type A (ブロックビルダー): Do I need on-chain ordering protection?

Yes → Use FBA, commit-reveal, or off-chain MPC settlement. No → proceed.

Type B (Operator): What is my operator trust assumption?

Semi-honest only → IndifDP or FairTraDEX. Malicious operator → P2DEX or 100-party MPC (expensive).

Type C (悪意ある参加者): Can participants cheat to learn others' orders?

If yes → need UC-secure MPC or game-theoretic equilibrium. If semi-honest sufficient → cheaper.

Type D (外部観測者): Must I protect against blockchain analysis?

Yes → commit before reveal, DP on outputs. No → standard settlement.

Type E (Colluding Group): What collusion threshold do I tolerate?

t-of-n threshold → threshold MPC. Full majority-honest → Rialto-style. All-but-one → P2DEX.

I have documented my adversary model explicitly and shared it with users

Security without a defined threat model is marketing. Write it down.

Step 3 — Architecture Decisions

Counterparty discovery mechanism chosen

Options: IoI broadcast (Renegade, leaks direction), PSI (expensive), pre-shared axe list (Prime Match), public intent (weak プライバシー)

Clearing price source decided

External oracle (manipulation risk), FBA batch (relayer trust), DP aggregates (ε tradeoff), MPC-computed (expensive)

Output publication policy defined

Correlated-Output DP (2023) attack: match outputs reveal input content even with private inputs. How much of match output is public?

Settlement layer chosen (on-chain vs off-chain vs hybrid)

Full on-chain → vulnerable to Type A. Off-chain MPC + on-chain settlement → protected but complex.

Step 4 — パフォーマンス Budget

Target throughput defined (orders/sec)

<20: MPC approaches feasible. 20-200: FBA/DP hybrid. >200: must use lightweight crypto (IndifDP range).

Latency target defined (ms per match)

MPC rounds add 100-1000ms. ZK proving adds seconds. FBA adds batch interval (e.g., 100ms). DP is near-zero overhead.

パフォーマンス vs security tradeoff explicitly accepted

Every security improvement costs throughput. This is not a solvable problem — it is a fundamental constraint.

Step 5 — Context (TradFi vs DeFi)

TradFi / institutional: Can I use institutional trust in place of cryptographic guarantees?

If yes → Prime Match approach. Bank as operator solves barriers 2, 3, 4 at once. Regulatory framework provides audit trail.

Permissionless DeFi: I accept none of the four production barriers are fully solved

Honest assessment of the state as of 2025. You are building research/experimental infrastructure.

Regulatory compliance requirements identified

KYC/AML requirements may force metadata publication that undermines プライバシー guarantees. Compliance × Privacy is a separate design problem.

Step 6 — Before Launch

Security model is publicly documented and peer-reviewed

Unpublished security claims are unverifiable. Dark pool security is subtle — get external review.

Correlated-Output DP attack surface analyzed

Even if inputs are private, matching outputs may leak. Analyze your specific output publication policy against the 2023 result.

ε budget (if using DP) set with explicit プライバシー-utility tradeoff documentation

Publish your ε parameter and what it means in plain language. Users need to understand what "protected" actually means.