Vitalik 隐私文章：区块链隐私与监管合规：迈向实用平衡
我们研究了 Privacy Pools，一种基于智能合约的新型隐私增强协议。该协议引入了一种机制，允许用户在不公开交易本身的情况下，揭示其交易的某些属性。
🔗 原文链接：https://www.sciencedirect.com/science/article/pii/S2096720923000519
Vitalik Buterin，Jacob Illum，Matthias Nadler，Fabian Schär，Ameen Soleimani
关键词：区块链、隐私、监管、智能合约、零知识证明
我们研究了 Privacy Pools，一种基于智能合约的新型隐私增强协议。该协议引入了一种机制，允许用户在不公开交易本身的情况下，揭示其交易的某些属性。核心概念是让用户发布零知识证明，证明其资金（不）来源于已知的（非）合法来源，而无需公开其完整的交易历史。这是通过证明在自定义关联集合中的成员资格实现的，这些集合旨在展示对监管框架或社会共识的合规性。我们说明了这种机制如何在合规和非合规提款之间创建分离均衡。我们的工作描述了该机制的技术基础、激励机制和更广泛的影响，强调了 Privacy Pools 类协议如何创建更私密且合规的区块链交易。
01 ｜ 引言
公共区块链在设计上是透明的。其基本理念是任何人都应能够验证交易，而无需依赖中心化的第三方。这减少了依赖性，并可能为各种应用（包括但不限于金融和自主身份）提供中立的基础。
然而，从隐私角度来看，存在一个包含每个区块链地址所有交易的公共数据集是有问题的。每当某人将资产转移到另一个地址或与智能合约交互时，该交易将永远在区块链上可见。
考虑以下例子：Alice 去餐厅用餐并使用她的区块链钱包支付晚餐费用。收款方现在知道 Alice 的地址，并可以分析该地址的所有过去和未来活动。同样，Alice 现在知道餐厅的钱包地址，可以利用这些信息获取其他客人的钱包地址或查看餐厅的收入。第三方如果知道餐厅的钱包地址并通过社交媒体得知 Alice 正在用餐，可以轻松推导出 Alice 的地址并研究她的所有交易。
尽管餐厅的例子可能被视为假设场景，但其基本概念适用于公共区块链上的每一笔交易。在公共区块链上执行的每个操作都被公开记录并可供所有人访问，使得第三方能够分析用户的金融交易和行为模式。
这些问题催生了隐私增强协议的出现。这些协议允许用户使用一个地址将资金存入协议，并在稍后使用另一个地址从协议中提取资金。所有存款和提款仍然在区块链上可见，但特定存款与其提款对应关系不再公开。
最著名的隐私增强协议之一是 Tornado Cash。它成功解决了上述问题，允许用户保留一定的隐私。然而，除了试图保护数据的合法用户外，Tornado Cash 也被各种不良行为者使用。存款数据表明，黑客组织通过该协议转移了来自非法来源的资金。证据显示，该隐私增强协议还被朝鲜黑客组织使用，最终导致其智能合约地址被列入美国外国资产控制办公室（OFAC）的特别指定国民与封锁人员名单（SDN 名单）。
本质上，Tornado Cash 的关键问题在于合法用户几乎没有选择将自己与协议吸引的犯罪活动区分开来。Tornado Cash 提供了一个合规工具，允许用户创建证明其提款来自特定存款的证据。虽然这种机制允许人们证明自己的清白，但其代价是需要信任中心化的中介机构，并导致信息不对称。因此，该机制的使用率很低。
本文讨论了对该方法的扩展，使用户能够公开证明关于其提款来源的广泛但信息丰富的声明。它允许成员资格证明（“我证明我的提款来自这些存款之一”）或排除证明（“我证明我的提款不来自这些存款之一”）。这一概念最初由 Privacy Pools 提出。本文讨论了该提案，并解释了如何利用其构建模块在诚实和不诚实协议用户之间实现分离均衡。
需要注意的是，Privacy Pools 通过扩展用户的操作集提供了更多选择。用户仍然可以根据需要向特定对手方提供更详细的证明。然而，在某些情况下，成员资格或排除证明已经足够。此外，公开这些证明的选项比双边披露更具优势。
本文结构如下：在简短介绍后，我们提供了关于零知识证明和 Privacy Pools 的技术背景。在第 3 节中，我们讨论了关联集合的使用和构建。在第 4 节中，我们详细阐述了更多技术细节和特殊情况。在第 5 节中，我们讨论了研究发现并转向实际考虑。最后，在第 6 节中，我们总结了结论。我们鼓励读者探索其他隐私增强提案，这些提案通过不同的实现方式努力实现类似的平衡，例如参考文献。
02 ｜ 技术背景
本节提供了简短的技术概述，并讨论了 Privacy Pools 类协议的技术构建模块和一般原则。
2.1 ZK-SNARKs 之前的区块链隐私
历史上，区块链支持者认为，尽管所有交易都是透明的，但区块链可以通过提供假名性来保护隐私：使用区块链时无需透露任何关于线下身份的信息。相反，用户由数字“地址”标识。
中本聪的比特币白皮书提出了这一观点，认为“通过保持公钥匿名，可以在另一个地方切断信息流以维护隐私。公众可以看到某人向其他人发送了一定数量的比特币，但没有信息将交易与任何人联系起来”。不幸的是，面对现代的聚类和分析工具，这种隐私水平已被证明远远不足。非金融应用使得维护隐私更加困难，因为它们通常要求用户在链上发布其他类型的信息。例如，在 ENS 等去中心化域名服务上注册名称需要在以太坊区块链上进行交易，并在您的交易和 ENS 名称之间建立公开链接。
因此，人们开始通过引入更强大的技术来改善公共区块链上的隐私。最早被广泛采用的非平凡隐私解决方案是 CoinJoin。CoinJoin 涉及一小群用户聚集在一起，在单个交易中混合他们的代币。从链上看，只能看到 CoinJoin 协议一轮的总输入和输出集，而无法确定哪个输入对应哪个输出。理论上，用户可以参与多轮 CoinJoin 协议，与不同的人群混合，从而将资产来源隐藏在众多可能的输入中。
Monero 通过使用可链接的环签名方案进一步推进了这一技术，允许用户在不需任何链下交互的情况下将其代币与其他少数用户的代币混合。随着技术的改进，每轮混合的参与者数量增加，从而提高了每笔交易的匿名集（即该交易可能来源的历史交易数量）。然而，这种重复的小群体混合技术不可避免地存在数据泄露的风险。
在追求更高加密隐私的过程中，下一步逻辑进展是引入通用零知识证明。这一创新在 Zerocash 中得到了体现，并随后被 Zcash 和 Tornado Cash 等链上智能合约系统采用。这种系统允许每笔交易的匿名集可能等于所有先前交易的整个集合。此类通用零知识证明在行业和学术社区中更常被称为“ZK-SNARKs”。
2.2 ZK-SNARKs
ZK-SNARKs 是一种技术，允许证明者在不透露私有数据的情况下，证明关于某些公共数据和私有数据的数学声明，同时满足两个关键属性：
零知识性：除了私有数据满足被证明的声明外，不会透露任何关于私有数据的信息。
简洁性：证明简短（以字节计），并且可以快速验证，即使底层被证明的声明涉及繁重且耗时的计算。
ZK-SNARKs 在区块链社区中因其这两个特性受到了广泛关注。非常耗时和资源密集的是 ZK 系统中使用的公共参数的初始可信设置。然而，整个系统只需执行一次初始可信设置。
在 ZK-rollups 等可扩展性用例中，证明时的简洁性至关重要。对于本文描述的隐私用例，简洁性不那么重要，但零知识性至关重要。
ZK-SNARK 的“声明”通常被称为“电路”。从数学上讲，可以将其视为一个函数 f(x,w)→{True,False}f(x,w)→{True,False}，其中 x 是公共输入，w 是私有输入，f(x)f(x) 是被计算的函数。ZK-SNARK 证明，对于证明者和验证者都已知的给定 x，证明者知道一个 w 使得 f(x,w)f(x,w) 返回 True。
2.3 示例：Zcash 和 Tornado Cash 类系统中的 ZK-SNARKs
Zcash 的不同版本以及受 Zcash 启发的系统（如 Tornado Cash）之间存在微小差异。然而，它们依赖的基本逻辑非常相似。本节描述了一个简单版本，大致对应于这些协议的工作原理。
一个“代币”由其所有者持有的秘密 s 组成。这里的秘密可以是任何仅由所有者知道的数据。可以从 s 派生两个值：
公共“代币 ID” L=hash(s+1)L=hash(s+1)
作废符 U=hash(s+2)U=hash(s+2)
术语 hashhash 指的是加密哈希函数，如 SHA256。给定 s，可以计算出代币 ID 和作废符。然而，给定一组作废符和公共代币 ID，哈希函数的伪随机行为确保除非知道生成两者的秘密 s，否则无法确定哪个作废符与哪个代币 ID 相关联。
区块链跟踪所有已“创建”的代币 ID 和已“花费”的“作废符”。这两个集合都在不断增长（除非协议希望强制执行代币必须花费的时间限制）。
代币 ID 集存储在一个称为 Merkle 树的数据结构中：如果树包含 N 个项目，则每对相邻项目被哈希（生成 ⌈N/2⌉ 哈希），这些哈希的每对相邻哈希再次被哈希（生成 ⌈N/4⌉ 哈希），依此类推，直到整个数据被提交到单个“根哈希”。
给定树中的特定值和根哈希，可以提供一个 Merkle 分支：从该值到根路径上每一步的“姐妹值”。这个 Merkle 分支很有用，因为它是一个小的（log2(N) 哈希）数据片段，可用于证明任何特定值确实在树中。图 1 显示了一个高度为 4 的 Merkle 树示例。
当用户将代币发送给其他人时，他们提供（i）要花费的作废符 U，（ii）要创建的新代币 ID L′（他们会要求接收者提供），以及（iii）一个 ZK-SNARK。
ZK-SNARK 包含以下私有输入：
用户的秘密 s
代币 ID 树中的 Merkle 分支，证明代币 ID L=hash(s+1) 的代币在过去某个时间点确实被创建
它还包含以下公共输入：
U 是要花费代币的作废符
R 是 Merkle 证明检查的根哈希
ZK-SNARK 证明两个属性：
U=hash(s+2)
Merkle 分支有效
在 ZK-SNARK 之外，协议还检查：
R 是代币 ID 树的当前或历史根哈希
U 不在已花费作废符集中
如果交易有效，则将 U 添加到已花费作废符集，并将 L′ 添加到代币 ID 列表。图 2 展示了这一过程。
揭示 U 可以防止单个代币被花费两次。然而，不会透露任何其他信息。外界只能看到交易何时被发送；他们无法获取关于谁发送或接收这些交易，或哪个代币与之前的代币是“同一代币”的信息。
上述模式有两个例外：存款和提款。在存款中，代币 ID 的创建不需要使某些先前的代币失效。存款在某种意义上不保护隐私，因为给定的 L 与允许 L 被添加的外部事件（在 Tornado Cash 中是将 ETH 存入系统；在 Zcash 中是新的 ZEC 代币被挖出）之间的链接是公开的。换句话说，存款与其过去的交易历史相关联。在提款中，作废符被消耗而不添加新的代币 ID。这可以打破提款与相应存款的链接，从而打破与过去交易历史的链接。然而，提款可以与提款事件后发生的任何未来交易相关联 [2]。
Tornado Cash 的第一个版本没有内部转账的概念；它只允许存款和提款。后来的版本（仍处于实验阶段）还允许内部转账和任意面额的代币，包括支持处理任意面额所需的“拆分”和“合并”操作。我们将在后续章节中讨论如何将基本的隐私保护代币转移系统和 Privacy Pools 扩展到任意面额的情况。
2.4 Privacy Pools 中的 ZK-SNARKs
Privacy Pools 的核心思想是：用户不仅零知识证明其提款与某些先前存款相关联，还证明其属于一个更严格的关联集合。关联集合可以是所有先前存款的完整子集，仅包含用户自己的存款的集合，或介于两者之间的任何集合。用户通过提供集合的 Merkle 根作为公共输入来指定集合。
为简单起见，我们不直接证明关联集合实际上是先前存款的子集；相反，我们只要求用户零知识证明两个 Merkle 分支，使用相同的代币 ID 作为两者的叶子：（i）一个 Merkle 分支进入 R（代币 ID 的总根），（ii）一个 Merkle 分支进入提供的关联集合根 RA。图 3 展示了这一点。
意图是整个关联集合将在某个地方可用，无论是在链上还是其他地方。这是核心概念：不是要求用户明确指定其提款来自哪个存款，或者在另一个极端完全不提供任何信息（除了证明非双重花费），我们让用户提供一组可能的资金来源，这个集合可以根据他们的意愿尽可能宽泛或狭窄。我们鼓励形成一个生态系统，使用户更容易指定符合其偏好的关联集合。本文的其余部分将仅描述基于这一简单核心机制的基础设施及其后果。
03 ｜ 实际考虑与用例
在技术介绍之后，我们现在转向应用层面，分析隐私增强协议如何在实践中使用。
3.1 关联集合的用例
为了说明该方案在执法背景下的价值，让我们考虑一个简单的例子。假设我们有五个用户：Alice、Bob、Carl、David 和 Eve。前四个是诚实、守法的用户，他们希望保护自己的隐私，而 Eve 是一个小偷。假设这也是公开已知的。公众可能不知道 Eve 的真实身份，但他们有足够的证据得出结论，发送到我们标记为“Eve”的地址的代币是被盗的。这在实践中经常发生：大多数流入 Tornado Cash 的非法资金来自 DeFi 协议漏洞利用，这一事件在公共区块链上是可见的。
当每个用户提款时，他们可以选择指定的关联集合。他们的关联集合必须包含自己的存款，但可以自由选择包含哪些其他地址。让我们首先考虑 Alice、Bob、Carl 和 David 的动机。一方面，他们希望最大化隐私。这促使他们扩大关联集合。另一方面，他们希望减少其代币被商家或交易所视为可疑的可能性。他们有一个简单的方法来实现这一点：不将 Eve 包含在他们的关联集合中。因此，对于所有四个人来说，选择很明确：使他们的关联集合为 {Alice, Bob, Carl, David}。
当然，Eve 也希望最大化她的关联集合。然而，她无法排除自己的存款，因此被迫使她的关联集合等于所有五个存款的集合。参与者的关联集合选择如图 4 所示。
尽管 Eve 自己没有提供任何信息，但通过简单的排除过程，我们可以做出明确的推断：提款 #5 只能来自 Eve。
3.2 关联集合的构建
上一节说明了在 Privacy Pools 类协议中使用关联集合的一种可能方式，以及诚实参与者如何与不良行为者区分开来。需要注意的是，该系统不依赖于 Alice、Bob、Carl 和 David 的利他行为；他们有明确的动机证明他们的分离。
现在，让我们更仔细地看看关联集合的构建。一般来说，生成关联集合有两种主要策略。它们描述如下，并在图 5 中可视化。
包含（或成员资格）：识别一组特定的存款，我们有具体证据认为它们是低风险的，并构建一个仅包含这些存款的关联集合。
排除：识别一组特定的存款，我们有具体证据认为它们是高风险的，并构建一个不包含这些存款的关联集合。
在实践中，用户不会手动选择存款来包含在他们的关联集合中。相反，用户将订阅中介机构，我们可以称之为关联集合提供者（ASPs），这些提供者生成具有某些属性的关联集合。在某些情况下，ASPs 可以完全在链上构建，无需人工（或 AI）干预。在其他情况下，ASPs 会自行生成关联集合，并将这些集合发布在链上或其他地方。
我们强烈建议至少将关联集合的 Merkle 根发布在链上；这消除了恶意 ASPs 对用户进行某些类型攻击的能力（例如，通过向不同用户提供不同的关联集合来试图去匿名化他们）。整个集合应通过 API 或理想情况下通过低成本去中心化存储系统（如 IPFS）提供。
下载整个关联集合的能力很重要，因为它允许用户在本地生成关联集合的成员资格证明，而无需向 ASP 透露任何额外信息，即使关于哪个存款对应于他们正在进行的提款。
以下是 ASPs 在实践中可能运作的一些构建方式：
延迟添加，排除不良行为者：任何存款在固定时间段（例如 7 天）后自动添加到关联集合；然而，如果系统检测到某个存款与已知的不良行为（例如大规模盗窃或政府发布的制裁名单上的地址）相关联，则该存款永远不会被添加。在实践中，这可以通过社区策划的集合或现有的交易筛选服务提供商来实现，这些提供商已经负责识别和跟踪与不良行为相关的存款。
每人每月固定金额：要加入关联集合，存款的价值必须小于固定最大值，并且存款人必须零知识证明他/她持有某种人格证明代币（例如政府支持的国家 ID 系统或更轻量级的机制，如社交媒体账户验证）。为了防止 Sybil 攻击（支付结构化），使用作废符机制，并混合一个代表当前月份的额外参数，以确保每个身份每月只能向关联集合提交一次存款。这一设计试图实现当今许多常见反洗钱（AML）规则的精神，其中低于特定阈值的小额支付被允许享有比大额支付更高的隐私级别。需要注意的是，这可以完全作为智能合约实现，无需人工监督来维持持续运行。
每位受信任社区成员每月固定金额：与“每人每月固定金额”相同，但更严格：用户必须证明属于高信任社区。高信任社区同意其成员彼此提供隐私。
实时基于 AI 的评分：AI ASP 系统可以实时为每笔存款提供风险评分，系统将输出一个关联集合，包含风险评分低于特定阈值的存款。可能，ASP 可以输出对应于多个风险评分阈值的多个集合。
04 ｜ 进一步技术细节
本节分析了该提案如何支持任意面额，并讨论了重新证明、双边直接证明和顺序证明等特殊情况。
4.1 支持任意面额
前述简化的隐私保护代币系统仅支持相同面额的代币转移。Zcash 使用未花费交易输出（UTXO）模型支持任意面额。每笔交易可以有多个输入（需要为每个输入发布作废符）和多个输出（需要为每个输出发布代币 ID）。每个创建的代币 ID 必须附带加密的面额值。除了证明作废符的有效性外，每笔交易还必须附带一个额外的证明，证明被创建的代币的面额总和不超过被花费代币的面额总和。图 6 展示了这一额外证明。
这一设计可以通过将存款视为（未加密的）输入，将提款视为（未加密的）输出来扩展到支持存款和提款。或者，可以限制设计以简化分析。例如，可以仅允许部分提款，允许交易具有一个加密输入和两个输出：一个未加密的输出代表提款，一个加密的“找零”输出代表剩余资金，可用于未来的提款。
一个自然的问题是，如何将这一设计扩展到支持 Privacy Pools。简单地将其“原样”插入 Privacy Pools 并不理想，因为交易图与我们直观期望的不一致：如果用户存入 10 个代币，然后分四次提款 1+2+3+4 个代币，我们希望将所有四次提款视为以原始的 10 个代币存款为来源。但我们得到的是图 7 所示的情况：第一次提款以 10 个代币存款为来源，但第二次提款以第一次提款创建的 9 个代币找零输出为来源，依此类推。这在实践中会导致问题，因为 ASP 必须验证中间存款并将其添加到其关联集合中。
如果我们希望本例中的所有四次提款都能够声称原始的 10 个代币存款为来源，我们需要同时解决两个问题：（i）确保每个部分提款不会公开链接到其他提款，（ii）允许每个部分提款将存款作为其关联集合的成员。
如果我们仅支持部分提款（而不是更复杂的多输入/多输出交易），确保每次提款有一个明确定义的对应“原始存款”，那么我们可以通过多种方式直接实现这一点。一种自然且非常可扩展的方法是通过交易传播某些信息的承诺。例如，我们可以要求交易包含一个诺 hash(coinID+hash(r))hash(coinID+hash(r))，添加一些随机值 rr 以实现盲化，并要求 ZK-SNARK 证明交易中的承诺与其父级承诺相同的值（如果父级本身是提款），或者简单地承诺原始存款的代币 ID（如果父级是存款）。因此，链中的每个交易都必须包含对原始存款代币 ID 的承诺，并且该值将被证明包含在交易提供的关联集合中。
为了改善针对余额求和攻击的隐私性（例如，如果我存入 10 个代币，然后提取 7.2859 和 2.7141，这两次提款可以仅基于金额进行关联），我们可能还希望支持代币合并：如果我有一些剩余代币，我可以将它们与下一次存款合并。为了适应这种情况，我们可以要求交易承诺一组代币 ID，并要求具有多个输入的交易承诺其父级的并集。提款将包含一个证明，证明其所有承诺的代币 ID 都在其关联集合中。
4.2 特殊情况
4.2.1 重新证明
要从 Privacy Pools 类协议中提取存款，用户需要秘密存款信息 s。相同的秘密信息随后用于构建关联集合成员资格证明。考虑一种情况：Alice 提取了她的资金，并创建并发布了一个关联集合成员资格证明。后来，她希望在一个要求针对不同集合的证明的商家处花费她的资金。只要 Alice 保留她的秘密信息，她将能够针对商家的关联集合生成新的证明。类似地，Alice 可以针对初始关联集合的更新版本生成新的证明。保留秘密信息为 Alice 提供了更多的灵活性，但如果秘密在任何时候泄露，可能会增加 Alice 隐私泄露的风险。
另一种情况出现在对特定事件的调查中。假设发生了一些涉及链上代币的不良行为，初步调查揭示了一组这些代币可能来源的输入。这可能是因为相关代币来自一个关联集合为小社区的提款，或者是由于链上证据和其他证据的结合揭示了事件背后者的部分信息。在这种情况下，其他成员可能希望证明他们与该事件的分离以证明自己的清白，而肇事者的身份将被揭示。或者，如果一个事件存在争议，但许多人即使不是责任人也支持它，他们可能拒绝提供此类证明。
4.2.2 双边直接证明
在某些情况下，用户可能需要向另一方披露其提款的精确来源。例如，如果 Alice 希望将提取的资金存入银行，银行可能会要求提供关于资金来源的完整信息。作为回应，Alice 可以创建一个仅包含其存款的关联集合，并针对该集合构建证明。我们预计这些证明将是例外，并且只有在双边共享时才能为部分隐私做出贡献。此外，共享此证明假设接收方不会进一步分发该证明的强信任假设。
另一个更高级的选项是 Alice 零知识证明以下陈述之一为真：（i）“此提款在此关联集合中”，（ii）“我是银行”，或（iii）“根据此特定时间戳服务（可以是服务器或区块链），此证明的创建已超过 10 秒”。只有银行在实时接收证明（iii）并知道他们自己没有创建证明（ii）时，才能信任该证明：如果证明落入他人之手，接收方将难以相信证明未被伪造。这消除了关于隐私泄露的大部分对手方风险。
4.2.3 顺序证明
让我们想象一个长期未来的场景，其中 Privacy Pools 类系统不仅偶尔使用，而是在绝大多数交易中使用。这是 Zeash 等隐私优先系统所期望的世界。它引入了一些在 Privacy Pools 偶尔使用的世界中不会出现的新复杂性。
为了适应这样的世界，需要进行以下协议修改：除了存款和提款交易类型外，协议还需要支持内部发送操作，该操作消耗现有的代币 ID 并生成由其他人拥有的新代币 ID。从协议分析的角度来看，这等同于发送者提款到接收者的地址，然后接收者立即重新存款，但它通过将步骤和链上证明从两个减少到一个来提高效率。
假设 Alice 发送一个代币给 Bob；即，她进行一个内部发送，部分消耗 Alice 拥有的代币 ID，并创建一个参数由 Bob 提供的新代币 ID。Bob 然后希望立即花费该代币，将其发送给 Carl，并且他希望他的支出交易也是私密的。在这里，我们面临挑战：包含延迟。在我们上面提出的许多配置中，ASPs 不愿意立即将 Bob 的新代币添加到他们的关联集合中，因为他们需要观察资金的来源不是 Alice，而是刚刚从 Alice 的钱包中窃取资金的人。包含延迟是为了给 Alice 时间报告事件或第三方时间检测事件。
在另一个类似的用例中，“Alice”是一个 DeFi 协议，Bob 希望从 DeFi 协议中提取资金并立即使用这些资金私下支付给 Carl。这一场景少了一个人，但在结构上非常相似。
在快速交易的经济中，相同的资金可能每周甚至更频繁地流动多次，包含延迟将构成严重挑战。针对这一问题的一个可能的解决方案如下：在用户钱包中没有代币“成熟”到足以被包含在相关关联集合中的情况下，用户可以通过非隐私保护交易发送它们。然而，我们提出了另一种泄露信息更少的替代方案。
当 Bob 支付 Carl 时，Bob 还直接向 Carl 提供用于生成支付的 Merkle 分支和秘密。这使得 Carl 可以看到 Bob 所看到的内容：来自 Alice 的支付在代币的历史中。如果后来发现大量与某些不良行为者相关的代币被存入并迅速重新流通，Carl 将能够证明他的代币来自一个与不良行为者无关的最终来源。
如果 Carl 随后将代币发送给 David，他将传递来自 Bob 的 Merkle 分支和秘密，并添加自己的。现在，假设 David 接下来将他的代币发送给 Emma，但当他这样做时，Alice 的存款已被添加到关联集合中。那么，David 不再需要提供来自 Alice 的 Merkle 分支或秘密；相反，他可以简单地代表 Alice 生成一个关联集合成员资格证明。一旦 Bob 的支付被添加到关联集合中，Bob 的 Merkle 分支和秘密同样变得过时。这一概念围绕确保每个用户仅获取对接收资金所需的最小必要信息以建立信心。图 8 说明了这一示例。
05 ｜ 讨论
5.1 社会共识与关联集合
如果对哪些资金是“好”的和哪些是“坏”的存在完美共识，系统将导致简单的分离均衡。所有拥有“好”资产的用户都有强烈的动机和能力证明他们属于“仅好”关联集合的成员资格。另一方面，不良行为者将无法提供该证明。他们仍然可以将“坏”资金存入池中，但不会为他们带来任何好处。每个人都可以轻松识别资金是从隐私增强协议中提取的，并看到提款引用了包含可疑来源存款的关联集合。更重要的是，“坏”资金不会污染“好”资金。当来自合法存款的资金被提取时，其所有者可以简单地从其关联集合中排除所有已知的“坏”存款。
在不存在全球共识且资金被视为“好”或“坏”取决于社会观点或司法管辖区的情况下，关联集合可能差异很大。假设有两个具有不同规则集的司法管辖区。根据司法管辖区，A 和 B 都可以使用相同的隐私增强协议，并选择发布满足各自司法管辖区要求的证明。两者都可以轻松地在其自己的关联集合内实现隐私，并排除不符合各自司法管辖区要求的提款。如果需要，可以发布针对两个关联集合的交集的成员资格证明，从而可信地证明与其提款对应的存款符合两个司法管辖区的要求。
因此，该提案非常灵活，应被视为中立的基础设施。一方面，它是抗审查的。它允许任何人选择加入他们选择的关联集合，并在自己的社区内保持隐私。另一方面，外部人可以要求针对符合其监管要求的特定关联集合的证明。因此，即使隐私增强协议中存在不良行为者社区，只要信息准确反映在关联集合的构建中，他们也无法混淆存款的可疑来源。
5.2 关联集合的属性
关联集合需要某些属性才能有效。这些集合需要准确，以便用户可以信任他们在提取资金后可以安全地花费资金。此外，每个集合的属性应该是稳定的，意味着它们不太可能随时间变化。这限制了对新集合重新证明提款的需求。最后，为了实现有意义的隐私，确保关联集合足够大并包含各种存款非常重要。然而，这些特性相互冲突。一般来说，大而多样化的集合可能具有更好的隐私属性，但可能不太准确和稳定，而较小的集合更容易维护但提供较少的隐私。
5.3 实际考虑与竞争
接受加密资产的受监管实体必须确保他们遵守的法律和法规允许接受此类资金。如今，许多这些实体依赖所谓的交易筛选工具：软件或服务，分析区块链以识别潜在可疑活动、与非法地址的连接或其他不合规交易。筛选工具通常通过风险评分表达与每笔交易相关的风险。该评分基于传输资金的目的地及其交易历史。隐私增强协议在这方面可能构成挑战。它们消除了存款和提款之间的可见链接。因此，在存在隐私增强协议的情况下，风险评分必须考虑证明并根据关联集合分配评分。
交易筛选的工具和服务主要由在区块链分析和相关法律领域具有专业知识的专业公司提供。理想情况下，这些公司（以及其他人）可以访问所有成员资格证明及其对应的关联集合，以提供跨所有交易的准确风险评分。因此，我们建议将所有证明存储在区块链上或其他公开可访问的证明存储库中。唯一的例外是仅与特定对手方共享的大小为一的成员资格证明。出于显而易见的原因，这些证明不应公开可用。
将证明随时可用地存储在链上引入了额外的交易成本，但减少了协调工作，平衡了竞争环境，并减轻了筛选工具提供商由于了解非公开证明而可能形成的准垄断风险。
Privacy Pools 的一般设置非常灵活。通过创建特定的关联集合，可以定制协议以适应各种用例。以下是此类专门关联集合的两个示例。（i）商业银行联盟可以创建一个仅包含其客户存款的关联集合。这保证了任何针对该集合创建证明的提款都经过了其中一家银行的了解您的客户（KYC）和反洗钱（AML）程序，但不会揭示哪个提款属于哪个客户。（ii）在金融中介必须记录资金确切来源的情况下，他们可以要求用户提供仅包含用户存款的关联集合的证明。然后，该证明与中介双边交换，使他们能够像用户从未使用 Privacy Pools 一样跟踪资金。虽然这要求用户信任中介不会披露证明，但理想情况下，它允许用户在不向公众披露信息的情况下遵守法规。
5.4 设计选择与替代方案
基于关联集合、ZK 证明和自愿披露的设置非常灵活。虽然这对于确保提案可以适应各种司法管辖区非常有用，但在特定设计选择上应非常谨慎。特别是，我们反对两种潜在的调整。我们认为它们在信任要求方面存在问题，并可能产生准垄断的市场结构。
以下我们简要描述并讨论这些替代方法。
集中式访问：执法机构、加密风险评分提供商或类似行为者可以访问查看用户交易之间的链接，而对其他人保持隐私。
系统范围的入口允许列表：隐私系统可以限制哪些类型的用户可以将其代币存入其池中，要么要求他们提供额外的证明，要么要求存款等待一段时间，在此期间集中式风险评分系统可以拒绝存款。
这两种方法非常相似，因为它们赋予特定实体特殊权限。这将导致复杂的治理问题：谁可以访问这些信息？谁有权管理权限？
私营企业似乎不是一个好的选择，因为任何特殊权限都可能产生寡头垄断的市场结构，少数公司可以访问允许他们提供这些服务的数据，而其他所有人都无法竞争。
同样，如果将权力赋予公共机构，特别是在国际背景下，将会有许多治理和政治问题。即使今天 100% 可信的机构获得了后门密钥，不会滥用这种权力用于政治议程，并且没有依赖于可能迫使其滥用权力的其他实体，认为这是一个静态游戏是天真的。组织、其成员、国家以及组织内的政治结构随时间而变化。可能存在外部压力，这些特殊权限的存在可能会激励不良行为者破坏并获得对组织治理系统的影响。
此外，来自组织内部或外部的攻击，或集中式实体代表的错误，可能会产生深远的影响。我们认为应防止创建这样一个中心故障点。
也就是说，我们承认不同的交易规模和情况可能需要不同的证明组合。例如，对于大额交易，许多用户最终可能会在链上提供基本的排除证明，并向其对手方提供有关来源的更详细信息。
5.5 进一步研究潜力
虽然本研究概述了基于 ZK-SNARK 的隐私增强协议如何在受监管环境中使用，但有几个领域值得进一步调查。
首先，重要的是要意识到通过这些协议获得的隐私取决于许多不同的因素。关联集合不足够大、根选择不当以及用户错误可能使专门的攻击者能够将提款链接到特定存款。此外，其他用户的选择可能会对您自己的隐私产生不利影响。在极端情况下，池中的其他所有人都会发布大小为 1 的成员资格证明，揭示其存款和提款之间的直接链接。显然，这将隐式揭示唯一剩下的存款和提款交易之间的链接。在更微妙的例子中，各种成员资格证明的约束可用于提取信息，并可能以高概率链接存款和提款。一旦将这些证明的信息与交易元数据结合，协议的隐私属性可能会被破坏。最后，恶意 ASP 可以选择以最大化可提取信息或通过添加已知对应提款的存款来夸大感知匿名性的方式编译提议的关联集合。所有这些问题都需要进一步研究以评估所提供的隐私属性。类似地，进一步研究分离均衡的属性，模拟好和不良行为者在某些假设下的行为，以及前者的公开证明如何影响后者的隐私，将是有趣的。
最后，法律学者可以进一步调查具体的披露要求。本文概述的提案高度可适应，法律专家的见解可以帮助定制协议及其周围的生态系统，以确保跨各种法律管辖区的合规性。
06 ｜ 结论
在许多情况下，隐私和监管合规被视为不兼容。本文表明，如果隐私增强协议使其用户能够证明关于其资金来源的某些属性，这不一定成立。例如，假设用户可以证明其资金与已知非法来源的存款无关，或证明资金属于特定存款集合而不透露任何进一步信息。
这样的设置可以生成一个分离均衡，其中诚实用户有强烈的动机证明属于给定的合规关联集合的成员资格，同时仍在该集合内享受隐私。相反，对于不诚实的用户，提供这样的证明是不可能的。这使得诚实用户可以与他们不同意或可能阻止他们在受监管环境中使用其资金的第三方存款分离。我们认为该提案非常灵活，可以适应可能满足各种监管要求。
本文应被视为对金融隐私和监管可能共存的潜在未来的谦逊贡献。我们希望促进讨论，并将对话转向更积极和建设性的方向。从业者、来自各个领域的学者、政策制定者和监管机构之间的合作将需要扩展和修改这一提案，最终目标是创建可以在受监管环境中使用的隐私增强基础设施。
竞争利益声明
作者声明以下财务利益/个人关系，可能被视为潜在的竞争利益：本文分析了 Privacy Pools 类设置。Ameen Soleimani 是 Privacy Pools 的开发者。
07 ｜ 致谢
特别感谢 Mitchell Goldberg、Katrin Schuler 和 Dario Thirkrauf 的宝贵意见，Emma Littlejohn 的校对，以及 Dario Thirkrauf 对图形设计的支持。
08 ｜ 参考文献
[1] Z. Wang, S. Chaliasos, K. Qin, L. Zhou, L. Gao, P. Berrang, B. Livshits, A. Gervais, On how zero-knowledge proof blockchain mixers improve, and worsen user privacy, arXiv preprint arXiv:2001.09035, https://doi.org/10.48550/arxiv.2201.09035.
[2] M. Nadler, F. Schia, Tornado cash and blockchain privacy: a primer for economists and policymakers, Fed. Reserve Bank St. Louis Rev. 105 (2) (2023) 122-136, https://doi.org/10.20955/r.105.122.136.
[3] A. Soleimani, Privacy pools, gitHub repository, https://github.com/ameensol/privacy-pools, 2023.
[4] J. Beal, B. Fisch, Derecho: privacy pools with proof-carrying disclosures, CryptologyePrint Archive, https://eprint.iacr.org/2023/273, 2023.
[5] S. Nakamoto, Bitcoin: a peer-to-peer electronic cash system, https://bitcoin.org/bitcoin.pdf, 2008.
[6] S. Meiklejohn, M. Pomarole, G. Jordan, K. Levchenko, D. McCoy, G.M. Voelker, S.Savage, A fistful of bitcoins: characterizing payments among men with no names,in: Proceedings of the 2013 Conference on Internet Measurement Conference IMC’13, ACM, 2013, pp. 127–140, https://doi.org/10.1145/2504730.2504747.
[7] C. Kang, C. Lee, K. Ko, J. Woo, J.W. Hong, De-anonymization of the bitcoin network using address clustering, in: Blockchain and Trustworthy Systems, Springer,Singapore, 2020, pp. 489–501, https://doi.org/10.1007/978-981-15-9213-3_38.
[8] Ethereum name service, decentralised naming for wallets, websites, & more, https://ens.domains/, 2023.
[9] G. Maxwell, Coinjoin: bitcoin privacy for the real world, https://bitcointalk.org/?topic=279249, 2013.
[10] J.K. Liu, V.K. Wei, D.S. Wong, Linkable spontaneous anonymous group signature forad hoc groups, in: Information Security and Privacy, Springer, Berlin, Heidelberg,2004, pp. 325–335, https://doi.org/10.1007/978-3-540-27800-9_28.
[11] B. Goodell, S. Noether, A. Blue, Concise linkable ring signatures and forgery againstadversarial keys, https://eprint.iacr.org/2019/654, 2019.
[12] M. Moser, K. Soska, E. Heilman, et al., An empirical analysis of traceability in themonero blockchain, https://arxiv.org/pdf/1704.04299/, 2018.
[13] E. Ben Sasson, A. Chiesa, C. Garman, M. Green, I. Miers, E. Tromer, M. Virza, Zerocash: decentralized anonymous payments from bitcoin, in: Proceedings of the2014 IEEE Symposium on Security and Privacy, IEEE, 2014, pp. 459–474, https://doi.org/10.1109/SP.2014.36.
[14] Zcash, https://z.cash/, 2023.
[15] V. Buterin, An incomplete guide to rollups, https://vitalik.ca/general/2021/01/05/rollup.html, 2021.
[16] M. Petkus, Why and how zk-snark works, CoRR, arXiv:1906.07221, 2019.
[17] A. Berentsen, J. Lenzi, R. Nyffenegger, An introduction to zero-knowledge proofsin blockchains and economics, Fed. Reserve B
