Shielded Pool（シールドプール）の構造・実装・課題の決定版。Zerocash 理論から Zcash 系譜、Tornado/Aztec/RAILGUN/ZKBob/Privacy Pools の EVM 実装、Penumbra/MASP の DeFi 統合、そして anonymity set フラグメンテーション・規制圧力・計算コストまで、20 論文 + 15 実装で深堀り。
Shielded Pool（シールドプール）とは、複数ユーザーの暗号化された残高を同一プールに集約し、誰が誰にいくら送ったかを ZK 証明で隠したまま検証可能にする仕組み。Zerocash (2014) を理論基盤とし、Zcash/Tornado/Aztec/RAILGUN/Penumbra 等の中核として 10 年で実装が進化してきた。核心は commitment + nullifier + Merkle tree + ZK proof の 4 要素の組み合わせ。
「全員の残高を一つの巨大な集合（pool）に commitment として登録し、移動・引出は『私はこの集合のどれかの所有者だが、どれかは言わない』を ZK 証明する」
1. Commitment: 「いくら・誰が・乱数」を hash で隠して登録 (c = H(v, pk, r))
2. Nullifier: 二重消費を防ぐ「使用済みマーク」(nf = H(sk, c))
3. Merkle Tree: 全 commitment を集合化、root のみオンチェーン
4. ZK Proof: 「私は集合のどれかの所有者で、nullifier が正しい」ことを内容を明かさず証明
代表: Zcash / Tornado / Aztec / RAILGUN / Penumbra
モデル: 各 note が独立、消費 → 新 note 生成
各 transaction は input notes を nullify し output notes を作る。Bitcoin 風で並列性が高い。
代表: Zether / Anonymous Zether
モデル: 各 account に暗号化残高 (ElGamal/AHE)
Zether は同種準同型暗号で残高を保持。N-out-of-anonymity set は ring proof で実現するが scaling が課題。
実装上の支配的選択は UTXO 風。Zcash 系譜の note モデルがほぼすべての shielded pool 実装で採用される。本ページでも以降は UTXO 風を中心に解説する。
どの shielded pool 実装も、内部構造は commitment / nullifier / Merkle tree / ZK proof の 4 要素に分解できる。本タブでは各コンポーネントの目的・数式・性質・実装例を 1 セットずつ解剖する。これを理解すれば、Zcash・Tornado・Aztec・RAILGUN・Penumbra の違いも「同じ骨格の異なる肉付け」として捉えられる。
note の中身（金額・所有者・乱数）を hash で隠して、オンチェーンに「登録」する。後で「私はこの commitment の note を持っている」と ZK で証明できる。
数式c から (v, pk, r) は復元不能（r が一様乱数）(v', pk', r') を主張できない（衝突困難）Sapling (Zcash): Pedersen commitment cm = COMM(g^v · h^r)。楕円曲線群上の準同型あり。
Aztec / RAILGUN: Poseidon hash。ZK-friendly な algebraic hash で constraint 数が小さい。
Tornado Cash: MiMC hash (BN254 上)。後発実装は Poseidon に移行。
Orchard: Sinsemilla hash（Pallas curve）。lookup table 活用。
c を得る。c が公開、内訳は秘密。commitment c を「消費」したことをチェーンに記録する必要がある。しかし c 自体を公開すると linkability が生じ（誰の note か特定）、shielded の意味が消える。
解: c とは別の値 nf を生成し、nf を「使用済み集合」に追加する。c と nf の関係は ZK proof 内のみで検証される。
nf（二重 spend を nullifier set で検出）nf と c の対応が不明（sk が secret）nf（誤検出なし）nf = PRF^{nk}(ρ) ここで ρ は note 固有の random、nk は nullifier keynf = MiMC(secret, nullifier_seed) シンプルな key + seednf = Poseidon(commitment, owner_sk, position) position も入れて衝突回避全ユーザーの commitment を扱う集合は数百万〜数十億規模になる。これをオンチェーンに保持できない。解は Incremental Merkle Tree: depth 32 で 2³² ≈ 40 億 note を持ち、オンチェーンには root（32 bytes）のみ を保存する。
c4 (★) を所有することを証明するには、c4 の sibling c5、L2 の sibling L2_3、L1 の sibling L1_0 の 3 つの hash を提供すれば root を再計算できる（depth d なら d 個）。新 commitment が増えるたび root を更新する必要があるが、全 tree を再計算すると O(n)。インクリメンタル構造は O(log n) で root を更新（次の leaf 位置のみ）。Zcash・Tornado・Aztec すべて採用。
Aztec の "Append-only sparse tree" は深さを変えずに insertion を高速化。
オンチェーンは root だけだが、クライアントは全 tree を再構築する必要がある。Zcash で chain head までスキャンに数分かかる課題。
解: compact block / FlyClient / wallet-as-a-service。Penumbra は client-side state management に強く投資。
shielded transfer 1 件で証明する内容は以下を 1 つの SNARK にまとめる:
Statement: // 公開入力
- merkle_root (現在のツリー root)
- nullifiers[] (使用済みマークの集合)
- new_commitments[] (新規 note の commitment)
- public_value (deposit/withdraw 額)
Witness: // 秘密入力
- input_notes[] (value, pk, r, position)
- merkle_paths[] (各 input の path)
- spending_keys[] (各 input の sk)
- output_notes[] (value, pk, r)
Constraints:
① ∀ i: commitment(input_notes[i]) ∈ tree (merkle_path[i] で証明)
② ∀ i: nf_i = Hash(sk_i, c_i) (nullifier 正しい)
③ ∀ i: owner_verify(sk_i, pk_i) (所有権)
④ Σ input.value + public_in = Σ output.value + public_out + fee (balance)
⑤ ∀ j: new_c_j = Hash(out_v_j, out_pk_j, out_r_j) (output commitment 正しい)
「私は集合のどれかの所有者で、二重 spend しておらず、balance が合っており、新 commitment が正しい」すべてを 1 つの proof π で証明。検証者は π・root・nullifier 集合・new commitment 集合だけを見ればよい。
これが shielded pool の magic: 4 要素が SNARK の constraint 内で結合し、外には何も漏れない。
Shielded pool 内の note は Mint (Deposit) → Transfer → Burn (Withdraw) の 3 ステージを循環する。各ステージで「何が公開され、何が秘匿されるか」が変わる。本タブでは ZK proof の statement を含めて 3 ステージを decompose する。
外部の public ETH / USDC / Token を shielded pool に「変換」する。新しい note を作成し、その commitment を Merkle tree に追加する。
crZK proof は通常不要 (deposit 時)。理由: 公開金額・公開送信者・新 commitment だけで「資金が pool に入った」ことは public visibility で検証できる。Tornado 等の単純実装では「deposit に proof 不要、withdraw に proof 必須」。
例外: Aztec Connect / RAILGUN は shielded mint with proof をサポート。任意金額入金時に金額が hidden な note を作る場合は proof 必要。
// Tornado Cash deposit (簡略)
function deposit(bytes32 commitment) external payable {
require(msg.value == DENOMINATION);
uint32 idx = _insert(commitment); // Merkle tree に追加
emit Deposit(commitment, idx, block.timestamp);
}これが shielded pool の本命。pool 内のある note を消費し、別の note を作る。誰から誰へ・いくらか、すべて隠蔽される。
nf （消費したマーク）c_newπZK proof が証明すること (statement):
∃ (input_note, sk, merkle_path, output_note, r_out):
① commitment(input_note) ∈ tree (root) // merkle path で
② derive_pk(sk) == input_note.pk // 所有権
③ nf == Hash(sk, input_note) // nullifier 正しい
④ output_note.value == input_note.value - fee // balance
⑤ c_new == commitment(output_note) // 新 commitment外部観察者は「誰かが pool 内のどれかの note を消費し、新しい note を作った」しか分からない。anonymity set = 全 unspent note 数。
マルチ in/out 拡張: 実際の Zcash transfer は最大 2 input・2 output。RAILGUN は最大 13 input・10 output。複雑な合算・分割が 1 transaction で可能。
shielded note を消費し、対応する金額を public address に払い出す。
nf (消費マーク)πWithdraw bottleneck: nullifier + recipient 公開は deanonymization 攻撃面。timing analysis で「deposit 直後の withdraw は同一人物」と推定可能。Tornado Cash はこれを relayer + delay で緩和。
ZK proof statement:
∃ (input_note, sk, merkle_path):
① commitment(input_note) ∈ tree
② derive_pk(sk) == input_note.pk
③ nf == Hash(sk, input_note)
④ input_note.value == public_withdraw_amount + fee // 残高一致recipient は public input なので、prover はそれを受け取って proof を生成。recipient が後で変更されると proof が invalid になる（malleability 防止）。
| ステージ | 送信者匿名 | 受信者匿名 | 金額匿名 | 主リスク |
|---|---|---|---|---|
| Mint | 公開 | 秘匿 | 公開 | 誰が pool に入金したか |
| Transfer | 秘匿 | 秘匿 | 秘匿 | timing analysis のみ |
| Burn | 秘匿 | 公開 | 公開 | deanonymize の主面 |
shielded pool の匿名性 ≈ 「Mint した全ユーザー」の集合サイズ。Transfer は内部循環で set を増やさず、新規 Mint のみが set を拡大する。
そのため Mint アクティビティを高く保つことが pool 価値の源泉。Tornado Cash の denomination 固定はこれを最大化する設計。
Shielded pool のすべては Zcash の 4 世代の進化に追従している。Zerocash (2014 理論) → Sprout (2016 launch) → Sapling (2018 高速化) → Orchard (2022 trustless) の各段階で「曲線・hash・commitment scheme・proving system」が再設計され、それぞれが次世代 shielded pool 設計の base lineになった。
Zerocoin (2013) の改良。Zerocoin は anonymity だけだったが、Zerocash は 金額秘匿 も加えた。SNARK で「私は pool 内のどれかの coin を持ち、その serial number が未消費」を証明。
キーアイデア: commitment scheme + accumulator (Merkle) + zk-SNARK の組み合わせ。これ以降のすべての shielded pool が踏襲する骨格。
暗号構成: BCTV14 SNARK (Ben-Sasson, Chiesa, Tromer, Virza), Curve25519, SHA-256 commitment
限界: proving ~minutes (理論モデル)、circuit が巨大、trusted setup 必要
Zerocash 論文の最初の実装。BN128 (BN254) 曲線上で BCTV14 SNARK。
Spend description: (nullifier, anchor_root, ZK_proof)
Output description: (commitment, encrypted_note_ciphertext, ZK_proof)
Jubjub scalar: spending key sk → derive a_pk = PRF(sk)、a_sk → derive nullifier
Powers of Tau ceremony: 6 参加者の MPC で trusted setup。1 人でも誠実なら secure。
限界:
Sprout の致命的な遅さを根本解決した世代。BLS12-381 / Jubjub という ZK-friendly な曲線ペアを採用。
Note 構造:
d: diversifier (受信者 unlinkability)pk_d = [ivk]·g_d: diversified transmission keyvalue: 金額 (64 bit)rcm: commitment trapdoorρ: nullifier 入力 (initial randomness)Commitment: Pedersen cm = NoteCommit_{rcm}(g_d, pk_d, v)。準同型性活用。
Nullifier: nf = PRF^{nk}(ρ)
BLAKE2s for Sprout-compatible, Pedersen + Bowe-Hopwood for in-circuit hashing。
パフォーマンス: spend proving ~3s（CPU）、output proving ~1s。mobile wallet 実用化。
Diversified address: 1 つの spending key から無数の receiving address を派生。各 address は unlinkable。
Sapling の trusted setup を完全排除した世代。Halo2 + Pallas curve（Vesta との cycle of curves）。
Halo recursion: 再帰的 SNARK で polynomial commitment が trusted setup なしで動く。Ian Miers, Sean Bowe らの理論成果。
Action description: spend + output を 1 つにまとめた構造。balance proof は Pedersen commitment の準同型で。
Action:
- cv (value commitment)
- nf (nullifier)
- rk (randomized verification key)
- cm_new (output commitment)
- epk_new (ephemeral pubkey for encryption)
- enc_ciphertext (encrypted note)
- out_ciphertext (encrypted output to recipient)
- π (Halo2 proof)Sinsemilla hash: lookup-based、circuit 内で Pedersen より高速
限界:
Penumbra・Iron Fish 等の後続 shielded chain も Halo2 / Pallas 系を採用。
ZSA (Zcash Shielded Assets): Orchard に multi-asset support（MASP に似た拡張）。Anoma/Namada との収斂。
Crosslink: Zcash の hybrid PoW/PoS への移行案。finality 高速化。
NU6.1 (2025): dev funding 構造の調整、Orchard memo の最適化。
FROST / threshold: shielded address の threshold signature support。
| 世代 | 曲線 | SNARK | Commitment | Hash (in-circuit) | Setup | Spend proving |
|---|---|---|---|---|---|---|
| Sprout | BN128 | BCTV14 | SHA256 | SHA256 | Trusted (Powers of Tau) | ~30-60s |
| Sapling | Jubjub / BLS12-381 | Groth16 | Pedersen | Bowe-Hopwood | Trusted (Sapling MPC) | ~3s |
| Orchard | Pallas / Vesta | Halo2 | Pedersen on Pallas | Sinsemilla | Trustless (recursive) | ~5-10s |
(a) 理論的厳密性: Sasson et al. の S&P paper が peer review済み・正式 cite 可能。(b) 10 年の運用実績: Sprout/Sapling/Orchard すべて mainnet で大規模稼働。(c) open source rust crates: zcash_proofs / orchard / halo2 を直接 fork できる（Aztec / Penumbra / Iron Fish はこの spec を base に）。(d) セキュリティ研究の蓄積: Sprout の counterfeit bug 発見・修正など、攻撃耐性が経験的に検証されている。
Ethereum 上で shielded pool を実装する試みは 2019 以降ほぼ毎年生まれてきた。Tornado / Aztec Connect / Aztec 3 / RAILGUN / ZKBob / ZeroPool / Privacy Pools の 7 プロジェクトを、暗号構成・規制対応・教訓の観点から比較する。
Launch: 2019 / 暗号: Solidity + Circom + Groth16 + BN254 / Hash: MiMC (later Poseidon variants)
設計: 単純 mixer。deposit(commitment) と withdraw(nullifier, proof, recipient) のみ。同額固定 (0.1 / 1 / 10 / 100 ETH)。
// Tornado の depth=20 Merkle tree
2^20 = 1,048,576 commitments per pool
circuit: ~5879 lines of Circom
proof: Groth16, ~30s browser provingRelayer support: gas を recipient ETH 残高なしで支払えるメタトランザクション。重要 UX。
OFAC sanctions (2022-08): 米財務省が smart contract address を SDN list に追加。前例なき事態。
5th Circuit ruling (2024-11): "immutable smart contracts cannot be sanctioned" として制裁取消。法的勝利。
限界: composability 0 (DeFi 連携不可)、denomination 制限で時間ベース linkability、wallet が deposit/withdraw を別々に管理する必要
TVL ピーク: ~$7B+ cumulative deposits
暗号: PLONK + BN254 / 言語: Solidity + barretenberg / L2 rollup (zkRollup)
キー革新: DeFi bridge contracts。Aztec 内の shielded note を Lido・Element・Yearn 等の外部 DeFi プロトコルに「橋渡し」できる。Bridge は Solidity contract で、Aztec rollup が batch して呼び出す。
// Aztec Connect bridge interface
interface IDefiBridge {
function convert(
AztecTypes.AztecAsset inputAsset,
AztecTypes.AztecAsset outputAsset,
uint256 inputValue,
uint256 interactionNonce,
uint64 auxData
) external returns (uint256, uint256, bool);
}2024-03 shutdown 発表: TVL ピーク ~$250M。理由: 規制不確実性 (Tornado 制裁後) + UX (proving が browser で重い) + composability 制限。
教訓: "privacy + DeFi for retail" の市場需要は当時想定より遥かに小さい。enterprise 路線へシフト示唆。
暗号: UltraHonk + BN254 / 言語: Noir（独自 ZK DSL）
転換: Connect の bridge model を捨てて、fully private smart contracts のチェーンへ。Hawk (2016) のビジョンを 8 年遅れで本格実装。
Private kernel circuits: 5 phases (init / inner / reset / tail / verifier)。各 contract call は client-side で proof 生成、aggregator が collect。
~427k total gates: private execution の全コスト。クライアント側数十秒。
Public + Private hybrid: 1 つの transaction で private と public function を呼べる。Noir で #[private] と #[public] アノテーション。
暗号: 54 Groth16 circuits + Poseidon + BN254 / 多 chain: Ethereum / BSC / Polygon / Arbitrum mainnet
設計: 任意 ERC-20 amount の shielded transfer。最大 13 input × 10 output / transaction。54 circuit は input/output 数の組み合わせ別。
PPOI (Private Proof of Innocence) [2023]: 自分の funds が tainted (制裁 address 由来) でないことを ZK で証明する optional 機能。Buterin 提案の Privacy Pools コンセプトを RAILGUN が先行実装。
// PPOI の statement (簡略)
∀ ancestor c in commitment lineage:
c.depositor ∉ public_blocklist
→ recipient can verify "innocence" off-chainTVL: ~$50M+ / 制裁対応: PPOI で銀行 / regulator との連携可能性
暗号: ZeroPool fork (Circom 化) + Groth16 + BN254
BOB stablecoin focused: ZKBob は BOB（USD pegged stablecoin）専用の shielded pool。複数 asset を扱わないので回路が単純化。
Compliance Manager Key: pool 管理者は特定 transaction を viewing key で監査可能。"private but not anarchic" のスタンス。
Relayer network: gasless transaction。Polygon の低 gas と組み合わせて mobile UX 重視。
限界: BOB stablecoin の発行・採用が限定的 → pool 流動性も小
RAILGUN・ZKBob の 祖先。Substrate / Polkadot origin、後に Circom 化。
UTXO 回路の汎用化: arbitrary input/output count を回路で扱う設計を最初に提案。
Diversified address: Zcash Sapling のアイデアを EVM に持ち込み。1 spending key から無数の receive address。
本体は wind-down だが、技術的 DNA は ZKBob / Tornado Nova / RAILGUN に継承。
論文: Buterin, Bünz et al. "Blockchain Privacy and Regulatory Compliance" (2023)
核心アイデア: Association Set (AS)。withdraw 時に「私は AS のどれかから出ている」を証明。AS は curator が選んだ「クリーンな」commitment 集合。
// Privacy Pools の statement
∃ note ∈ Anonymity Set: // 通常 shielded pool
∧ note ∈ Association Set: // NEW: 規制対応
∧ nullifier 正しい
∧ balance OKDerecho (2024): Privacy Pools 理論基盤の formal 化。AS 設計の properties (soundness/completeness/anonymity-vs-compliance trade-off)。
0xbow Mainnet (2025-03): 初の production deployment。AS は 0xbow が curate、tainted commitment を排除。
意義: 规制 friendly な mixer という従来矛盾していた 2 つを ZK で和解する初の試み。Tornado 制裁後の業界正解候補。
| 実装 | 規制対応機構 | 監査可能性 | 状態 |
|---|---|---|---|
| Tornado Cash | None (pure mixer) | None | Sanctioned → vacated |
| Aztec Connect | None | Viewing key (個別) | Shutdown 2024 |
| Aztec 3 | TBD (Noir で programmable) | Per-contract | Testnet |
| RAILGUN | PPOI (private innocence) | Optional disclosure | Production |
| ZKBob | Compliance Manager Key | Pool operator が viewing | Production |
| Privacy Pools | Association Set curation | AS exclusion で blocklist | Production 2025 |
Vanilla shielded pool は単一資産前提だが、DeFi に持ち込むには multi-asset と AMM 相当の swap が必要になる。MASP (Anoma) / Penumbra zswap / Manta / Aleo の 4 アプローチを数式で比較する。
Zcash / Tornado / RAILGUN(原型) はすべて 1 asset = 1 pool。USDC pool と DAI pool が独立し、interaction できない。
DeFi の本質は資産間 swap。AMM / lending / derivatives はすべて multi-asset を前提とする。shielded pool で DeFi をやるには、pool 内に複数 asset を共存させる仕組みが必要。
もっとも素直な拡張: commitment に asset_type field を追加。balance 制約も asset 別に分離する。
// MASP の transfer constraint (簡略)
circuit MASP_Transfer {
// Inputs (public)
merkle_root, nf[], c_new[]
asset_in[], asset_out[] // asset type per note
// Witnesses (private)
notes_in[], sk[], paths[]
notes_out[]
// Constraints
∀ i: c_i = H(value_i, asset_in[i], pk_i, r_i)
∀ i: c_i ∈ tree (via path_i)
∀ i: nf_i = H(sk_i, c_i)
∀ j: c_new_j = H(value_out_j, asset_out[j], pk_out_j, r_out_j)
∀ asset a:
Σ value_i [asset_in[i] == a] == Σ value_out_j [asset_out[j] == a] + fee(a)
}Penumbra は Cosmos chain で shielded pool + AMM を提供。AMM 部分が zswap。標準 CFMM (x·y=k) ではなく batch clearing で価格を決定する。
// zswap の 4 stage flow
Stage 1 (private): User が input note を burn し、swap intent を submit
intent = (asset_in, value_in, asset_out, claim_address)
→ swap NFT が mint される (transient)
Stage 2 (public): Validator が同一 block の全 intent を集約
All intents in epoch e for (asset_in → asset_out) アグリゲート
Stage 3 (public): Batch clearing price 決定
price_e = f(aggregated_inflow, aggregated_outflow, liquidity_positions)
→ 全 intent が同じ price で約定
Stage 4 (private): User が claim
swap NFT を burn し、output note を mint
output_note = (asset_out, value_out = price_e · value_in)(a) Individual intent は隠蔽: 自分が swap したことすら他 user から不可視。
(b) Batch clearing: 同一 epoch の全 trade が同一 price で約定 → MEV 完全排除（front-running 不可能）。
(c) Liquidity positions: LP も shielded で position を持てる（concentrated liquidity 風）。
Epoch latency: instant swap 不可、epoch (数秒〜数十秒) 待つ必要。
Aggregate volume leak: batch ごとの total volume・price は public。長期的に統計的攻撃の余地。
採用状況: 2024 mainnet 稼働開始だが liquidity・user base は限定的。Cosmos エコシステム内に閉じる。
原型: Substrate (Polkadot parachain) + Groth16。Zcash Sapling 的な shielded asset を Polkadot エコシステムに持ち込む試み。
MantaPay: shielded transfer 機能。USD/ETH/DOT 等の wrapped asset を shield。
2024 Pivot: pure shielded pool の market fit を達成できず、ZK Compression / Manta Pacific (general purpose ZK L2) に転換。shielded pool は legacy 化。
教訓: shielded だけでは流動性が集まらない。"why shield" の use case が決定的に重要。
暗号: Sapling fork (Rust, Jubjub/BLS12-381) / 独自 chain (Bitcoin 互換 PoW)
Multi-asset: 任意 asset を発行可能、各 asset が shielded 扱い。MASP より単純（asset type を note に含めるだけ、cross-asset balance はそのまま）。
Bridge to Ethereum: 双方向 bridge で WBTC・USDC 等を shielded で扱える。
差別化: Zcash の technical 系譜を尊重しつつ multi-asset + ergonomic wallet で retail 向け。Coinbase 等 listing も。
暗号: Marlin SNARK + 独自曲線 / 言語: Leo (Rust-like DSL for private SC)
Records: Aleo の note 相当。任意 struct を private に保存可能（Zcash の note を一般化）。
客観的には Aztec 3 の競合。Aztec が Noir なら、Aleo は Leo。両方とも general private smart contract platform 目指す。
限界: 2023 mainnet 後、user / 開発者の絶対数は限定的。Cosmos の Penumbra 同様、ニッチ内のリーダー。
| アプローチ | Multi-Asset | Swap 機能 | MEV 耐性 | Production |
|---|---|---|---|---|
| MASP / Namada | Yes (in commitment) | Convert (limited) | 部分的 | 2024 mainnet |
| Penumbra zswap | Yes (multi-pool) | Batch clearing | 完全 | 2024 mainnet |
| Manta | Yes (wrapped) | 外部 DEX 経由 | なし | Pivot 済 |
| Iron Fish | Yes (任意 asset) | なし (transfer のみ) | N/A | 2023 mainnet |
| Aleo | Yes (records) | Programmable | 未定 | 2023 mainnet |
Penumbra (batch clearing) と Namada (MASP) が現時点の最も洗練された設計。だが両者とも独自 chain で、Ethereum L1 への return は未解決問題。Aztec 3 の private contracts が EVM-compatible でこの gap を埋められるかが 2025-2026 の watch point。
これまで議論した実装を 1 つの表に集約。曲線・証明系・asset 性質・production status・規制対応の 8 軸で 15 実装を並べる。続いて anonymity set vs composability の散布図で全体地図を描く。
| 実装 | 言語 | 証明系 | 曲線 | UTXO/Acc | Multi-Asset | 本番化 | 規制対応 |
|---|---|---|---|---|---|---|---|
| Zcash Sprout | C++ | BCTV14 | BN254 | UTXO | No (ZEC) | 2016 | None |
| Zcash Sapling | Rust | Groth16 | Jubjub/BLS12-381 | UTXO | No (ZEC) | 2018 | Selective disclosure |
| Zcash Orchard | Rust | Halo2 | Pallas/Vesta | UTXO | No (ZSA pending) | 2022 | Selective disclosure |
| Tornado Cash | Solidity+Circom | Groth16 | BN254 | UTXO | No (固定額) | 2019 | Sanctioned |
| Aztec Connect | TypeScript+barret | PLONK | BN254 | UTXO | Yes | 2021-24 | Shutdown |
| Aztec 3 | Noir+Rust | UltraHonk | BN254 | UTXO+SC | Yes | 準備中 | Programmable |
| RAILGUN | Solidity+Circom | Groth16 | BN254 | UTXO | Yes (ERC-20) | 2022 | PPOI |
| ZKBob | Solidity+Circom | Groth16 | BN254 | UTXO | No (BOB) | 2022 | CMK viewing |
| ZeroPool | Substrate→Circom | Groth16 | BN254 | UTXO | Limited | 2020 | None |
| Manta | Substrate | Groth16 | BLS12-381 | UTXO | Yes (wrapped) | 2021→pivot | None |
| Iron Fish | Rust | Sapling-fork | Jubjub/BLS12-381 | UTXO | Yes (任意) | 2023 | None |
| Penumbra | Rust | Groth16 | decaf377 | UTXO | Yes (zswap) | 2024 | None |
| MASP / Namada | Rust | Groth16 | BLS12-381 | UTXO | Yes (full) | 2024 | Compliance keys |
| Privacy Pools (0xbow) | Solidity+Circom | Groth16 | BN254 | UTXO | No | 2025-03 | Association Set |
| Aleo | Rust+Leo | Marlin | BLS12-377 | Records (UTXO+) | Yes | 2023 | Programmable |
Tornado / RAILGUN / ZKBob / Privacy Pools すべて BN254 + Groth16。理由: Ethereum precompile (0x06/07/08) で pairing 検証が安価 (~80k gas)。proof 192B 固定。
Zcash Orchard が pioneer、Penumbra・Iron Fish 等が継承。trusted setup 不要が最大利点だが、verifier が EVM precompile に乗らないので EVM 直接デプロイは難しい（rollup or Cosmos chain 経由が現実解）。
10 年の実装進化にもかかわらず、shielded pool は 普及・規制・性能の 3 軸で大きな壁を抱える。各課題に「なぜ難しいか / 既存試み / 研究機会」を付ける。
shielded pool の匿名性は set サイズの log に比例する。各 chain・各 asset・各 implementation ごとに独立 pool を立てると、set が小さく分割され、effective anonymity が大幅に劣化する。
なぜ難しいかchain 間の commitment / nullifier 整合性を保つには cross-chain ZK bridge が必要。bridge 自身が trust point になるか、計算コストが膨大になる。
既存試みCross-chain shielded pool: 複数 chain の commitment が同じ Merkle tree に乗る設計。recursive ZK + bridge proof で技術的には可能だが production 例なし。
Aztec Connect TVL ピーク ~$250M で 2024-03 shutdown。Penumbra mainnet も流動性は限定的。「privacy + DeFi」の retail 需要は当時の見立てより遥かに小さいのが 2024 時点の現実。
なぜ難しいか(a) ガス高い (Mainnet で proof verify ~300k+ gas)、(b) UX 複雑 (proving 数十秒、wallet sync 数分)、(c) 「shield する理由」を retail user が持たない、(d) shielded asset は CEX 入金できない。
既存試みShielded UX 改善: client-side proving の高速化 (recursive ZK)、social recovery for shielded address、shielded → public CEX bridge。B2B 路線: payroll・treasury・OTC 向けの enterprise shielded pool。
Groth16 proof generation は circuit 規模に応じ 5-30 秒。Mobile wallet では Browser WASM 制約 + memory 制約で 数分 かかる場合も。これが UX を壊す主因。
なぜ難しいかshielded transfer は constraint 数 ~100k-500k。これを browser で多項式展開・MSM・FFT する。GPU 加速も browser/mobile では限定的。
既存試みWebGPU 活用 / WASM SIMD 最適化 / mobile dedicated proving SDK / TEE-assisted proving (proof gen を SGX に委譲、user の secret は seal)
Mint と Burn は public side が露出する。特に Burn (withdraw) は recipient + amount が公開されるため、timing analysis 攻撃で「直前 deposit と同一人物」と推定される。
なぜ難しいかshielded pool は internal transfer のみ匿名。external interaction が必須なので、必ずどこかで「公開境界」が生じる。
既存試みForced delay shielded pool: smart contract レベルで withdraw を最低 N 時間遅延。Batched withdraw: 同一 epoch 内の全 withdraw を集約して order を decorrelate。
Groth16 は circuit-specific な trusted setup が必要。Powers of Tau ceremony で「1 人でも誠実なら secure」とはいえ、心理的・規制的なハードルが残る。
既存解Halo2/STARK の EVM verify cost。現状 BN254 precompile に乗らないので production EVM デプロイで Groth16 が依然支配的。Layer-2 や custom precompile (RISC-V upgrade) で改善余地。
2022 OFAC Tornado 制裁、2024 Aztec Connect shutdown。EU MiCA・米 FATF Travel Rule・UK FCA 等、「無条件 anonymity」へのプレッシャーが継続強化されている。
なぜ難しいか規制要求 (KYC, audit trail, sanctions screening) と shielded pool の core property (unlinkability, hidden balances) が原理的に対立する。
既存試み (compliance-friendly shielded)規制対応の標準化: AS curation の governance、blocklist の cross-implementation 共有、travel rule との整合 (FATF), CBDC との接続。長期的な勝者はおそらく「規制対応 mode と pure mode を切替可能な dual shielded pool」。
(A) 規制 friendly 派の優勢: Privacy Pools / RAILGUN PPOI 系が business adoption。Tornado-like pure mixer は legacy 化。
(B) Native shielded chain 路線: Penumbra / Namada / Iron Fish が独自 ecosystem 内で完結。Ethereum L1 との bridge は限定的。
(C) Aztec 3 / private SC platform: shielded pool を超えた "private smart contracts" として再起動。retail よりも enterprise (DeFi protocol、treasury) 向け。
2026 時点で最も賭けられるのは (A) と (C) の組合せ。pure shielded pool (B) は地政学的・経済的逆風が大きい。
Shielded pool の理論・実装・応用に関する 20 論文を 4 カテゴリで整理。各カードは title・著者・会議・要点・暗号構成・限界・後継への影響を含む。クリックで詳細展開。
Shielded pool の理論基盤。commitment + accumulator + zk-SNARK で「金額秘匿付き匿名送金」を実現。後の全 shielded pool の祖先。
BCTV14 SNARK on Curve25519, SHA-256 commitment, JoinSplit primitive
限界理論モデル。実装側で proving 数分、circuit が巨大。
後継への影響Zcash Sprout / Sapling / Orchard、Tornado、Aztec、RAILGUN すべての base。
Sprout の致命的遅さを解決。BLS12-381/Jubjub で proving 数秒へ。Pedersen commitment + Bowe-Hopwood hash。
Groth16 + BLS12-381 / Jubjub, Pedersen commitment, BLAKE2s for Sprout-compat
限界Sapling MPC ceremony (trusted setup) が依然必要。
後継への影響Iron Fish が直接 fork。Aztec / RAILGUN が note 構造を踏襲。
Trusted setup を完全排除。Halo2 + Pallas/Vesta cycle of curves。Sinsemilla hash で in-circuit hashing 高速化。
Halo2 PLONKish + Pallas/Vesta + Sinsemilla hash
限界EVM precompile に乗らない。verify cost が pairing なしで重い。
後継への影響Penumbra・Aleo 等が Halo2 系を採用。Orchard = trustless shielded の standard。
EVM 上 shielded pool の最初の成功例。同額固定 + Circom + Groth16。$7B+ cumulative deposit。
Solidity + Circom Groth16 + BN254 + MiMC, depth-20 Merkle tree
限界Composability 0、固定 denomination の linkability、wallet UX 課題
後継への影響RAILGUN・ZKBob・Privacy Pools が UX 反省点を踏襲。2022 OFAC 制裁 → 2024 court 取消。
Bridge contract で外部 DeFi protocol と shielded pool を連携する初の本格実装。Lido / Element / Yearn 統合。
PLONK + BN254, L2 zkRollup, barretenberg backend
限界2024-03 shutdown。TVL ピーク $250M、規制不確実 + UX 重さで持続不可。
後継への影響Aztec 3 (private SC) への pivot のきっかけ。"shielded + DeFi retail" 市場の小ささを実証。
Connect の bridge model を捨て、Hawk 型の fully private smart contracts へ。Noir DSL + UltraHonk + private kernel circuits。
UltraHonk + BN254, Noir compiler, 5-phase private kernel (init/inner/reset/tail/verifier)
限界~427k total gates の重さ、testnet 段階、ecosystem 構築中
後継への影響未来形。2025-26 mainnet で評価。
任意 ERC-20 amount の shielded pool。54 Groth16 circuits で input/output の組合せ対応。PPOI で innocence 証明。
Solidity + Circom Groth16 + Poseidon + BN254, multi-chain (ETH/BSC/Polygon/Arbitrum)
限界複雑な circuit 数、cross-chain pool 独立、流動性まだ限定的
後継への影響PPOI が Buterin の Privacy Pools と並ぶ規制対応標準候補に。
BOB stablecoin focused shielded pool。Polygon mainnet。Compliance Manager Key で operator viewing 機能。
Circom Groth16 + BN254, ZeroPool fork, relayer network
限界BOB stablecoin 自体の adoption が低く pool 流動性も限定
後継への影響Compliance Manager Key 設計が「監査可能 mixer」モデルとして参照される。
Polkadot parachain で shielded transfer。MantaPay で USD/ETH/DOT wrapped を shield。後に ZK Compression へ pivot。
Substrate + Groth16 + BLS12-381
限界市場 fit 不足で 2024 にメイン製品を ZK rollup 一般 (Manta Pacific) にシフト
後継への影響Pure shielded pool での retail 採用の難しさを実証。
Sapling 直接 fork に multi-asset 拡張。独自 chain (PoW)。Coinbase listing。Bitcoin 互換 wallet UX 重視。
Rust + Sapling-style Groth16 + Jubjub/BLS12-381, custom asset issuance
限界独自 chain ゆえ DeFi 流動性は薄い、Bridge 依存
後継への影響Sapling spec を multi-asset に拡張する素直なパスを示す。
Cosmos chain で shielded transfer + zswap (batch clearing DEX)。Individual intent 隠蔽 + MEV 完全排除。
Groth16 + decaf377, IBC interoperability, custom Sapling-style notes
限界Epoch latency、Cosmos エコシステムに閉じる、aggregate volume leak
後継への影響Batch clearing が MEV-resistant DEX の reference design に。
commitment に asset_type を加え、balance 制約を asset 別に分離。Namada chain で 2024 mainnet。
Sapling-style + asset_type field, Groth16 + BLS12-381
限界Convert ロジック (asset 間変換) は別途。低 liquidity asset の anonymity 弱い。
後継への影響Multi-asset shielded のreference 設計。Iron Fish もこの線。
Association Set (AS) で shielded pool に規制対応を追加。withdraw 時に AS 内 commitment 由来を証明。
Solidity + Circom + Groth16 + BN254, double-Merkle (anonymity set + association set)
限界AS curator の信頼問題、tainted vs clean の境界判定
後継への影響2025-03 0xbow が初の production 化。Tornado 後の業界正解候補。
Privacy Pools の理論基盤を formal 化。AS 設計の soundness/completeness/anonymity-vs-compliance trade-off を証明。
Set membership proof, range proof, ZK-SNARK
限界理論モデル中心、production deployment は別実装に依存
後継への影響Privacy Pools v2 / 0xbow の理論裏付けに。
Records (Zcash note の一般化) で任意 struct を shielded で扱う。Leo DSL で private SC 開発。
Marlin SNARK + BLS12-377, Edwards-BLS12 for in-circuit, snarkOS runtime
限界User / 開発者の絶対数は限定。Cosmos の Penumbra 同様、ニッチ内のリーダー。
後継への影響Aztec 3 と並ぶ private SC platform の二大勢力。
Account-based shielded pool。account の updatable anonymity set。Zether の前駆。
UC framework, ElGamal-like commitments, Σ-protocols
限界Production 実装少ない、UTXO 系に主流が流れた
後継への影響Anonymous Zether の理論先駆。Account 派の代表。
Zether (2019) の anonymity 拡張。N-out-of anonymity set を ring proof で実現。account-based shielded の代表。
ElGamal AHE, Σ-Bullets, Sigma proofs over BN254
限界Anonymity set サイズで proof cost 線形、epoch / front-running 課題
後継への影響Account 派の理論ピーク。実装 adoption は UTXO 派に劣後。
Tornado 系 mixer の改良。anonymity set を時間で更新する設計。
SNARK-based, sliding-window anonymity set
限界Production 実装は limited
後継への影響Anonymity set の時間管理に関する重要な参照点。
DPC (Decentralized Private Computation) framework。Records + birth/death predicate で general private SC。
Marlin SNARK + BLS12-377 / Edwards-BLS12 cycle
限界Proof aggregation overhead, complex constraints
後継への影響Aleo / VeriZexe / Aztec 3 の records モデル前駆。
RAILGUN・ZKBob の祖先。任意 input/output count を扱う UTXO 回路の汎用化を初めて提案。
Substrate origin → Circom Groth16 + BN254, Diversified address
限界本体は wind-down、技術的 DNA のみ継承
後継への影響RAILGUN・ZKBob・Tornado Nova の base。