论文阅读：《Blockchain privacy and regulatory compliance: Towards a practical equilibrium》

0. 摘要

我们研究了一种名为“隐私池”（Privacy Pools）的新型智能合约隐私增强协议。该协议引入了一种机制，允许用户在不公开完整交易记录的前提下，选择性披露交易的某些属性。其核心在于让用户发布零知识证明，以验证其资金（未）来源于已知的（非法）合法渠道，这通过证明资金属于特定关联集合来实现——这些集合专为展示符合监管框架或社会共识而设计。我们阐述了该机制如何在合规与非合规提款间建立分离均衡，并详细分析了其技术原理、激励机制及更广泛的影响，揭示此类协议如何实现既保护隐私又符合监管要求的区块链交易。

1. Introduction

公有区块链在设计上具有透明性。其核心理念是任何人都应能自主验证交易，而无需依赖中心化的第三方机构。然而从隐私角度看，记录所有地址交易的公开数据集存在显著问题。当用户向某个地址转移资产或与智能合约交互时，该交易将永久留存于区块链上。每个链上操作都会形成永久公开记录，使得第三方能够分析用户的财务往来和行为模式。

这些隐私隐患催生了增强隐私协议的出现。此类协议允许用户通过A地址存入资金，后续通过B地址提取。尽管存取记录仍公开可见，但具体存取行为间的关联性已被隐藏。

Tornado Cash是最著名的隐私增强协议之一。它在解决上述问题的同时，也吸引了不法分子使用。链上数据显示，黑客组织曾利用该协议转移非法所得资金。当证据表明朝鲜黑客组织也使用该协议后，美国财政部海外资产控制办公室(OFAC)将其智能合约地址列入特别指定国民名单(SDN清单)。

Tornado Cash的核心缺陷在于：诚实用户缺乏有效手段与协议内的非法活动划清界限。其提供的合规工具虽允许用户证明取款来源，但需依赖中心化中介并导致信息不对称，因此实际使用率极低。

本文提出该方案的扩展机制，使用户能公开证明其取款资金可能来源的宽泛范围。支持两种证明模式：成员证明（“证明取款来自特定存款集合”）或排除证明（“证明取款与特定存款无关”）。该概念由Privacy Pools率先提出，本文将探讨如何运用其构建模块实现诚实用户与恶意用户的行为分离。

需说明的是，Privacy Pools通过扩展用户操作集提供更多选择。必要时用户仍可向特定对手方提供详细证明。但在多数场景下，成员证明或排除证明已足够。且相较于双边披露机制，公开这些证明具有显著优势。

2. 技术背景

本节将简要介绍Privacy Pools类协议的技术构件与基本原理。

2.1 ZK-SNARKs出现前的区块链隐私方案

早期区块链支持者认为，尽管交易透明，但通过地址伪匿名性（用户无需透露线下身份，仅通过数字"地址"标识）仍可保障隐私。中本聪在比特币白皮书中明确主张：“通过公钥匿名化切断信息流，公众仅能观测资金流向而无法关联具体身份”。但事实证明，面对现代聚类分析工具，这种隐私保护程度远远不足。非金融应用（如在Ethereum name service等去中心化域名服务注册名称）往往需要用户链上公开更多个人信息，进一步加剧隐私泄露风险。

为提升公有链隐私性，业界逐步引入更强大的技术方案。首个被广泛采用的非平凡隐私解决方案是CoinJoin[9]，其通过多用户在同一交易中混合币种实现输入输出对应关系的模糊化。理论上用户参与多轮混合可隐藏资产来源，但Monero采用的环签名方案更进一步，无需链下交互即可实现小额混合。随着技术演进，单次混合参与者数量增加扩大了匿名集（即可能成为交易来源的历史交易范围），但这类小规模重复混合仍存在数据泄露风险。

密码学隐私技术的下一阶段突破是通用零知识证明的引入。Zerocash率先实现该创新，后被Zcash等区块链及Tornado Cash等智能合约系统采用。这类系统使交易的匿名集可扩展至所有历史交易，此类通用零知识证明技术通常被称为ZK-SNARKs。

2.2 ZK-SNARKs技术

ZK-SNARKs允许证明者在不泄露私有数据的前提下，验证关于公私数据组合的数学命题，其具备两大核心特性：

• 零知识性：除证明命题成立外，不泄露任何私有数据
• 简洁性：证明体积小且验证速度快，即使底层计算非常复杂

在区块链领域，ZK-SNARKs因这两大特性备受关注。虽然系统公共参数的初始可信设置（trusted setup）需要消耗大量时间和资源，但该过程仅需执行一次。证明过程的简洁性对ZK-rollups等扩展性方案至关重要，而本文讨论的隐私用例更侧重零知识特性。

ZK-SNARKs证明的命题通常表示为电路程序，数学上可抽象为函数 $f(x, w) \rightarrow \{\text{True}, \text{False}\}$ 。其中$𝑥$为公开输入，$𝑤$ 为私有输入，$𝑓(.)$为待验证函数。ZK-SNARKs的本质是：对于证明者与验证者共知的$𝑥$，证明者能提供使$𝑓(𝑥,𝑤)=\text{True}$ 的私有参数$𝑤$。

2.3 应用案例：Zcash 与 Tornado Cash类系统中的ZK-SNARKs

尽管Zcash各版本及其衍生系统（如Tornado Cash）存在细微差异，但其底层逻辑高度相似。本节将描述这些协议的基本运作原理。

每个"代币"(coin)由持有者保管的私密参数 $𝑠$ 构成，该参数可为任何仅所有者知晓的数据。通过 $𝑠$ 可衍生两个关键值：

• 公开的"代币ID"：$L = \mathrm{hash}(s + 1)$
• 作废标识符：$U = \mathrm{hash}(s + 2)$

其中 $\mathrm{hash}$ 代表 SHA256 等密码学哈希函数。已知$s$可计算代币ID与作废符，但哈希函数的伪随机性确保在缺乏𝑠的情况下，外界无法关联特定作废符与代币ID的对应关系。

区块链会记录所有已"创建"的代币ID和已"花费"的作废标识符。这两个集合都是持续增长的（除非协议要求代币必须在时限内花费）。

代币ID集合存储在名为默克尔树（Merkle Tree）的数据结构中：若树包含 $𝑁$ 个条目，则每对相邻条目会被哈希（产生$\lceil N/2 \rceil$个哈希值），这些哈希值再两两哈希（产生$\lceil N/4 \rceil$个哈希值），如此递归直至所有数据最终汇聚为单个"根哈希"。

一组代币ID存储在一个名为**默克尔树（Merkle Tree）**的数据结构中：

• 若树包含 $𝑁$ 个数据项，则首先对相邻两项进行哈希计算，生成$\lceil N/2 \rceil$个哈希值；
• 接着对这些哈希值再次两两哈希，生成$\lceil N/4 \rceil$个哈希值；
• 重复此过程，直到最终生成一个唯一的**“根哈希”（root hash）**。

给定树中的某个值和根哈希，我们可以提供一条默克尔分支（Merkle Branch）：即从该值到根哈希的路径上，每一层级哈希时所需的**“兄弟节点值”**。这条分支非常有用，因为它仅需少量数据（约$\log_2 N$个哈希值），即可证明某个值确实存在于树中。下图展示了一个高度为4的默克尔树示例。

图中高亮了树中某个值对应的默克尔分支（Merkle Branch）：

• 橙色：待证明的叶子节点 𝐿（即需要验证的数据项）。
• 底部一行：代表整个数据集（所有叶子节点）。
• 绿色：根哈希 𝑅（整棵树的唯一摘要）。
• 蓝色：从叶子 𝐿 到根 𝑅 的路径。
• 紫色：路径上每一层级的兄弟节点（sister nodes）。

路径本身无需直接提供，因为只需从叶子 𝐿 开始，逐层与兄弟节点哈希计算，即可推导出根哈希 𝑅。验证时，仅需提供这些兄弟节点（紫色部分），通过计算即可确认 𝐿 是否在树中。

当用户向他人发送代币时，需提供：(i) 待花费的作废标识符（nullifier）𝑈；(ii) 新生成的代币ID 𝐿′（由接收方提供）；(iii) 一个ZK-SNARK证明。

该ZK-SNARK包含以下私有输入：

• 用户的私密值 $𝑠$
• 代币ID树中的一条默克尔分支，用于证明代币ID $𝐿 = \text{hash}(𝑠 + 1)$ 曾经被创建过

以及以下公开输入：

• $𝑈$（待花费代币的作废标识符）
• $𝑅$（默克尔证明所验证的根哈希）

ZK-SNARK证明以下两个性质：

1. $𝑈 = \text{hash}(𝑠 + 2)$（确保作废标识符正确生成）
2. 默克尔分支有效（证明代币 $𝐿$ 确实存在于树中）

在ZK-SNARK之外，协议还会验证：

• 𝑅 是当前或历史版本的代币ID树的根哈希
• 𝑈 未被标记为已花费

若交易有效，系统会将 𝑈 加入已花费作废标识符集合，并将 𝐿′ 添加到代币ID列表中（见图2）。

作废机制（𝑈）的作用：

• 防止同一代币被重复花费。
• 除此之外，不泄露任何其他信息。外界仅能观察到交易的发生，但无法推断交易双方的身份或代币的流转历史。

对上述模式存在两种例外情况：存款（deposit）与提款（withdrawal） 在存款操作中，系统会直接生成新的代币ID（coin ID），而无需使任何既有代币失效。存款行为本质上不具备隐私保护性，因为特定代币ID（𝐿）与其生成所依赖的外部事件（例如Tornado Cash中的ETH充值、Zcash中的ZEC新币挖矿）之间的关联是公开可查的。换言之，存款行为会暴露其与历史交易链路的关联性。

而在提款操作中，系统仅消耗作废标识符（nullifier）而不生成新代币ID。这种机制可以切断提款操作与对应存款之间的关联，进而消除与历史交易链路的联系。但需注意的是，提款操作仍可能与后续发生的交易产生关联[2]。

Tornado Cash的版本演进

• 初代版本：仅支持存款/提款基础功能，未实现内部转账机制
• 实验版本（Alpha阶段）： ✓ 新增支持隐私化内部转账​ ✓ 引入任意面额代币处理能力 ✓ 集成"拆分"（splitting）与"合并"（merging）操作协议 （这些功能是处理可变面额交易的必备基础架构）

我们将在后续章节详细探讨如何将基础隐私转账系统与隐私资金池（Privacy Pools）扩展至支持任意面额交易的实施方案。

2.4 隐私池中的ZK-SNARK技术

隐私池的核心思想在于：用户不仅需要零知识证明（zero-knowledge proof）其提款与某个历史存款相关联，还需证明该交易隶属于一个更具约束性的关联集合（association set）。这个关联集合可以是所有历史存款的全集子集、仅包含用户自身存款的集合，或是介于二者之间的任意组合。用户通过提供该集合的默克尔根（Merkle root）作为公开输入来指定具体集合。

为简化流程，我们并不直接证明关联集合确实是历史存款的子集，而是要求用户对两条默克尔分支（Merkle branch）进行零知识证明，且两条分支均使用相同的代币ID作为叶子节点：(i) 指向总币ID集合根𝑅的默克尔分支；(ii) 指向用户提供的关联集合根𝑅𝐴的默克尔分支。下图展示了这一机制：

设计意图在于，完整的关联集合将通过链上或其他渠道公开。这正是核心创新所在：我们既不强制用户精确披露提款来源的具体存款（这过于严格），也不允许其仅提供防双花证明（这过于宽松），而是让用户自主指定资金可能来源的集合范围——该范围可宽可窄，完全取决于用户意愿。我们期望形成一个生态系统，帮助用户便捷地创建符合其偏好的关联集合。本文后续内容将围绕这一基础机制，阐述其上层基础设施及衍生影响。

3. 实践考量与应用场景

在完成技术性介绍后，我们现在转向应用层面，探讨隐私增强协议（privacy-enhancing protocols）如何在实际场景中发挥作用。

3.1 关联集合（association sets）的用例

为了说明该方案在执法场景中的价值，我们举一个简单例子。假设有五名用户：Alice、Bob、Carl、David 和 Eve。前四位是诚实守法的用户，但仍希望保护隐私；而 Eve 是一名窃贼。这一信息为公众所知——尽管公众可能不知道 Eve 的真实身份，但有充分证据表明，发送至标记为“Eve”的地址的代币是赃款。这种情形在实践中很常见：例如，流入 Tornado Cash（一种隐私混币协议）的大部分非法资金均来自 DeFi（去中心化金融）协议漏洞攻击，此类事件在公开区块链上可被追踪。

当这五名用户发起提款时，他们需选择指定的关联集合（association set）。其关联集合必须包含自己的初始存款地址，但可自由选择是否包含其他地址。我们首先分析 Alice、Bob、Carl 和 David 的动机：

• 隐私最大化：促使他们扩大关联集合的规模；
• 降低风险：为避免商户或交易所将其代币视为可疑资产，他们会选择不将 Eve 纳入关联集合。

因此，四人的选择很明确：关联集合均为 {Alice, Bob, Carl, David}。

而 Eve 同样希望最大化关联集合，但由于无法排除自己的存款地址，她被迫将关联集合设为全部五个地址。图4展示了参与者的关联集合选择结果。

每行中的灰色区域代表相应用户的关联集合（association set）。

在我们简化的示例中，假设 Alice、Bob、Carl 和 David 的关联集合均包含其他所有“清白”存款地址，同时排除来自已知非法来源的存款5。而 Eve 无法生成一个将其提款与自身存款地址解绑的证明（proof）。

尽管 Eve 本人未主动泄露信息，但通过简单的排除法即可明确推断：提款 #5 只能来自 Eve。

3.2 关联集合的构建

上一节阐述了在类似隐私池（Privacy Pools）的协议中使用关联集合的一种可能方式，以及诚实参与者如何与不良行为者划清界限。需注意，该系统并不依赖Alice、Bob、Carl和David的利他行为——他们有明确的动机去证明自己与不良行为的无关性。

现在，让我们更深入地探讨关联集合的构建方法。总体而言，生成关联集合主要有两大策略（如图5所示）：

• 包含策略（Inclusion/Membership）： 通过特定证据筛选出一组被认定为低风险的存款（deposits），并构建仅包含这些存款的关联集合。
• 排除策略（Exclusion）： 通过特定证据识别一组高风险存款，并构建排除这些存款之外的关联集合。

实际应用中，用户不会手动挑选存款来构建关联集合，而是订阅中介服务商——我们称之为关联集合提供方（Association Set Providers, ASPs）。这些提供方会生成具有特定属性的关联集合。某些情况下，ASPs可完全通过链上（on-chain）自动化生成，无需人工（或AI）干预；其他情况下，ASPs可能自主生成关联集合，并将其发布在链上或其他平台。

我们强烈建议至少将关联集合的默克尔根（Merkle root）发布在链上。此举可防止恶意ASPs对用户实施特定类型的攻击（例如：通过向不同用户提供不同关联集合来试图去匿名化）。完整的集合数据应通过API提供，或理想情况下存储在低成本去中心化存储系统（如IPFS）中。

用户能够下载完整关联集合至关重要，因为这允许他们在本地生成集合成员证明（proofs of membership），而无需向ASPs透露任何额外信息（包括提款对应的具体存款）。

以下是ASPs在实际运营中可能采用的几种构建方案：

1. 延迟添加+排除不良行为者： 所有存款在固定期限（如7天）后自动加入关联集合；但若系统检测到某笔存款与已知不良行为（如大规模盗窃或政府制裁名单中的地址）相关联，则永久排除。实践中可通过社区维护的黑名单或现有交易筛查服务商实现。
2. 每人每月$N限额： 加入关联集合的存款需满足：
   • 金额低于固定上限
   • 存款人需零知识证明（zero-knowledge-proof）其持有人格验证凭证（proof-of-personhood token）（如政府背书的国民ID系统或社交媒体账号验证等轻量机制） 为防止女巫攻击（Sybil attacks），系统采用带月份参数的作废机制（nullifier mechanism），确保每个身份每月仅能提交一笔存款。此设计试图体现现行反洗钱（AML）规则的精神——低于特定阈值的小额交易可享有更高隐私权限。注：该方案可完全通过智能合约实现，无需人工监督。
3. 可信社区成员每月$N限额： 与方案2类似但更严格：用户必须证明自己是高信任度社区（high-trust community）​的成员，该社区承诺为成员提供相互隐私保障。
4. 基于AI的实时评分： AI驱动的ASP系统可实时评估每笔存款的风险分数，并输出包含低于特定风险阈值存款的关联集合。ASPs还可能根据多级风险阈值生成多个集合。

4. 技术细节详解

本节将分析提案如何支持任意面额（arbitrary denominations）​，并讨论重复验证（re-proofing）​、双向直接验证（bilateral direct proofs）​和序列验证（sequential proofs）​等特殊情况。

4.1 支持任意面额

前文所述的简化隐私币系统仅支持同面额转账。而Zcash通过未花费交易输出模型（UTXO, Unspent Transaction Output）实现任意面额支持：每笔交易可包含多个输入（需为每个输入公开作废标识符/nullifier）和多个输出（需为每个输出公开币ID/coin ID）。每个新生成的币ID必须附带加密的面额值。除验证作废标识符有效性外，交易还需额外证明新生成币的面额总和不超过所花费币的面额总和（见图6）。

图6. 零知识简洁非交互式论证（ZK-SNARK） 需额外证明以下声明：加密面额对应的数值满足 输出端数值总和 ≤ 输入端数值总和。根据具体实现方案，可能还需显式证明所有新生成币的面额均为非负数。

此设计可通过以下方式扩展以支持存取款：

• 将存款视为未加密的输入，取款视为未加密的输出；
• 或限制设计以简化分析（例如仅允许部分取款/partial withdrawals）：交易包含1个加密输入和2个输出（1个未加密的取款输出 + 1个加密的"找零"输出，剩余资金可后续使用）。

隐私池（Privacy Pools）的适配挑战

直接套用现有设计会导致**交易图谱（transaction graph）不符合预期：例如用户存入10个币后分四次取出（1+2+3+4），理想情况是所有取款都应关联原始10币存款，但实际结果如图7所示——第二次取款关联的是第一次取款后生成的9币找零输出，依此类推。这会导致关联集（association set）**需不断验证中间存款，引发实践问题。

解决方案

若要使所有取款都能声明原始10币存款为来源，需同时满足：

1. 确保部分取款之间无公开关联；
2. 允许每笔部分取款将存款纳入其关联集。

对于仅支持部分取款（非复杂多输入/输出交易）的场景，可通过信息承诺传播实现：

• 要求交易包含承诺值 hash(coinID + hash(r))（添加随机数r保证盲性）；
• 通过零知识证明/ZK-SNARK验证：若父交易为取款，则承诺值与父交易一致；若为存款，则承诺值关联原始存款的coin ID。
• 最终链上每笔交易都会包含对原始存款coin ID的承诺，并证明该值包含在提供的关联集中。

防余额求和攻击（balance-summing attacks）

例如存入10币后分次取出7.2859和2.7141，攻击者可能通过金额关联交易。为此可支持币合并（coin merging）：将零散币与下次存款合并处理。此时需：

• 交易承诺一组coin ID；
• 多输入交易承诺其所有父交易的并集；
• 取款时证明所有承诺的coin ID均在其关联集中。

4.2. 特殊情况

4.2.1. 重复验证（Re-proofing）

在类似隐私池（Privacy Pools）的协议中，用户需要凭借秘密存款信息 $𝑠$ 才能提取存款。该秘密信息随后还可用于构建关联集成员资格证明（association set membership proofs）。假设以下场景：Alice 提取了她的资金，创建并发布了一个关联集成员资格证明。之后，当她想在要求提供不同关联集证明的商户处消费时，只要仍持有该秘密信息，就能针对商户的关联集生成新的证明。同理，Alice 也可针对初始关联集的更新版本生成新证明。保留秘密信息能赋予 Alice 更大灵活性，但若该信息遭泄露，则可能增加其隐私暴露的风险。

另一种场景出现在针对特定事件的调查中。假设某些涉及链上代币的不良行为发生，初步调查显示这些代币可能来自一组特定输入源——这可能是因为相关代币源自某个小型社区的提款关联集，或是链上证据与其他证据共同揭示了事件幕后者的部分信息。此时，关联集其他成员或需通过生成排除性证明（exclusion proofs）以自证清白，从而揭露真实责任人的身份。反之，若某事件存在争议但获得大量无关人士支持，这些支持者可能拒绝提供此类证明。

4.2.2 双边直接证明（Bilateral direct proofs）

在某些场景下，用户可能需要向另一方披露其提款资金的确切来源。例如，当Alice希望将提取的资金存入银行时，银行可能要求提供资金完整来源信息。对此，Alice可以创建一个仅包含其存款的关联集，并针对该集合生成证明。此类证明预计属于特例，且仅在双边共享时提供部分隐私保护。需注意的是，共享此类证明需基于强信任假设——即接收方不会进一步传播该证明。

另一种更高级的方案是：Alice通过零知识证明（zero-knowledge proof）声明以下三个命题中至少有一个为真：(i) “该提款属于当前关联集”；(ii) “我是银行方”；(iii) “根据特定时间戳服务（可以是服务器或区块链记录），本证明的生成时间已超过10秒”。只有实时接收证明的银行方（iii）在确认自身未生成该证明（ii）时，才会采信该证明。若证明落入第三方手中，接收者将难以验证其真实性。这种机制可消除绝大多数因隐私泄露导致的对手方风险（counter-party risk）。

4.2.3 顺序证明（Sequential proofs）

让我们设想一个长期未来的场景：类似隐私池（Privacy Pools）的系统不再偶尔使用，而是应用于绝大多数交易中。这正是Zcash等隐私优先（privacy-first）系统所追求的理想状态。这种场景会带来一些新的复杂性，而这些复杂性在隐私池偶尔使用的场景中并不存在。

为适应这种场景，协议需进行如下修改：除存款（deposit）和取款（withdrawal）交易类型外，协议还需支持一种内部发送（internal send）操作——该操作会消耗现有的代币ID（coin ID），并生成一个归属于他人的新代币ID。从协议分析角度看，这等同于发送方将资金提取至接收方地址后，接收方立即重新存款，但通过将步骤数量与链上证明（on-chain proofs）从两次缩减为一次，显著提升了效率。

假设Alice向Bob发送代币：即她执行一次内部发送操作，（可能部分）消耗属于Alice的代币ID，并根据Bob提供的参数创建新代币ID。若Bob想立即将该代币转给Carl进行消费，同时希望这笔消费交易也保持隐私性，此时就会面临我们的核心挑战：纳入延迟（inclusion delays）。在前文提出的多数配置方案中，关联集提供方（ASPs）不会立即将Bob的新代币加入其关联集（association set），因为他们需要警惕资金源头可能并非Alice，而是刚从Alice钱包窃取资金的攻击者。纳入延迟的设计正是为了让Alice有时间报告异常，或为第三方提供检测时间。

另一个类似用例是：当"Alice"变为DeFi协议时，Bob希望从该协议提取资金后立即以隐私支付方式转给Carl。此场景虽减少了一个人类参与者，但结构上高度相似。

在高速流转的经济体中，同一笔资金可能每周甚至更频繁地多次流转，此时纳入延迟将构成严峻挑战。一个可能的解决方案是：当用户钱包中所有代币均未"成熟"（即未被纳入相关关联集）时，用户只能通过非隐私保护交易（non-privacy-preserving transaction）进行转账。但我们提出了信息泄露更少的替代方案：

当Bob向Carl支付时，Bob会直接向Carl提供用于生成该笔支付的默克尔分支（Merkle branch）和密钥（secret）。这使得Carl能像Bob一样确认：来自Alice的支付记录存在于该代币的历史中。若后续发现大量与不良行为者（bad actors）关联的代币被存入并快速流通，Carl可证明其代币的最终来源与不良行为者无关。

当Carl将代币转给David时，他会传递来自Bob的默克尔分支与密钥，并追加自己的信息。假设David随后将代币转给Emma时，Alice的存款已被纳入关联集，此时David无需再提供Alice的默克尔分支或密钥——他只需代表Alice生成关联集成员证明（association set membership proof）即可。同理，当Bob的支付被纳入关联集后，其默克尔分支与密钥也将失效。该机制的核心在于确保每个用户仅获取必要的最小信息量，即可对所接收资金建立信任。图8展示了这一案例。

图8. 当David向Emma发送交易时，他需要提供来自自身、Carl和Bob的默克尔分支（Merkle branch）与密钥（secret），但无需提供Alice的部分——因为Alice向Bob的支付此时已被纳入关联集（association set）。

实际场景中，一个代币可能具有多重"来源"：例如Bob作为咖啡供应商，分别收到Alice的5枚、Ashley的4枚和Anne的7枚代币，当日需向Carl支付15枚代币作为晚餐费用；而David可能从Carl处收到15枚代币，又从Chris处收到25枚，最终需向交易所Emma存入30枚代币。对于此类复杂情况，我们遵循同一原则：已被纳入关联集的陈旧历史可被忽略，而新近历史需继续向前传递。

5. 讨论

类似隐私池（Privacy Pools）的系统允许用户在保护金融交易数据隐私的同时，保留证明其与已知非法活动无关的能力。我们预计诚实用户将受到以下两个因素的共同激励而参与此类方案：(i) 对隐私的需求；(ii) 避免被怀疑的意愿。

5.1. 社会共识与关联集合（Association Sets）

若社会对资金"合法"（good）与"非法"（bad）存在完全共识，该系统将形成简单的分离均衡（separating equilibrium）。所有持有"合法"资产的用户都有强烈动机且能够证明自己属于仅包含"合法"资金的关联集合。而恶意行为者则无法提供此类证明——他们仍可将"非法"资金存入池中，但无法从中获益。任何人都能轻易识别这些资金来自隐私增强协议（privacy-enhancing protocol），并发现其提款引用了包含可疑来源资金的关联集合。更重要的是，“非法"资金不会污染"合法"资金：当合法存款被提款时，所有者只需从关联集合中排除所有已知"非法"存款即可。

当缺乏全球共识，且资金性质判定取决于社会观念或司法管辖区时，关联集合可能显著不同。假设存在两个采用不同规则的司法管辖区，𝐴和𝐵均可使用相同的隐私增强协议，并根据各自辖区要求生成合规证明。双方都能在其关联集合内实现隐私保护，并排除不符合本辖区要求的提款。必要时，用户还可针对两个关联集合的交集生成成员证明（membership proof），从而可信地表明其提款对应的存款同时符合双方法规要求。

因此，该提案具有高度灵活性，应被视为中立基础设施。一方面，它具有抗审查性（censorship-resistant），允许用户自主选择关联集合并在其社群内保持隐私；另一方面，外部监管方可要求提供符合其特定关联集合的证明。这意味着即使隐私增强协议内存在恶意行为者社群，只要关联集合的构建准确反映信息，他们也无法掩盖存款的可疑来源。

5.2. 关联集合的特性

关联集合需具备特定属性才能有效运作：首先必须保证准确性（accurate），使用户确信提款后的资金可安全使用；其次应保持稳定性（stable），即属性不会随时间轻易变化，从而减少针对新集合的重复证明需求；最后，为实现实质性隐私，必须确保集合足够庞大且包含多样化存款。然而这些特性存在内在矛盾：规模大且多样化的集合虽能提供更好隐私性，但准确性与稳定性较低；而较小集合更易维护，却会削弱隐私保护效果。

5.3 实践考量与竞争关系

接受加密资产（crypto assets）的受监管实体必须确保其适用的法律法规允许接收此类资金。目前，这些实体大多依赖所谓的交易筛查工具（transaction screening tools）——通过分析区块链来识别潜在可疑活动、与非法地址（illicit addresses）的关联或其他违规交易的软件或服务。筛查工具通常通过风险评分（risk score）来量化每笔交易的风险程度，该评分基于资金流向地址及其交易历史记录（transaction history）生成。

隐私增强协议（privacy-enhancing protocols）在这方面可能构成挑战。这类协议会切断存款（deposits）与提款（withdrawals）之间的可见关联。因此，当存在隐私增强协议时，风险评分必须结合零知识证明（proofs），并根据关联集合（association set）进行判定。

现有的交易筛查工具和服务主要由兼具区块链分析与法律专业知识的公司提供。理想情况下，这些公司（及其他所有方）应能获取全部成员证明（membership proofs）及其对应关联集合，从而对所有交易生成精准风险评分。为此我们建议：除与特定交易对手方（counterparty）共享的单一成员证明（size one proofs）外，所有证明都应存储在区块链或公开可访问的证明库（proof repository）中——基于明显原因，此类单一证明不应公开。

将证明存储于链上（on-chain）虽会增加交易成本，但能降低协调难度、维护公平竞争环境，并避免筛查工具提供商因掌握非公开证明而获得准垄断地位（quasi-monopoly）。

隐私池（Privacy Pools）的架构具有高度灵活性。通过创建特定关联集合，该协议可适配多样化应用场景，例如：

• 商业银行联盟（consortium of commercial banks）可创建仅包含其客户存款的关联集合。这能确保任何基于该集合生成的提款证明均经过成员银行的客户身份核验（KYC）与反洗钱（AML）程序，同时不暴露具体客户归属；
• 当金融中介（financial intermediary）需记录资金确切来源时，可要求用户提供仅包含其自身存款的关联集合证明。该证明通过双方私下交换（exchanged bilaterally），使中介能像用户从未使用隐私池一样追踪资金流向。此方案虽需用户信任中介不泄露证明，但能在满足监管要求的同时避免向公众公开信息。

5.4 设计选择与替代方案（Design choices and alternatives）

基于关联集合（association sets）、零知识证明（ZK-proofs）和自愿披露（voluntary disclosure）的架构具有高度灵活性。虽然这种设计能确保提案可适配不同司法管辖区，但必须审慎对待具体实施方案。我们特别反对两种潜在调整方案，因其信任要求存在缺陷，并可能催生准垄断（quasi-monopolistic）市场结构。

下文将简要探讨这两种替代方案：

1. 中心化访问权限（Centralized access）：允许执法机构、加密风险评分服务商（crypto risk scoring providers）等特定主体查看用户交易关联，同时对其他主体保持隐匿。
2. 系统级准入白名单（System-wide entry allowlisting）：隐私系统可限制用户向资金池存款的权限，要么要求提供额外证明，要么设置存款等待期供中心化风险评分系统（centralized risk scoring system）行使否决权。

这两种方案的共性在于赋予特定实体特权，进而引发复杂的治理问题：谁有权获取信息？谁掌握权限管理权？

私营企业并非理想选择——任何特权都可能导致寡头垄断（oligopolistic）市场结构，少数掌握数据权限的企业将垄断服务市场，扼杀竞争。

若将权力赋予公共机构（public institutions），尤其在国际语境下，则会衍生大量治理与政治难题。即便当前某个完全可信的机构持有后门密钥（backdoor key），既不滥用权力谋取政治利益，也不受其他施压实体影响，但认为这种状态会永恒不变则过于天真。组织架构、成员构成、国家政权及内部政治结构都会随时间演变。外部压力可能涌现，而特权的存在会激励恶意行为者渗透并操控该组织的治理体系。

更严重的是，组织内外的攻击行为或中心化实体代表的失误都可能引发深远后果。我们认为应当避免制造这类中心化单点故障（central point of failure）。

当然，我们承认不同交易规模与场景可能需要差异化的证明组合。例如大额交易用户可能需在链上提交基础排他证明（basic exclusion proof），同时向交易对手方披露更详尽的资金来源信息。

5.5 后续研究方向（Further research potential）

尽管本研究概述了基于ZK-SNARK的隐私增强协议（privacy-enhancing protocols）在监管环境中的应用前景，仍有多个领域值得深入探索：

首先需明确，这些协议提供的隐私保护效果受多重因素影响。关联集合规模不足、根值（root choices）选择不当或用户操作失误，都可能使攻击者成功关联存取款交易。其他用户的行为也可能损害你的隐私——极端情况下，若资金池中所有成员都提交规模为1的成员证明（membership proof），其存取款间的直接关联将暴露无遗，剩余的唯一存取款交易对也会被间接曝光。更微妙的情形中，攻击者可通过组合各类成员证明的约束条件，以高概率推断存取款关联。当这些证明数据与交易元数据（transactional metadata）结合时，协议的隐私属性将受到严重威胁。此外，恶意匿名服务提供商（ASP）可能通过精心构造关联集合来最大化信息提取效率，或通过混入已知取款路径的存款来虚增匿名性感知。这些问题都需进一步研究以评估实际隐私保障效果。

同样值得深入研究分离均衡（separating equilibrium）的特性：建模分析良性与恶意行为者在特定假设下的行为模式，以及前者的公开证明如何影响后者的隐私。

最后，法律学者可深入研究具体披露要求。本文提案具有高度适应性（highly adaptable），法学专家的见解能帮助定制协议及周边生态，确保其符合不同司法管辖区的合规要求。

6. 结论（Conclusion）

传统观点常将隐私保护与监管合规视为不可调和的矛盾。本文论证：若隐私增强协议（privacy-enhancing protocol）允许用户证明其资金合法来源的特定属性，二者便可实现共存。例如，用户既能证明资金与非法来源存款无关，又能通过零知识证明（ZK-proofs）表明资金属于某个合规存款集合，而无需泄露更多信息。

这种机制可形成分离均衡（separating equilibrium）——诚实用户有强烈动机证明自己属于合规关联集合（compliant association set），同时在该集合内享受隐私保护；而欺诈者则无法提供此类证明。这使得诚实用户能与不受监管认可的第三方存款划清界限，避免在受监管环境中遭遇资金使用限制。我们认为该提案具有高度灵活性，可适配多样化的监管要求。

本文旨在为金融隐私与监管共存的未来提供建设性思考。我们期望推动跨领域对话，将讨论导向更积极务实的方向。要实现这一目标，需要从业者、跨学科学者、政策制定者与监管机构通力合作，共同完善提案细节，最终构建出既符合监管要求又保障隐私的基础设施。

利益冲突声明（Declaration of competing interest）

作者声明以下可能构成潜在利益冲突的财务/个人关系：

• 本文分析了类Privacy Pools架构，而Ameen Soleimani系Privacy Pools开发者

致谢（Acknowledgement）

特别感谢Mitchell Goldberg、Katrin Schuler和Dario Thürkauf提供的宝贵意见，Emma Littlejohn的文稿校对，以及Dario Thürkauf在图形设计方面的支持。