Solana プライバシーランドスケープ

2022-2025年、3世代・7プロジェクトの進化 — Token-2022 CT / Arcium MPC / zkAMM / DFBA

3
世代
7
主要プロジェクト
2022
Phase 1 開始
2025
現在フロンティア
$2.76M
29日MEV被害
100ms
DFBAバッチ窓

Solanaプライバシーの3世代アーキテクチャ

Solana上のプライバシー技術は2022-2025年で急速に進化した。EVMが「L2ロールアップ+ZK証明」を中心に発展したのに対し、SolanaはToken-2022ネイティブCT + MPC(Arcium) + zkAMMという3層アプローチを取る。

PHASE 1 — 2022-2023 — 単一ユーザーツール Elusiv 停止 Shared Pool + ZK-SNARK "Anonymity loves company" Light Protocol 転換 UTXO + ZK Circuit (ZEXE類似) Private Solana Programs (PSP) 規制圧力→停止 →ZK Compression転換 PHASE 2 — 2024 — ネイティブ統合 Token-2022 Confidential Transfer El-Gamal暗号化 / アドレス公開+金額秘匿 / OFAC親和 監査中 ZK El-Gamal監査待ち PHASE 3 — 2025 — 共有プライベート状態 Arcium 稼働中 MPC-as-a-Service MXE + Arx Cluster + Arcis Elusiv MPC部門が独立 Cerberus / Manticore backend Darklake (zkAMM) 開発中 Pre/Post-trade privacy ZK + Arcium MPC統合 RenegadeのSolana版 Anchor + CLMM設計 DFBA (Jump Crypto) 研究段階 Dual Flow Batch Auction 100ms均一清算価格 Budish FBA拡張 レイテンシー軍拡競争を無効化

技術スタック比較

プロジェクト技術プライバシー対象規制親和性現況
Token-2022 CT El-Gamal暗号化 + ZK Range Proof 金額のみ（アドレス公開） ◎ OFAC自然適用 監査中
Arcium MPC (Cerberus / Manticore) 計算内容・中間状態 △ 要検証 稼働中
Darklake ZK証明 + Arcium MPC スリッページ/サイズ/価格 △ 未確認 開発中
DFBA バッチオークション（暗号不要） 時刻的フロントラン ◎ 構造的解決 研究段階
Elusiv Shared Pool + ZK-SNARK + MPC 送金元・送金先・金額 ✗ 規制リスク 停止
Light Protocol UTXO + ZK Circuit (ZEXE類似) PSP全般 — 未評価 ZK Compression転換

EVM vs Solana — プライバシーアーキテクチャ比較

観点SolanaEthereum / EVM
ネイティブCT Token-2022に組み込み（プロトコルレベル） プロトコル外（Aztec等L2で実装）
汎用MPC Arcium（Solana上でオーケストレーション） Renegade / Cartlidge系
DEXプライバシー Darklake / DFBA Privacy Pools / Renegade
メンプール Jito（外部プロトコル）/ DeezNode MEV-Boost（外部）/ PBS
規制対応 CTのアドレス公開が自然なコンプライアンス Privacy Pools / zkKYC / 匿名資格証明
バッチオークション DFBA（100ms窓、Solana Archer） CoW Protocol / Gnosis Auction

Phase 1 (2022-2023) — 単一ユーザーツール時代

最初の世代は、既存の暗号プリミティブをSolanaに移植する試みだった。EVMのTornado CashやMoneroのアイデアを参照しながら、独自のZK回路とプールモデルを実装。しかし両者とも2024年に方向転換を余儀なくされた。

Elusiv — 共有プールプライバシー

設計思想

"Anonymity loves company" — 参加者が多いほど追跡が困難になる。共有プール（Shared Pool）モデルを採用し、ZK-SNARKで所有権を証明しながら任意金額の引き出しを可能にした。

  • 観察者に見えること: 「誰かがプールに入れた / 出した」という事実
  • 観察者に見えないこと: 誰が誰に送ったか、金額の紐付け
  • ZK証明の内容: 残高コミットメントに対するOwnership証明

Decentralized Compliance設計

完全匿名化だけでなく、規制当局向けの選択的開示も設計に含まれていた。

  • ZK-SNARK + MPCを組み合わせた選択的開示 (Selective Disclosure)
  • ユーザーは必要に応じて取引証明を生成可能
  • MPC部門は後にArciumとして独立（設計資産が継承された）
シャットダウン経緯
Tornado Cash制裁（2022年8月）、Roman Storm起訴（2023年）の余波を受け、2024年初頭に規制リスクを判断してシャットダウン。
根本的教訓: 共有プールモデルは「money transmitter」認定リスクを避けられない。匿名性の集合が利点であると同時に規制上の標的となる。

Elusiv → Arcium の継承関係

1
Elusiv停止
(2024初)
→
2
プール部門終了
MPC部門分離
→
3
Arcium独立
ブランド化(2024)
→
4
Darklake等と
統合(2025)

Light Protocol — Private Solana Programs

技術設計

  • UTXO モデル: EVM accountモデルではなくUTXO設計でプライバシー実現
  • ZK Circuit: ZEXE類似設計 — オフライン実行 + ZK証明をon-chainに提出
  • PSP (Private Solana Programs): 開発者が独自プライベートロジックをZK回路で定義可能
  • Shielded Pool: Solana SPL + CompressedToken統合

2024年の方向転換

プライバシーからスケーラビリティへのピボット。ZK Compressionを採用し、状態圧縮によってSolanaのオンチェーンデータコストを大幅削減することが主目的になった。

  • プライバシー機能は二次的目標に後退
  • ZK Compression: 1000倍以上のコスト削減を実現
  • ピボット理由: プライバシー需要よりスケーラビリティ需要が市場で勝った
Phase 1 からの学び
Elusiv: 共有プールモデルは暗号的には優れているが、法的には「マネートランスミッター」に近い。規制当局はプールの運営者を処罰対象とする。
Light Protocol: ZK回路によるプライバシーは技術的に実現可能だが、市場需要はスケーラビリティに向いていた。プライバシーはニッチ市場。

Phase 1 プロジェクト比較

項目ElusivLight Protocol
モデル共有プール (Shared Pool)UTXO + ZK
ZK技術ZK-SNARK (Groth16系)ZK Circuit (ZEXE類似)
対象SPLトークン転送プライバシー任意プライベートプログラム
コンプライアンス選択的開示設計ありなし
2024年の運命規制圧力でシャットダウンZK Compressionへピボット
遺産MPC部門→Arcium独立ZK Compression (Solanaエコシステム基盤)

Phase 2 (2024) — Token-2022 Confidential Transfer

Token-2022はSolanaのネイティブトークンプログラム拡張で、Confidential Transfer (CT) extensionによりプロトコルレベルでの金額秘匿を実現する。EVMが外部L2でプライバシーを実装するのと対照的に、Solanaはプロトコルに直接組み込んだ。

El-Gamal暗号化フロー

Sender plaintext: 1000 USDC r = random scalar address: PUBLIC amount: ENCRYPTED El-Gamal 暗号化 Ciphertext C = (rG, rP + mH) G, H = curve points P = recipient pubkey on-chain state ZK Range Proof生成 ZK Range Proof 「amount ∈ [0, 2^64)」 金額を開示せずに 範囲正当性を証明 verifier accepts ✓ Valid コンプライアンス設計のポイント アドレスはオンチェーンで公開 → OFAC制裁リスト照合が自然に可能 / 金額のみ暗号化 → 規制当局との親和性が高い

設計の強み

  • プロトコルネイティブ: 外部コントラクトではなくToken-2022に組み込み
  • アドレス公開 + 金額秘匿: 規制当局がアドレスベースでスクリーニング可能
  • OFAC自然適用: Tornado Cashのように「アドレスも隠す」設計ではない
  • 機関投資家対応: プロプラ残高を競合に隠しながらDeFi参加可能

現況と課題

  • ZK El-Gamal Programのセキュリティ監査中
  • 監査完了までmainnet一時停止状態
  • Testnetでは稼働中
  • 監査機関: 複数の外部セキュリティ企業が担当

Tornado Cash問題との構造的差異

比較点Tornado Cash (EVM)Token-2022 CT (Solana)
アドレス秘匿 ◎ 完全匿名 × アドレス公開
金額秘匿 ◎ 秘匿 ◎ El-Gamalで秘匿
OFAC対応 ✗ 困難（アドレス不明） ◎ 自然に適用可能
規制リスク 制裁済・停止 コンプライアンス設計
プロトコル組み込み 外部コントラクト Token-2022ネイティブ
CT + zkKYC の組み合わせ
最も規制耐性の高い設計: Token-2022 CT（金額秘匿）+ zkKYC / Anonymous Credentials（本人確認をZKで証明）を組み合わせることで、「金額は隠しつつ、適格投資家であることをZK証明する」設計が実現可能。現在の研究フロンティア。

Phase 3 — Arcium: MPC-as-a-Service

Arciumは暗号化されたまま多者間計算を行うMPC基盤。計算が完了して初めて結果が公開される。Solana上でオーケストレーション（タスクキュー/報酬/スラッシング）を管理し、分散ノード群が秘密分散を協調実行する。

Arciumアーキテクチャ 4要素

Developer Layer Arcis — Rust DSL for MPC circuit description MXE MPC eXecution Environment Single-Use / Recurring コンテキスト ステートレス Arx Node Cluster 複数ノードがsecret shareを保持 協調してMPC計算を実行 dishonest majority耐性 arxOS 各Arxノードが稼働する 暗号化オペレーティングシステム Solana (Orchestration) タスクキュー / 報酬分配 スラッシング（不正ペナルティ） 計算ライフサイクル Definition → Commission → Mempool → Execution → Callback

2種類のMPCバックエンド

Cerberus — Dishonest Majority設定

  • セキュリティ保証: 最高レベル。少なくとも1ノードが正直であればOK
  • 適用場面: DeFi秘密取引、プライベートオークション
  • 特徴: 多くのノードが悪意を持っても安全が保たれる
  • 速度: Manticoreより低速
  • 信頼前提: 最小（Byzantine fault tolerant）

Manticore — HBC + Trusted Dealer

  • セキュリティ保証: Honest-but-Curious (HBC) モデル
  • 適用場面: ML/AI推論、高速が必要なユースケース
  • 特徴: Cerberusより大幅に高速
  • 速度: 高速（AI推論対応）
  • 信頼前提: 参加者が正直だが好奇心を持つと仮定

計算ライフサイクル

1
Definition
回路定義(Arcis)
2
Commission
クラスター選択
3
Mempool
タスクキュー登録
4
Execution
MPC協調計算
5
Callback
結果のみ公開

プライバシー技術比較

技術速度信頼前提DeFi適合性実装例
Arcium (MPC) 中〜高 誠実な少数派で十分 ◎ 高 Darklake, プライベートオークション
FHE 非常に低速 なし（完全暗号化） △ 速度問題 FHE-MEV (EVM), 実験段階
TEE 高速 ハードウェア(Intel SGX等) △ HW信頼必要 Secret Network, Phala
ZKP (ZK-SNARK) 中（証明生成コスト） なし（数学的保証） ◎ 高 Token-2022 CT, Darklake pre-trade
DeFi応用例
Arciumが実現する具体的なユースケース: (1) 秘密注文マッチング（Darklake統合）— スリッページ・サイズ・価格を暗号化したまま約定 (2) プライベートオークション — 入札価格を開示せず最高入札者が勝利 (3) AI推論プライバシー — ユーザーデータを開示せずML推論 (Manticoreバックエンド)

Darklake — zkAMM (Pre/Post-trade Privacy)

問題: 通常AMMのMEV被害実績
Raydium / Pumpfunでの計測値: 29日間で18,409 SOL ($2.76M) が186,159件の攻撃で流出
通常AMMではスリッページ許容値・注文サイズ・価格パラメータがvalidatorに全部可視化される
$2.76M
29日間MEV被害 (Raydium/Pumpfun)
186,159
攻撃件数 (29日間)

Darklake: プライバシー保護スワップフロー

User Order slippage: VISIBLE size: VISIBLE price: VISIBLE ← 通常AMM ZK証明 Pre-trade Privacy slippage: HIDDEN size: HIDDEN price: HIDDEN ZK証明で秘匿したまま提出 Arcium MPC統合 Post-trade Privacy Dark Pool Order Book 暗号化された共有状態 約定後のみ結果公開 Arcium協調実行 約定 結果 公開 ZK AMM + MPC = フル暗号化執行レイヤー 技術: Solana Anchor + Uniswap v3スタイル CLMM + 機密スワップ機能 LunarPunkビジョン: プライバシーをマーケット構造の根本レイヤーとして埋め込む 類比: EVM系RenegadeのSolana版

DFBA (Jump Crypto) — Dual Flow Batch Auction

CLOBの構造的欠陥であるフロントランニング・sandwich攻撃・レイテンシー軍拡競争を、バッチオークション設計によって根本的に解決する提案。

CLOBの構造的問題
Time-priority (FIFO) → レイテンシー軍拡競争 → コロケーション・専用回線への巨大投資
自然流量トレーダー (ordinary traders)が最大の被害者：フロントランニング・sandwich攻撃の標的

DFBAの設計: 100msバッチ窓

0ms 100ms 100ms バッチ収集ウィンドウ — 全注文が同時に処理される #1 Maker-Buy 10.00 × 100 @10ms #2 Maker-Sell 10.01 × 100 @14ms #3 Taker-Buy 10.05 × 300 @34ms #6 Maker-Buy 9.97 × 1000 @75ms Bid Auction 清算結果 清算価格 = 9.97 (Uniform Clearing Price) / 約定量 = 500単位 ⚡ @10ms の注文も @75ms の注文も 同じ価格 9.97 で約定 → 100ms以内であれば到着時刻は完全に無関係

DFBAが解決する問題

  • 先着順が無意味化: 100ms以内なら誰でも同じ清算価格
  • マイクロ秒投資のROIゼロ: コロケーション/専用回線の優位性消滅
  • フロントランニング不可能: バッチで処理されるため順序操作不可
  • sandwich攻撃不可能: 全注文が同時に清算されるため挟み込み不可

2オークション設計

  • Maker Orders: 流動性提供者の継続的指値注文
  • Taker Orders: 自然流量トレーダーの成行・指値注文
  • t=0ms〜100ms: 注文収集フェーズ
  • t=100ms: Bid Auction + Ask Auction 同時清算
  • Uniform Clearing Price: 全参加者が同一価格で約定

Budish FBA (QJE 2015) との関係

DFBAはBudish (2015)の"Frequent Batch Auction"提案を発展させたもの。Budish FBAが単一清算価格を提案したのに対し、DFBAはMaker/Taker分離型2オークションという構造に進化させた。これにより流動性提供者と自然流量トレーダーの役割を明示的に分離し、より現実的なマーケット設計を実現。実装: Solana Archer Exchange (Hackathon POC) + Urani。

Solana MEV コンテキスト

DeezNode (private mempool独占)

Jito停止 (2024-03) 後に台頭したプライベートmempool。

MEV対策の3アプローチ

sr-AMM

Sandwich-Resistant AMM。スロット開始価格より有利な価格でのswapを禁止。AMM設計レベルの対策。

Paladin

Validator levelでsandwich TXを拒否するソフトウェア。validator協力が前提。

MCL

Multiple Concurrent Leaders。長期的解決策。複数リーダーが同時に存在することでsingle point of MEV extraction を排除。

Privacy → MEV保護の連鎖

技術MEV保護メカニズムアプローチ
Arcium MPC 注文が暗号化 → フロントランに必要な情報がゼロ 暗号解決
Darklake zkAMM スリッページ秘匿 → sandwich標的化不可能 暗号解決
DFBA batch clearing → 到着時刻の価値ゼロ化 設計解決

未解決問題 (2025)

1. Token-2022 CT mainnet有効化

ZK El-Gamal Programのセキュリティ監査完了待ち。監査完了後、mainnetで金額秘匿が正式稼働する。機関投資家のDeFi参入に向けた最重要マイルストーン。

ブロッカー: 複数外部セキュリティ企業による監査 / 潜在的なバグリスク

2. Arcium × DeFiの統合成熟度

mainnetでの実戦的ダークプール（Darklake）はまだ開発段階。MPC計算のlatencyがDeFiのリアルタイム性要件に合うか検証が必要。Cerberusバックエンドの実際のスループット計測が待たれる。

ブロッカー: Arcium-Darklake統合の本番稼働 / MPC latency vs. DEX要求の整合

3. DFBAのmaker/taker判定問題

「誰をmakerとして認定するか」という定義問題が残る。高頻度トレーダーが意図的にmakerに分類されることで、DFBAの均一清算価格の恩恵だけを享受しようとするインセンティブが生じる可能性。

ブロッカー: maker認定ルールの形式化 / ゲーム理論的安定性の検証

4. 規制耐性の検証

Elusivの後継としてArciumが同様の規制圧力を受けるリスク。MPCアーキテクチャはプールではないため法的リスクは低いと見られるが、未検証。特にArcium上で動くDarklakeがmoney transmitter認定を受けるかどうかが焦点。

ブロッカー: 米国規制当局のMPCサービス解釈 / FinCEN/SEC見解

5. MEV保護+プライバシーの共存

DFBAは設計でMEVを解決、MPC/ZKは暗号でMEVを解決するが、両者を同時に実現するシステムはまだない。Darklake + DFBAを組み合わせた「暗号+設計のハイブリッド」が理論上最強だが、実装されていない。

規制設計の系譜

Elusiv (停止) Shared Pool = money transmitter 規制リスク → 停止 学び Elusivの失敗から学んだこと プールはNG / アドレス秘匿は危険 コンプライアンスは設計段階で必要 MPCはプールではない（法的に別物） Arcium (MPC非プール型) 計算のみ、中間保管なし Token-2022 CT 金額秘匿のみ / アドレス公開継続 最適設計: CT (金額秘匿) + zkKYC (匿名資格証明) = 「金額は隠しつつ適格投資家をZK証明」 → これが現時点で最も規制耐性が高いと考えられるアーキテクチャ

Solana Privacy投資動向

注目投資家 / VC

  • Coinbase Ventures: Solana DeFiプライバシー全般に関心。CTのコンプライアンス親和性を評価
  • Dragonfly Capital: Arciumラウンドに参加（MPC-as-a-ServiceのDeFi展開）
  • Jump Crypto: DFBA論文執筆 + Archer Exchangeへの直接関与
  • Multicoin Capital: Solana優位性論者として全般的にSolana DeFiインフラを支援

研究コミュニティ動向

  • ZK Research: ZK El-Gamal証明の最適化（Bulletproofの応用）
  • MEV Research: DFBA ↔ Jito統合の可能性研究
  • Regulatory Tech: CT + zkKYCの統合プロトタイプ実装
  • MPC Performance: Cerberusのlatency最適化 (DeFi向け)

まとめ: Solanaプライバシーの位置づけ

世代特徴成否次世代への継承
Phase 1 単一ユーザーツール（Elusiv/Light） 両者方向転換 MPC設計資産 → Arcium / ZK技術 → ZK Compression
Phase 2 ネイティブCT（Token-2022） 監査中・保留 コンプライアンス設計の標準として確立予定
Phase 3 MPC + zkAMM + DFBA 進行中・成長 現在のフロンティア。mainnet実戦化が課題
総括
Solanaプライバシーは、EVM（L2 + ZK + プライバシープール）とは異なるアーキテクチャパスを歩んでいる。ネイティブCT + MPC-as-a-Service + バッチオークションという3層構造は、それぞれ異なる問題（金額秘匿 / 計算秘匿 / MEV）を独立して解決しつつ、相互に補完する設計になっている。規制対応においても、アドレス公開を維持するCTのアプローチはEVM系の「完全匿名化」より現実的なコンプライアンス経路を提供している。