title: "以太坊隱私技術與合規框架完整指南：Privacy Pools 實作深度解析 2026"

summary: "Privacy Pools 是區塊鏈隱私領域的革命性突破，透過零知識證明實現「選擇性披露」機制，讓用戶在保護交易隱私的同時能滿足監管合規需求。本文深入探討 Privacy Pools 的密碼學原理、承諾機制、關聯性證明、AML/KYC 合規框架，以及在 Tornado Cash、Aztec、Railgun 等主流協議中的實際実装。我們提供完整的 Solidity 智慧合約範例、Circom 電路代碼，以及針對不同司法管轄區的合規策略建議。"

tags:

• "privacy-pools"
• "zero-knowledge"
• "zk-snark"
• "compliance"
• "aml"
• "kyc"
• "tornado-cash"
• "aztec"
• "railgun"
• "merkle-tree"
• "commitment-scheme"

category: "privacy"

difficulty: "advanced"

date: "2026-03-30"

parent: null

status: "published"

disclaimer: "本網站內容僅供教育與資訊目的，不構成任何法律或投資建議。隱私技術涉及複雜的監管考量，在實際應用前請諮詢專業法律意見。"

datacutoffdate: "2026-03-30"

semantic_relations:

• "zero-knowledge-proofs"
• "zk-snark"
• "circom"
• "merkle-proof"
• "commitment-scheme"
• "amana"
• "tornado-cash"
• "aztec-network"
• "railgun"
• "compliance-framework"
• "aml-kyc"
• "smart-contract"

references:

• title: "Buterin, V. (2023). Privacy Pools 原始提案"

url: "https://ethresear.ch/t/privacy-pools-solution-for-privacy-and-regulatory-compliance/13818"

desc: "Vitalik Buterin 在 Ethereum Research 論壇發表的 Privacy Pools 原始論文"

• title: "Privacy Pools Protocol Specification"

url: "https://github.com/privacy-pools/privacy-pools-protocol"

desc: "Privacy Pools 官方協議規範與參考實現"

• title: "Aztec Network Documentation"

url: "https://docs.aztec.network/"

desc: "Aztec Network 隱私 Rollup 官方文檔，包含 zk.money 實現"

• title: "Railgun Protocol"

url: "https://railgun.org/"

desc: "Railgun 隱私協議官方網站"

• title: "FATF Travel Rule"

url: "https://www.fatf-gafi.org/publications/fatfgeneral/documents/FATF%20Recommendations.html"

desc: "FATF 旅行規則與虛擬資產服務提供商監管指引"

• title: "EU MiCA Regulation"

url: "https://finance.ec.europa.eu/capital-markets-union-and-financial-markets/company-reporting-and-auditing/capital-markets-union en-for-crypto-assets-investor-protection_en"

desc: "歐盟加密資產市場監管框架（MiCA）"

• title: "Chainalysis 2026 Crypto Crime Report"

url: "https://www.chainalysis.com/"

desc: "區塊鏈分析公司發布的加密貨幣犯罪趨勢報告"

以太坊隱私技術與合規框架完整指南：Privacy Pools 實作深度解析 2026

說實話區塊鏈隱私這個話題我本來不太想碰的。太敏感了，你懂的。Tornado Cash 被制裁的新聞出來的時候，整個圈子都炸了。

但後來仔細想了想，隱私這事兒還真不能完全放棄。試想一下，你願意讓全世界看到你的銀行帳單嗎？當然不願意。那為什麼加密貨幣用戶就應該被迫公開所有的交易記錄呢？

所以當我看到 Vitalik 在 2023 年提出 Privacy Pools 概念的時候，眼睛真的亮了。這個設計太聰明瞭——它不是那種「完全匿名愛咋咋地」的方案，而是試圖在隱私和合規之間找個平衡點。

截至 2026 年第一季度，Privacy Pools 類似的設計已經被多個主流隱私協議採用，總處理的隱私交易量超過 180 億美元（數據來源： Dune Analytics，截止 2026-03-30）。這個數字證明了市場確實有需求——用戶想要隱私，但也願意在合理的範圍內滿足監管要求。

區塊鏈隱私的根本矛盾

在深入 Privacy Pools 之前，得先把問題說清楚。

區塊鏈的核心特性——透明性與可追溯性——本來是為了建立信任。但如果走到另一個極端，變成「所有人的所有交易都是完全透明的」，那用戶隱私就完全沒了。

現有的隱私保護方案各有各的問題：

混幣器（如 Tornado Cash）

• 原理是把多筆存款混合在一起，讓外界無法追蹤資金流向
• 問題是被犯罪分子大量使用，導致 2022 年被美國 OFAC 制裁
• 制裁後連正常使用者的資金都被凍結的風險

隱私幣（如 Monero、Zcash）

• 使用先進的密碼學技術（環簽名、零知識證明）保護隱私
• 問題是與以太坊生態不相容，無法直接參與 DeFi
• Zcash 的 optiona transparency 也讓監管機構有話說

零知識證明

• 可以驗證某個陳述為真而不透露具體訊息
• 問題是計算成本高，實現複雜度也高

Privacy Pools 的創新在於，它不走極端。它允許用戶選擇性地向監管機構證明「我的資金來源是合法的」，而無需透露具體的存款記錄。

承諾機制：看不見的存款證明

承諾的基本概念

在密碼學中，「承諾」（Commitment）是一種可以「鎖定」一個值但不會透露其內容的機制，同時之後可以「打開」來證明這個值。

數學定義：

$$C = \text{Commit}(x; r) = H(x || r)$$

其中：

• $x$ 是秘密值（例如存款金額和存款地址）
• $r$ 是隨機盲因子（randomness）
• $H$ 是密碼學哈希函數（如 keccak256）
• $C$ 是承諾值

承諾的兩個核心性質：

1. 隱藏性（Hiding）：從承諾 $C$ 無法推導出 $x$ 的任何訊息
2. 綁定性（Binding）：無法找到兩個不同的 $(x, r)$ 和 $(x', r')$ 使得 $\text{Commit}(x, r) = \text{Commit}(x', r')$

# 承諾機制的 Python 實現
import hashlib
from typing import Tuple

def pedersen_commitment(value: int, randomness: bytes) -> int:
    """
    Pedersen 承諾方案
    
    C = g^value * h^randomness
    
    其中 g 和 h 是群生成元
    
    在 BN254 曲線上：
    - g = 1（橢圓曲線上的基點）
    - h 需要額外選擇（通常使用 another generator）
    """
    from constants import G, H, FIELD_ORDER
    
    # 計算 g^value
    g_power = pow(G[0], value, FIELD_ORDER)
    
    # 計算 h^randomness
    h_power = pow(H[0], int.from_bytes(randomness, 'big'), FIELD_ORDER)
    
    # 乘法（群操作）
    commitment = (g_power * h_power) % FIELD_ORDER
    
    return commitment

def create_deposit_commitment(
    secret: bytes,
    nullifier: bytes,
    deposit_amount: int
) -> Tuple[int, bytes]:
    """
    創建存款承諾
    
    存款時，用戶需要：
    1. 生成一個秘密 secret（用於計算提款密鑰）
    2. 生成一個 nullifier（用於識別這筆存款，防止雙花）
    3. 計算承諾 C = Commit(secret || nullifier || amount)
    
    Returns:
        commitment: 承諾值
        nullifier_hash: 空符哈希（用於後續識別）
    """
    import secrets
    
    # 生成盲因子
    blinding = secrets.token_bytes(32)
    
    # 計算空符哈希（用於提款時識別存款）
    nullifier_hash = int.from_bytes(
        hashlib.sha256(nullifier).digest(),
        'big'
    ) % FIELD_ORDER
    
    # 組合輸入
    input_data = secret + nullifier + deposit_amount.to_bytes(32, 'big') + blinding
    
    # 計算承諾
    commitment = int.from_bytes(
        hashlib.sha256(input_data).digest(),
        'big'
    ) % FIELD_ORDER
    
    return commitment, nullifier_hash, blinding

def verify_commitment_structure(commitment: int) -> bool:
    """
    驗證承諾是否在有效範圍內
    
    在 BN254 中，有效承諾需要滿足：
    - 0 < commitment < FIELD_ORDER
    - commitment != 0（零承諾是無效的）
    """
    from constants import FIELD_ORDER
    
    return 0 < commitment < FIELD_ORDER

Merkle 樹：組織承諾的結構

當系統中有多筆存款時，需要一種方式來組織和驗證這些承諾。Merkle 樹就是這個任務的理想工具。

# Merkle 樹實現
import hashlib
from typing import List, Optional
from dataclasses import dataclass

@dataclass
class MerkleNode:
    value: int  # 節點的哈希值
    left: Optional['MerkleNode'] = None
    right: Optional['MerkleNode'] = None
    is_leaf: bool = False

class MerkleTree:
    """
    Merkle 樹用於組織所有存款承諾
    
    結構：
                    Root
                   /    \
                H(0,1)  H(2,3)
               /    \   /    \
             H(0)  H(1) H(2)  H(3)
             /      \   /      \
           C_0      C_1  C_2    C_3  (承諾值)
    """
    
    def __init__(self, depth: int = 20):
        self.depth = depth
        self.leaves: List[int] = []
        self.nodes: List[List[int]] = [[] for _ in range(depth + 1)]
    
    def insert(self, commitment: int) -> int:
        """插入新承諾，返回葉子節點索引"""
        leaf_index = len(self.leaves)
        self.leaves.append(commitment)
        self.nodes[0].append(commitment)
        
        # 向上更新父節點
        current_index = leaf_index
        for level in range(self.depth):
            if current_index % 2 == 0:
                # 左節點，等待兄弟節點
                pass
            else:
                # 右節點，可以計算父節點
                left_idx = current_index - 1
                right_idx = current_index
                
                if left_idx < len(self.nodes[level]):
                    left_val = self.nodes[level][left_idx]
                    right_val = self.nodes[level][right_idx]
                    
                    parent_hash = self._hash_pair(left_val, right_val)
                    self.nodes[level + 1].append(parent_hash)
            
            current_index = current_index // 2
        
        return leaf_index
    
    def _hash_pair(self, left: int, right: int) -> int:
        """計算一對節點的父節點哈希"""
        # 確保順序一致（小值在前）
        if left > right:
            left, right = right, left
        
        data = left.to_bytes(32, 'big') + right.to_bytes(32, 'big')
        return int.from_bytes(
            hashlib.sha256(data).digest(),
            'big'
        ) % FIELD_ORDER
    
    def get_root(self) -> int:
        """獲取 Merkle 根"""
        if not self.nodes[self.depth]:
            return 0
        return self.nodes[self.depth][0]
    
    def generate_proof(self, leaf_index: int) -> List[Tuple[int, bool]]:
        """
        生成 Merkle 證明
        
        證明格式：[ (sibling_hash, is_left), ... ]
        """
        proof = []
        current_idx = leaf_index
        
        for level in range(self.depth):
            sibling_idx = current_idx + 1 if current_idx % 2 == 0 else current_idx - 1
            is_left = current_idx % 2 == 1
            
            if sibling_idx < len(self.nodes[level]):
                proof.append((self.nodes[level][sibling_idx], is_left))
            else:
                # 如果沒有兄弟節點，使用 0
                proof.append((0, is_left))
            
            current_idx = current_idx // 2
        
        return proof
    
    def verify_proof(
        self,
        leaf_value: int,
        leaf_index: int,
        proof: List[Tuple[int, bool]],
        root: int
    ) -> bool:
        """驗證 Merkle 證明"""
        current = leaf_value
        
        for sibling, is_left in proof:
            if is_left:
                # 兄弟節點在左邊
                current = self._hash_pair(sibling, current)
            else:
                # 兄弟節點在右邊
                current = self._hash_pair(current, sibling)
        
        return current == root

關聯性證明：Privacy Pools 的核心

終於到重頭戲了。關聯性證明（Association Proof）是 Privacy Pools 的核心創新。

問題定義

假設 Alice 存了 1 ETH 到 Privacy Pool，過了一段時間後想取出。傳統匿名池的問題是：

• Alice 無法向監管機構證明這 1 ETH 不是來自暗網市場
• 監管機構也無法區分「乾淨的」和「骯髒的」資金

Privacy Pools 的解決方案是：允許用戶選擇一個「合規關聯集」（Compliance Association Set），並證明自己的存款屬於這個集合。

集合成員證明

數學上，設：

• $\mathcal{U}$ 是所有存款承諾組成的集合（Universe）
• $\mathcal{C} \subseteq \mathcal{U}$ 是「乾淨的」子集（Compliant Set）
• $\mathcal{N} = \mathcal{U} \setminus \mathcal{C}$ 是「非乾淨的」子集

用戶想要證明：自己的承諾 $c \in \mathcal{C}$

傳統的 Merkle 證明只能證明 $c \in \mathcal{U}$，無法區分子集。

承諾函數的設計

Privacy Pools 使用承諾函數來建立這種關聯：

$$Ci = \text{Commit}(mi, r_i)$$

其中 $mi$ 是存款訊息，$ri$ 是盲因子。

定義兩個 Merkle 根：

• $R_{all}$：包含所有存款承諾的 Merkle 樹根
• $R_{clean}$：只包含「乾淨」存款承諾的 Merkle 樹根

用戶需要證明：

1. 自己的承諾 $C$ 存在於 $R_{all}$ 中
2. 自己的承諾 $C$ 不存在於 $R_{clean}$ 的補集中

等等，這樣不對⋯⋯讓我重新想一下。

實際的設計是這樣的：

• 用戶持有一個存款承諾 $C$
• 系統有兩個（或多個）Merkle 樹
• $M_1$ 包含所有存款
• $M_2$ 只包含「已驗證為乾淨」的存款
• 用戶可以選擇在提款時使用哪個 Merkle 根的證明

如果用戶選擇使用 $M_2$ 的證明，監管機構就能確認這筆錢來自「乾淨」的存款。

# 關聯性證明的簡化實現
class AssociationProof:
    """
    關聯性證明允許用戶證明其存款屬於某個特定集合
    
    核心思想：
    1. 存款時，承諾被插入到 Merkle 樹中
    2. 提款時，用戶可以選擇證明集合
    3. 零知識證明確保用戶只知道自己的承諾
    """
    
    def __init__(self, merkle_trees: Dict[str, MerkleTree]):
        self.merkle_trees = merkle_trees  # 多棵 Merkle 樹
    
    def generate_proof(
        self,
        commitment: int,
        association_set: str = "all"  # "all" 或 "clean"
    ) -> Dict:
        """
        生成關聯性證明
        
        Args:
            commitment: 用戶的存款承諾
            association_set: 要證明的關聯集
            
        Returns:
            包含以下內容的字典：
            - merkle_root: 使用的 Merkle 根
            - merkle_proof: Merkle 證明
            - commitment: 存款承諾
        """
        merkle_tree = self.merkle_trees.get(association_set)
        if merkle_tree is None:
            raise ValueError(f"Unknown association set: {association_set}")
        
        # 找到承諾在樹中的位置
        leaf_index = None
        for idx, leaf in enumerate(merkle_tree.leaves):
            if leaf == commitment:
                leaf_index = idx
                break
        
        if leaf_index is None:
            # 承諾不在這個集合中
            return {
                'valid': False,
                'reason': 'Commitment not found in association set'
            }
        
        # 生成 Merkle 證明
        proof = merkle_tree.generate_proof(leaf_index)
        root = merkle_tree.get_root()
        
        return {
            'valid': True,
            'merkle_root': root,
            'merkle_proof': proof,
            'commitment': commitment,
            'leaf_index': leaf_index,
            'association_set': association_set
        }
    
    def verify_proof(
        self,
        proof_data: Dict,
        expected_root: int
    ) -> bool:
        """驗證關聯性證明"""
        if not proof_data['valid']:
            return False
        
        return MerkleTree.verify_proof(
            proof_data['commitment'],
            proof_data['leaf_index'],
            proof_data['merkle_proof'],
            expected_root
        )

零知識電路：Circom 實作

讓我上點實際的電路代碼，展示如何在 Circom 中實現 Privacy Pools 的核心邏輯。

存款電路

// deposit.circom
// 存款電路：生成存款承諾

pragma circom 2.0.0;

include "../circomlib/circuits/poseidon.circom";
include "../circomlib/circuits/bitify.circom";

template Deposit() {
    // 公開輸入：承諾值（將存入合約）
    signal input commitment;
    
    // 私密輸入：用於計算承諾的秘密值
    signal private input nullifier;
    signal private input secret;
    signal private input blinding;
    
    // 計算承諾
    // commitment = hash(nullifier || secret || blinding)
    component hasher = Poseidon(3);
    hasher.inputs[0] <== nullifier;
    hasher.inputs[1] <== secret;
    hasher.inputs[2] <== blinding;
    
    // 約束：計算出的承諾必須等於公開輸入
    commitment === hasher.out;
    
    // 輸出空符哈希（用於後續識別存款）
    component nullifierHasher = Poseidon(1);
    nullifierHasher.inputs[0] <== nullifier;
    
    // 這裡可以添加輸出信號用於追蹤
    // 但核心存款電路只需要承諾本身
}

component main {public [commitment]} = Deposit();

提款電路

// withdraw.circom
// 提款電路：驗證存款並生成零知識證明

pragma circom 2.0.0;

include "../circomlib/circuits/poseidon.circom";
include "../circomlib/circuits/merkleproof.circom";

template Withdraw(levels, nCommitments) {
    // 公開輸入
    signal input root;
    signal input nullifierHash;
    signal input recipient;        // 接收者地址
    signal input relayer;          // 中繼者地址（可選）
    signal input fee;              // 手續費
    signal input refund;           // 退款金額
    
    // 私密輸入
    signal private input nullifier;
    signal private input secret;
    signal private input blinding;
    signal private input pathElements[levels];
    signal private input pathIndices[levels];
    
    // ============== 第一部分：驗證存款承諾 ==============
    
    // 重新計算承諾
    component commitmentHasher = Poseidon(3);
    commitmentHasher.inputs[0] <== nullifier;
    commitmentHasher.inputs[1] <== secret;
    commitmentHasher.inputs[2] <== blinding;
    signal commitment <== commitmentHasher.out;
    
    // ============== 第二部分：驗證 Merkle 證明 ==============
    
    // 使用 Merkle 樹驗證存款存在
    component merkleProof = MerkleProof(levels);
    merkleProof.leaf <== commitment;
    merkleProof.root <== root;
    
    for (var i = 0; i < levels; i++) {
        merkleProof.pathElements[i] <== pathElements[i];
        merkleProof.pathIndices[i] <== pathIndices[i];
    }
    
    // Merkle 驗證通過，意味著存款存在於樹中
    
    // ============== 第三部分：驗證空符哈希 ==============
    
    // 計算空符哈希並約束等於公開輸入
    component nullifierHasher = Poseidon(1);
    nullifierHasher.inputs[0] <== nullifier;
    nullifierHasher.out === nullifierHash;
    
    // ============== 第四部分：訊息驗證 ==============
    
    // 防止惡意中繼者替換接收者
    // 計算訊息哈希並驗證簽名（這裡省略簽名驗證電路）
    // 實際電路中需要包含 ECDSA 或 Schnorr 簽名驗證
    
    // ============== 安全約束 ==============
    
    // 防止攻擊者通過猜測找到存款
    // 秘密值應該至少有 128 位熵
    component secretBits = Num2Bits(128);
    secretBits.in <== secret;
    
    component nullifierBits = Num2Bits(128);
    nullifierBits.in <== nullifier;
    
    // 防止饋送攻擊：recipient、fee、refund 應該被包含在電路中
    // 實際實現需要這些值作為公開輸入並約束它們的使用
}

// 實例化電路
// levels: Merkle 樹深度
// nCommitments: 承諾總數
component main {public [root, nullifierHash, recipient, relayer, fee, refund]} = 
    Withdraw(20, 1048576);

承諾相等性約束

在 Privacy Pools 中，一個重要的約束是確保存款電路和提款電路使用相同的承諾邏輯：

// commitment_equality.circom
// 確保存款和提款使用相同的承諾計算

pragma circom 2.0.0;

include "poseidon.circom";

template CommitmentEquality() {
    signal input commitment1;
    signal input nullifier1;
    signal input secret1;
    signal input blinding1;
    
    signal input commitment2;
    signal input nullifier2;
    signal input secret2;
    signal input blinding2;
    
    // 計算第一組的承諾
    component hasher1 = Poseidon(3);
    hasher1.inputs[0] <== nullifier1;
    hasher1.inputs[1] <== secret1;
    hasher1.inputs[2] <== blinding1;
    
    // 計算第二組的承諾
    component hasher2 = Poseidon(3);
    hasher2.inputs[0] <== nullifier2;
    hasher2.inputs[1] <== secret2;
    hasher2.inputs[2] <== blinding2;
    
    // 約束：兩組輸入應該產生相同的承諾
    hasher1.out === commitment1;
    hasher2.out === commitment2;
    
    // 約束：兩個承諾相等（這是核心！）
    commitment1 === commitment2;
    
    // 這確保了：
    // 1. 存款時的承諾計算正確
    // 2. 提款時重新計算的承諾與存款承諾一致
    // 3. 攻擊者無法構造假的存款證明
}

// 這個約束在提款時隱式滿足，因為：
// - 存款電路的 commitment = hash(nullifier, secret, blinding)
// - 提款電路重新計算 commitment
// - 如果攻擊者想要構造假的提款，必須知道 (nullifier, secret, blinding)
// - 而這些值只有存款者知道

Solidity 智慧合約實作

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;

/**
 * @title PrivacyPool
 * @notice Privacy Pools 核心合約實現
 * @dev 支援多種關聯集的隱私存款和提款
 * 
 * 協議流程：
 * 1. 存款：用戶發送 ETH，計算並提交承諾
 * 2. 等待：建議至少 1 小時的等待期
 * 3. 提款：用戶提供零知識證明，取回 ETH
 * 
 * 安全考量：
 * - 零知識證明保護隱私
 * - 空符哈希防止雙花
 * - 承諾不可鏈接（non-linkable）
 */
contract PrivacyPool {
    
    // ============ 常量 ============
    
    uint256 public constant FIELD_ORDER = 
        21888242871839275222246405745257275088548364400416034343698204186575808495617;
    
    uint256 public constant denomination = 1 ether;
    
    // Merkle 樹深度
    uint32 public constant MERKLE_TREE_LEVELS = 20;
    
    // ============ 事件 ============
    
    event Deposit(
        bytes32 indexed commitment,
        uint32 leafIndex,
        uint256 timestamp
    );
    
    event Withdrawal(
        address indexed recipient,
        bytes32 nullifierHash,
        address indexed relayer,
        uint256 fee,
        uint256 refund,
        bytes32 indexed commitment
    );
    
    // ============ 狀態變量 ============
    
    // Merkle 樹根映射（支援多個根共存）
    mapping(bytes32 => bool) public roots;
    
    // 已使用的空符哈希（防止雙花）
    mapping(bytes32 => bool) public nullifierHashes;
    
    // 存款記錄
    mapping(bytes32 => uint256) public commitmentAmounts;
    
    // ============ 資料結構 ============
    
    struct Proof {
        bytes32[2] a;           // Groth16: alpha
        bytes32[4] b;           // Groth16: beta
        bytes32[2] c;           // Groth16: gamma
        bytes32[6] input;       // 公開輸入
    }
    
    // ============ Verifier 合約 ============
    
    IVerifier public verifier;
    
    constructor(address _verifier) {
        verifier = IVerifier(_verifier);
    }
    
    // ============ 存款函數 ============
    
    /**
     * @notice 存款到隱私池
     * @param _commitment 存款承諾 = hash(nullifier || secret || blinding)
     */
    function deposit(bytes32 _commitment) external payable {
        require(msg.value == denomination, "Incorrect deposit amount");
        require(_commitment != bytes32(0), "Invalid commitment");
        require(
            commitmentAmounts[_commitment] == 0,
            "Commitment already exists"
        );
        
        // 記錄存款
        commitmentAmounts[_commitment] = block.timestamp;
        
        // 插入到 Merkle 樹（這裡假設合約維護 Merkle 樹）
        uint32 leafIndex = _insert(_commitment);
        
        emit Deposit(_commitment, leafIndex, block.timestamp);
    }
    
    /**
     * @notice 內部函數：插入承諾到 Merkle 樹
     * @dev 實際實現需要維護完整的 Merkle 樹結構
     */
    function _insert(bytes32 _leaf) internal returns (uint32 index) {
        // 簡化版本：實際需要 Merkle 樹庫（如 OpenZeppelin 的）
        // 這裡返回當前葉子數量作為索引
        index = uint32(nextIndex);
        nextIndex++;
        
        // 更新當前根
        currentRoot = _updateMerkleRoot(_leaf);
        
        return index;
    }
    
    // ============ 提款函數 ============
    
    /**
     * @notice 從隱私池提款
     * @param _proof 零知識證明
     * @param _root 使用的 Merkle 根
     * @param _nullifierHash 空符哈希
     * @param _recipient 接收者地址
     * @param _relayer 中繼者地址（可選，否則為 0）
     * @param _fee 支付給中繼者的費用
     * @param _refund 退還的多餘 ETH
     */
    function withdraw(
        Proof memory _proof,
        bytes32 _root,
        bytes32 _nullifierHash,
        address payable _recipient,
        address payable _relayer,
        uint256 _fee,
        uint256 _refund
    ) external {
        
        // 1. 驗證 Merkle 根有效
        require(roots[_root], "Invalid Merkle root");
        
        // 2. 驗證空符哈希未使用（防止雙花）
        require(!nullifierHashes[_nullifierHash], "Nullifier already used");
        
        // 3. 驗證零知識證明
        // 公開輸入格式：[root, nullifierHash, recipient, relayer, fee, refund]
        bytes32[6] memory inputs = [
            _root,
            _nullifierHash,
            bytes32(uint256(uint160(_recipient))),
            bytes32(uint256(uint160(_relayer))),
            bytes32(_fee),
            bytes32(_refund)
        ];
        
        require(
            verifier.verifyProof(_proof.a, _proof.b, _proof.c, inputs),
            "Invalid proof"
        );
        
        // 4. 標記空符哈希為已使用
        nullifierHashes[_nullifierHash] = true;
        
        // 5. 轉帳
        require(
            address(this).balance >= denomination + _fee + _refund,
            "Insufficient balance"
        );
        
        if (_fee > 0) {
            _relayer.transfer(_fee);
        }
        
        _recipient.transfer(denomination);
        
        if (_refund > 0) {
            msg.sender.transfer(_refund);
        }
        
        emit Withdrawal(
            _recipient,
            _nullifierHash,
            _relayer,
            _fee,
            _refund,
            bytes32(0)  // commitment 從證明中無法直接獲取
        );
    }
    
    // ============ 管理函數 ============
    
    /**
     * @notice 添加新的有效 Merkle 根
     * @dev 通常由時間鎖控制的 DAO 調用
     */
    function addRoot(bytes32 _root) external onlyGovernance {
        roots[_root] = true;
    }
    
    // ============ 查詢函數 ============
    
    function isSpent(bytes32 _nullifierHash) external view returns (bool) {
        return nullifierHashes[_nullifierHash];
    }
    
    function isKnownRoot(bytes32 _root) external view returns (bool) {
        return roots[_root];
    }
    
    // ============ 內部狀態 ============
    
    bytes32 public currentRoot;
    uint32 public nextIndex;
    
    function _updateMerkleRoot(bytes32 _leaf) internal view returns (bytes32) {
        // 簡化：實際需要 Merkle 樹實現
        // 這裡應該計算新的 Merkle 根
        return keccak256(abi.encodePacked(currentRoot, _leaf));
    }
    
    // ============ 修飾符 ============
    
    modifier onlyGovernance() {
        // 實現治理檢查
        _;
    }
}

/**
 * @title IVerifier
 * @notice ZK 驗證者接口
 */
interface IVerifier {
    function verifyProof(
        bytes32[2] memory a,
        bytes32[4] memory b,
        bytes32[2] memory c,
        bytes32[6] memory input
    ) external view returns (bool);
}

AML/KYC 合規框架：機構級部署

終於聊到合規這個敏感話題了。

全球監管概況

截至 2026 年第一季度，各主要司法管轄區對 Privacy Pools 的態度：

數據來源：FATF 2026 年虛擬資產監管報告、Dune Analytics 合規追蹤儀表板，截止 2026-03-30

機構合規需求分層

不同類型的機構有不同的合規需求：

┌─────────────────────────────────────────────┐
│           最高隱私模式                       │
│  機構：家族辦公室、高淨值個人                │
│  特點：完全匿名、拒絕任何合規關聯            │
├─────────────────────────────────────────────┤
│           平衡模式                           │
│  機構：對沖基金、資產管理公司                │
│  特點：選擇性披露、僅向審計機構證明           │
├─────────────────────────────────────────────┤
│           合規優先模式                       │
│  機構：銀行、經紀商、託管機構                │
│  特點：主動合規、完全透明的鏈上蹤跡          │
└─────────────────────────────────────────────┘

合規集合設計

一個實際的合規集合設計：

// 合規集合管理器
contract ComplianceSetManager {
    
    // 合規集合狀態
    enum ComplianceLevel { NONE, BASIC, STANDARD, FULL }
    
    struct ComplianceSet {
        bytes32 merkleRoot;           // 集合的 Merkle 根
        ComplianceLevel level;        // 合規級別
        uint256 createdAt;            // 創建時間
        bytes32[] registeredAssets;   // 註冊的資產標識
        mapping(address => bool) authorities;  // 授權的監管機構
    }
    
    // 所有合規集合
    mapping(bytes32 => ComplianceSet) public complianceSets;
    bytes32[] public allSetIds;
    
    // 用戶的合規選擇
    mapping(address => bytes32) public userComplianceSet;
    
    event ComplianceSetCreated(bytes32 indexed setId, ComplianceLevel level);
    event UserComplianceUpdated(address indexed user, bytes32 indexed setId);
    event AuthorityAuthorized(bytes32 indexed setId, address authority);
    
    /**
     * @notice 創建新的合規集合
     * @dev 通常由監管機構或合規服務商調用
     */
    function createComplianceSet(
        bytes32 _setId,
        ComplianceLevel _level,
        bytes32[] calldata _registeredAssets
    ) external onlyOperator {
        require(
            complianceSets[_setId].createdAt == 0,
            "Set already exists"
        );
        
        ComplianceSet storage newSet = complianceSets[_setId];
        newSet.merkleRoot = bytes32(0);  // 初始為空
        newSet.level = _level;
        newSet.createdAt = block.timestamp;
        
        for (uint i = 0; i < _registeredAssets.length; i++) {
            newSet.registeredAssets.push(_registeredAssets[i]);
        }
        
        allSetIds.push(_setId);
        
        emit ComplianceSetCreated(_setId, _level);
    }
    
    /**
     * @notice 添加資產到合規集合
     */
    function addAssetToSet(
        bytes32 _setId,
        bytes32 _assetCommitment,
        bytes32[] calldata _merkleProof
    ) external onlyOperator {
        ComplianceSet storage set = complianceSets[_setId];
        require(set.createdAt > 0, "Set does not exist");
        
        // 驗證資產確實屬於此集合
        require(
            verifyMerkleProof(_assetCommitment, set.merkleRoot, _merkleProof),
            "Invalid proof"
        );
        
        // 這裡需要實現 Merkle 樹更新邏輯
        // ...
    }
    
    /**
     * @notice 用戶選擇合規集合
     * @dev 用戶在提款前選擇要使用的合規集合
     */
    function selectComplianceSet(bytes32 _setId) external {
        require(
            complianceSets[_setId].createdAt > 0,
            "Set does not exist"
        );
        
        userComplianceSet[msg.sender] = _setId;
        
        emit UserComplianceUpdated(msg.sender, _setId);
    }
    
    /**
     * @notice 授權監管機構訪問
     */
    function authorizeAuthority(
        bytes32 _setId,
        address _authority
    ) external onlyGovernance {
        complianceSets[_setId].authorities[_authority] = true;
        
        emit AuthorityAuthorized(_setId, _authority);
    }
    
    /**
     * @notice 查詢用戶的合規狀態
     * @dev 監管機構可調用此函數驗證用戶合規性
     */
    function getUserComplianceStatus(
        address _user,
        bytes32 _nullifierHash
    ) external view returns (
        bool isCompliant,
        ComplianceLevel level,
        bytes32 setId
    ) {
        setId = userComplianceSet[_user];
        
        if (setId == bytes32(0)) {
            return (false, ComplianceLevel.NONE, bytes32(0));
        }
        
        ComplianceSet storage set = complianceSets[setId];
        
        return (
            true,
            set.level,
            setId
        );
    }
    
    // 簡化的 Merkle 驗證
    function verifyMerkleProof(
        bytes32 _leaf,
        bytes32 _root,
        bytes32[] calldata _proof
    ) internal pure returns (bool) {
        bytes32 current = _leaf;
        
        for (uint i = 0; i < _proof.length; i++) {
            if (uint256(current) % 2 == 0) {
                current = keccak256(abi.encodePacked(current, _proof[i]));
            } else {
                current = keccak256(abi.encodePacked(_proof[i], current));
            }
        }
        
        return current == _root;
    }
    
    modifier onlyOperator() {
        // 運營商檢查
        _;
    }
    
    modifier onlyGovernance() {
        // 治理檢查
        _;
    }
}

主流協議實際實現比較

*Privacy Pools 為 2025 年新上線的協議，數據來源 Dune Analytics，截止 2026-03-30

結語

說實話，折騰完這些代碼和理論之後，我對 Privacy Pools 的態度變得複雜了。

一方面，這個技術設計確實優雅——它在密碼學上很有趣，在商業上也很有價值。機構用戶可以保護自己的交易隱私，同時又能滿足監管要求，這簡直是夢寐以求的平衡。

但另一方面，我總覺得哪裡不對⋯⋯

最大的問題是：誰來定義「乾淨」的標準？

如果把所有 Tornado Cash 的存款都標記為「骯髒」的，那隱私協議本身就變成了監管的附庸。如果標準太寬鬆，又可能成為洗錢的溫床。

而且別忘了，鏈上分析公司可不傻。他們完全可以把你和「使用過 Privacy Pools 的人」歸為同一類⋯⋯

不管怎樣，這項技術肯定會繼續發展下去的。2026 年看起來會是 Privacy Pools 真正起飛的一年，感興趣的朋友建議持續關注。

數據截止日期：2026-03-30

主要參考來源：

• Buterin, V. (2023). "Privacy Pools", Ethereum Research Forum, ethresear.ch/t/13818
• Privacy Pools Protocol (2026). GitHub Repository, github.com/privacy-pools
• Aztec Network (2026). Official Documentation, docs.aztec.network
• FATF (2026). "Virtual Asset Service Provider Guidance", FATF Recommendations
• European Banking Authority (2026). "MiCA Implementation Guidelines"
• Chainalysis (2026). "Crypto Crime Report 2026"