---
# System prepended metadata

title: 区块链隐私与监管合规：迈向实际的平衡
tags: [Privacy, Blockchain, Smart Contract]

---

> 翻译自：https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4563364


<br>

**摘要** - 本文研究了隐私池，这是一种基于智能合约的新型隐私增强协议。我们讨论了该协议的优缺点，并展示了如何利用它在诚实用户和不诚实用户之间建立分离均衡。该提议的核心思想是允许用户发布零知识证明，以证明其资金（不）来自已知的（非）合法来源，而无需公开披露其整个交易图。这是通过证明在满足监管或社会共识所要求的某些属性的自定义关联集中的成员资格来实现的。该提议可能是迈向未来的第一步，在未来人们可以证明合规性而无需披露其整个交易历史。

> 关键词 - 区块链、隐私、监管、智能合约、零知识证明。

<br>

## 一、引言

公共区块链在设计上具有透明性。其基本理念是，任何人都应有权选择在无需依赖中心化第三方的情况下验证交易。这减少了对第三方的依赖，并可能为包括但不限于金融和自主身份等各种应用提供一个中立的基础。

然而，从隐私角度来看，存在一个包含每个区块链地址的每笔交易的公共数据集是有问题的。每当有人向另一个地址转移资产，和/或与智能合约进行交互时，该交易将永远在区块链上可见。

考虑以下示例：Alice 去一家餐厅，并用她的区块链钱包支付晚餐费用。收款人现在知道了 Alice 的地址，并可以分析该地址过去和未来的所有活动。同样，Alice 现在知道了餐厅的钱包地址，并可以利用这些信息获取其他客人的钱包地址，或调查餐厅的收入情况。知道餐厅钱包地址，并且知晓Alice 在那里用餐信息（例如从社交媒体得知）的第三方，也可以轻松推断出 Alice 的地址，并研究她过去和未来的交易。

尽管餐厅的例子可能被视为一种假设情景，但基本概念适用于在公共区块链上进行的每一笔交易。在公共区块链上执行的每一个动作都会被公开记录，任何人都可以访问，这使得第三方能够分析用户的金融交易和行为模式。

这些问题导致了隐私增强 (*privacy-enhancing*) 协议的兴起。它们允许用户使用一个地址将资金存入协议，并在稍后的某个时间使用另一个地址从协议中提取资金。所有的存款和取款在区块链上仍然可见，但特定存款与其取款对应项之间的联系不再公开。

最著名的隐私增强协议之一是 **Tornado Cash**。它成功解决了上述问题，允许用户保留一定的隐私。然而，除了试图保护其数据的合法用户外，Tornado Cash也被各种不良行为者使用。存款数据表明，黑客组织通过该协议转移了来自非法来源的资金。有证据表明，一个朝鲜黑客组织也使用了该隐私增强协议，这最终导致该协议的智能合约地址被列入美国外国资产控制办公室（OFAC）维护的特别指定国民和被封锁人员名单（通常称为SDN名单）。

Tornado Cash的关键问题本质上在于，合法用户几乎没有办法与该协议所引发的犯罪活动撇清关系。Tornado Cash提供了一项合规功能，允许用户创建证据，证明某笔取款来自哪笔存款。虽然这种机制确实能让人们证明自己的清白，但代价是必须信任一个中心化的中介机构，并且会造成信息不对称$^{[1]}$。因此，这种机制鲜少被使用。

本文探讨了对该方法的一种扩展，该扩展使用户能够公开证明一个信息丰富但仍较为宽泛的声明，即其提款可能来自哪些存款。它支持

1. **成员资格证明** (*membership proofs) :* “我证明我的取款来自这些存款中的一笔”。或 
2. **排除证明** (*exclusion proofs) :* “我证明我的取款并非来自这些存款中的一笔”。

这一通用概念由隐私池（Privacy Pools）提出$^{[2]}$。本文对该提议进行了讨论，并解释了如何利用其组成部分在诚实和不诚实的协议用户之间实现分离均衡。

请注意，隐私池通过扩展用户的操作集提供了额外的选择。如果需要，用户仍然可以向特定的交易对手提供更详细的证明。不过，在某些情况下，成员资格证明或排除证明可能就已足够。此外，与双边披露相比，公开发布这些证明的选项确实具有许多优势。

本文结构如下。在这个简短的介绍之后，我们给出零知识证明和隐私池的技术背景。在第三节中，我们讨论关联集的使用和构建方式。在第四节中，我们详细阐述进一步的技术细节和特殊情况。在第五节中，我们讨论我们的研究结果，并转向实际考虑因素。最后，在第六节中，我们进行总结。
<br>

## 二、技术背景

在本节中，我们将提供一个简短的技术概述，并讨论类似隐私池协议的技术组件和一般原则。

### A. ZK-SNARKs 出现之前的区块链隐私

从历史上看，区块链的支持者认为，尽管所有交易都是透明的，但区块链仍能保护隐私，因为它们提供了匿名性：使用区块链时，你无需透露任何有关线下身份的信息。相反，用户由数字 “地址” 来标识。
中本聪（Satoshi）的比特币白皮书就提出了这一确切主张，认为 “通过在另一个地方切断信息流仍可维护隐私：即保持公钥匿名。公众可以看到有人在向其他人发送一笔金额，但没有将该交易与任何人相关联的信息” $^{[3]}$。不幸的是，面对现代聚类和分析工具，这种程度的隐私已被证明远远不够 $^{[4][5]}$。非金融应用使得维护隐私变得更加困难，因为它们通常要求用户在链上发布关于自己的其他类型信息。例如，在诸如以太坊名称服务（ENS）$^{[6]}$ 这样的去中心化域名服务上注册一个名称，涉及在以太坊区块链上进行一笔交易，从而在你的交易和你的 ENS 名称之间建立一个公开链接。

出于这个原因，通过引入更强大的技术，出现了一股在公共区块链上改善隐私的趋势。最早获得显著采用的有重要意义的隐私解决方案是 CoinJoin $^{[7]}$。CoinJoin 涉及一小群用户聚集在一起，在一笔交易中相互混合他们的加密货币。从区块链上看，人们只能看到 CoinJoin 协议某一轮的全部输入和输出集合，而无法得知哪个输入对应哪个输出。其理论是，用户可以与不同的人群参与多轮 CoinJoin 协议，从而在众多可能的输入中隐藏其资产的来源。门罗币（Monero）更进一步，使用可链接环签名方案$^{[8]}$，允许用户在无需任何链下交互的情况下，将自己的加密货币与其他一些用户的加密货币混合。随着技术的改进$^{[9]}$，每次混合中的参与者数量增加，扩大了每笔交易的**匿名集**：即可能是该笔交易起源的历史交易。然而，这种重复的小群体混币技术不可避免地仍然存在数据泄露风险$^{[10]}$。

在追求增强加密隐私方面的下一个合理进展涉及引入通用零知识证明，就像在Zcash等区块链$^{[11]}$以及Tornado Cash等链上智能合约系统中所使用的那样。此类系统使得每笔交易的匿名集有可能等同于之前所有交易的完整集合。这里应用的这种通用零知识证明在行业和学术界更常被称为“**零知识简洁非交互式知识论证（ZK-SNARKs）**”。 

### B. ZK-SNARKS

ZK-SNARKs 是一种技术，它允许证明者对其持有的公共数据和私有数据的某种组合进行数学断言证明，且满足两个关键特性：

- 零知识：除了私有数据满足正在被证明的断言这一事实外，不会泄露任何关于私有数据的信息。
- 简洁性：证明简短（以字节为单位），并且可以非常快速地验证，即使正在被证明的底层断言涉及到需要很长时间才能运行完成的繁重计算。

由于这两个原因，ZK-SNARKs 在区块链社区中受到了广泛关注。简洁性方面在 ZK-SNARKs 用于可扩展性的用例中至关重要，例如零知识汇总（ZK - rollups）$^{[12]}$。对于我们在此描述的隐私用例，简洁性并非那么重要，但零知识方面却是必不可少的。

ZK-SNARK 所证明的“断言”被表示为一种通常称为“电路”的程序类型。从数学角度来看，将其视为函数 $f(x, w) → \{True, False\}$ 即可，其中 $x$ 是公共输入，$w$ 是私有输入，$f(.)$ 是正在计算的函数。ZK-SNARK 证明，对于证明者和验证者都已知的给定 $x$，证明者知道一个 $w$，使得 $f(x, w)$ 返回 $True$。

> 有关 ZK-SNAKRS 的更全面介绍，请参阅 [13] 和 [14]



### C. 示例：Zcash和类似Tornado Cash系统中的 ZK-SNARKs

不同版本的Zcash之间，以及受Zcash启发的不同版本系统（如Tornado Cash）之间存在细微差异。然而，它们所依赖的基本逻辑非常相似。本节描述一个简单版本，大致对应于这些协议的工作方式。
一个 “coin” 由其所有者持有的秘密值 $s$ 组成。可以从s推导出两个值：

- 公开的“coin ID”:  $L = hash(s + 1)$
- The nullifier:  $U = hash(s + 2)$

术语“hash”指的是一种加密哈希函数，例如SHA256。给定 $s$ ，你可以计算出coin ID和nullifier。然而，给定一组nullifier和公开的coin ID，哈希函数的伪随机特性确保你无法判断哪个nullifier与哪个coin ID相关联，除非你知道生成这两者的秘密值 $s$ 。

区块链会记录所有已经“创建”的coin ID，以及所有已经“花费”的“nullifier”。这两个集合都在不断增长（除非协议希望对硬币必须被花费的时间设置限制）。

coin ID集合存储在一种称为默克尔树的数据结构中：如果树包含N个元素，那么每对相邻元素会被哈希（产生 $[N/2]$ 个哈希值），这些哈希值的每对相邻值又会被哈希（产生 $[ N/4 ]$ 个哈希值），依此类推，直到整个数据被压缩成单个“根哈希值”。

给定树中的一个特定值和一个根哈希值，就可以提供一个默克尔分支：即从该值到根的路径上每一步与该值一起进行哈希运算的“姐妹值”。这个默克尔分支很有用，因为它是一小段（$log_2$(N)个哈希值）数据，可用于证明任何特定值确实在树中。图1展示了一个高度为4的默克尔树示例。

![image](https://hackmd.io/_uploads/r1VOQlNSgl.png)

> 图1：默克尔树的结构，突出显示树中给定值的默克尔分支。橙色部分是正在被证明的叶节点 L；树的最底层代表整个数据集。绿色部分是根哈希值R。蓝色部分是从叶节点到根节点的路径。紫色部分是每一层的姐妹节点。请注意，该路径可以从叶节点开始计算，将其与每一层的姐妹节点一起进行哈希计算，因此无需提供路径本身。
> 

当用户向他人发送一枚硬币时，他们需提供：（i）他们想要花费的nullifier $U$；（ii）他们想要创建的新硬币的coin ID $L'$（他们会要求接收者提供此ID）；以及（iii）一个ZK-SNARK。

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

- 用户的秘密值 s ；
- coin ID树中的一个默克尔分支，用于证明coin ID为$L = hash(s + 1)$ 的硬币确实是在过去某个时刻创建的。

它还包含以下公共输入：

- U，被花费硬币的nullifier
- R，默克尔证明所对照的根哈希。

ZK-SNARK证明了两个属性：

- U = hash(s + 2)；
- 默克尔分支有效；

在 ZK-SNARK 之外，该协议还检查：

- R 是coin ID树的当前或历史根哈希；
- U 不在已花费 nullifier 集合中；

如果交易有效，它会将 U 添加到已花费nullifier集合中，并将 L' 添加到硬币ID列表中。

![image](https://hackmd.io/_uploads/SkE3Qg4rxl.png)

> 图2：隐私保护硬币转移系统中涉及的一些数据结构。所示的默克尔树是coin ID树；未显示nullifier集合，但它也存储在链上。当特定硬币存在但尚未被花费时，coin ID（L）在链上，但其秘密值（s）和nullifier（ U）仅由硬币持有者所知晓。
> 

揭示U可防止单个硬币被花费两次。无论怎样，这不会泄露其他信息。外界所能看到的仅仅是交易何时被发送；他们无法得知是谁在发送或接收这些交易，也无法知晓哪枚硬币与之前的哪枚硬币是“同一枚硬币”。

上述模式有两个例外：***deposits*** 和 ***withdrawals***。在 deposit 操作中，创建一个coin ID时无需使之前的某个硬币失效。deposit 操作并不具备隐私保护性，因为特定的 L 与允许添加该 L 的外部事件之间的关联是公开的（在Tornado Cash中，是将 ETH 存入系统；在Zcash中，是新开采的ZEC硬币）。换句话说，deposit 操作与其过去的交易历史相关联。在 withdraw 过程中，会消耗一个 nullifier，且不会添加新的 coin ID。这会切断取款与相应存款之间的联系，进而切断与过往交易历史的联系。不过，取款可与取款事件之后发生的任何未来交易建立关联。$^{[1]}$ 

最初版本的Tornado Cash没有内部转账的概念，仅支持 deposits 和 withdrawals。后续版本仍处于实验阶段，新增了内部转账功能，并支持任意面额的代币，包括“拆分 (splitting)”和“合并 (merging)”操作，以处理任意面额所需的机制。我们将在后面的章节中讨论如何将基本的隐私保护货币转账系统和隐私池（Privacy Pools）扩展到支持任意面额的场景。

### D. 隐私池中的 ZK-SNARKs

隐私池的核心思想如下：用户并非仅仅通过零知识证明其提款与之前的某个存款相关联，而是证明其在一个更具限制性的**关联集** (*association set*) 中的成员身份。该关联集可以是之前所有存款的完整子集，也可以是仅由用户自己的存款组成的集合，或者介于两者之间的任何集合。用户通过提供该集合的默克尔根作为公共输入来指定该集合。

为简化起见，我们并不直接证明该关联集实际上是之前所做存款的一个子集；相反，我们仅要求用户使用相同的 coin ID 作为叶子节点，通过零知识证明两个默克尔分支：

（i）一个指向R（coin ID总集合的根）的默克尔分支，以及

（ii）一个指向所提供的关联集合根RA的默克尔分支。

如图3所示:

![image](https://hackmd.io/_uploads/B1b1NgVBge.png)

> 图3：用户通过零知识证明两个默克尔分支：一个证明其 coin ID 在 coin ID 树的某个位置，另一个证明相同的 coin ID在代表用户提供的关联集（由其根RA表示）的树中的某个位置。
> 

其意图是，完整的关联集可在某个地方获取，无论是在链上还是在其他位置。这是核心概念：我们不是要求用户确切指定其提款来自哪笔存款，或者在另一个极端情况下，除了非双花证明之外不提供任何信息，而是让用户提供其资金可能来源的集合，并且这个集合的范围可以根据他们的意愿宽窄不一。我们鼓励形成一个生态系统，使用户更容易指定符合其偏好的关联集合。本文的其余部分将仅描述在此简单核心机制之上的基础设施及其带来的影响。

<br>

## 三、实际考量与应用场景

在进行了技术介绍之后，我们现在转向应用层面，分析隐私增强协议在实际中如何应用。

### A. 关联集的用例

为了说明该方案在执法场景中的价值，让我们考虑一个简单的例子。假设我们有五个用户：Alice、Bob、Carl、David 和 Eve 。前四个是诚实守法的用户，他们希望保护自己的隐私，但Eve是个小偷。假设这是众所周知的。公众可能不知道 Eve 在现实世界中的身份，但他们有足够的证据得出结论，发送到我们标记为“Eve”的地址的代币是被盗的。在实践中经常出现这种情况：已查明流入Tornado Cash的大多数非法资金来自去中心化金融（DeFi）协议漏洞利用，这一事件在公共区块链上是可见的。

当这五个用户中的每一个进行提款时，他们可以选择指定哪个关联集。他们的关联集必须包括他们自己的存款，但他们可以自由选择包括其他哪些地址。让我们首先考虑Alice、Bob、Carl和David的动机。一方面，他们希望最大限度地保护自己的隐私。这促使他们扩大自己的关联集。另一方面，他们希望减少自己的代币被商家或交易所视为可疑的可能。他们有一个简单的方法来做到这一点：他们不在自己的关联集中包括 Eve。因此，对他们四个人来说，选择很明确：将他们的关联集设为{Alice、Bob、Carl、David}。

当然，Eve 也希望最大化她的关联集。但她不能排除自己的存款，所以她不得不使自己的关联集等同于所有五笔存款的集合。参与者的关联集选择如图4所示。

![image](https://hackmd.io/_uploads/SksWEgEHxg.png)

> 图4：每行中的灰色区域代表相应用户的关联集。在我们的简化示例中，我们假设Alice、Bob、Carl和David在各自的关联集中包含所有其他 “良好” 存款，并排除来自已知非法来源的存款5。另一方面，Eve 无法创建一个证明，将她的取款与她自己的存款区分开来。
> 

尽管 Eve 本人没有提供任何信息，但通过一个简单的排除过程，我们可以得出一个明确的推断：
取款5号只能来自Eve。

### B. 关联集构建

上一节阐述了在类似隐私池的协议中使用关联集的一种可能方式，以及诚实参与者如何将自己与不良参与者区分开来。注意，该系统并不依赖于Alice、Bob、Carl和David的利他主义；他们有明确的动机来证明自己与之无关联。

现在让我们更深入地研究一下关联集的构建。一般来说，有两种主要策略用于生成关联集。下面对其进行描述，并在图5中进行可视化展示。

- **包含（或成员关系）**：确定一组特定的存款，我们有确切证据认为这些存款风险较低，并构建一个仅包含这些存款的关联集。
- **排除**：确定一组特定的存款，我们有确切证据认为这些存款风险较高，并构建一个包含除这些存款之外所有内容的关联集。

![image](https://hackmd.io/_uploads/S1KVNgErxg.png)

> 图5：成员资格证明在其关联集中包含特定的存款集合，而排除证明的关联集包含除特定存款集合之外的任何内容。从技术角度来看，它们是相同的，因为它们都针对关联集的默克尔根进行证明。
> 

在实际应用中，用户不会手动挑选要包含在其关联集中的存款。相反，用户将订阅我们可以称之为 <strong>关联集提供商 (ASP)</strong> 的中介机构，这些中介机构生成具有特定属性的关联集。在某些情况下，ASP可以完全在链上构建，无需人工（或AI）干预。 在其他情况下，关联集提供商（ASPs）将自行生成关联集，并将关联集发布到链上或其他位置。

我们强烈建议至少应将关联集的默克尔根（Merkle root）发布到链上；这消除了恶意关联集提供商对用户进行某些类型攻击的能力（例如，为不同用户提供不同的关联集，试图对他们进行去匿名化）。整个关联集应通过API提供，或者理想情况下，存储在诸如 IPFS 这样的低成本去中心化存储系统中。

能够下载整个关联集非常重要，因为这允许用户在本地生成关联集成员资格证明，而无需向关联服务提供商透露任何额外信息，包括他们所进行的取款对应的是哪笔存款。

以下是一些关于 ASP 在实际中可能的运作方式：

- **延迟添加，排除不良行为者**：任何存款在固定时间段（例如7天）后会自动添加到关联集合中，但如果系统检测到特定存款与已知的不良行为（例如大规模盗窃，或政府公布的制裁名单上的地址）相关联，则该存款永远不会被添加。在实际中，这可以通过社区管理的集合来实现，或者通过现有的交易筛选服务提供商来实现，这些提供商已经在进行识别和追踪与不良行为相关的存款的工作。
- **每人每月N美元**：要加入关联集合，存款的价值必须低于某个固定的最大值，并且存款人必须通过零知识证明他们持有某种身份证明令牌（例如政府支持的国民身份证系统，或者像社交媒体账户验证这样较简便的机制）。一种带有表示当前月份的额外参数的 nullifier 机制，用于确保每个身份每月只能向关联集合提交一次存款。这种设计试图体现当今许多常见反洗钱规则的精神，即低于一定阈值的低价值支付比高价值支付享有更高程度的隐私。请注意，这可以完全作为智能合约来实现，无需人工监督即可维持持续运行。
- **每位受信任社区成员每月N美元**：与每人每月N美元相同，但限制更严格：用户必须证明其为高信任度社区的成员。高信任度社区同意其成员相互提供隐私保护。
- **基于实时人工智能的评分**：人工智能 ASP 系统可以实时为每笔存款提供风险评分，并且该系统将输出一个关联集，其中包含风险评分低于特定阈值的那些存款。潜在地，ASP 可能会输出多组对应于多个风险评分阈值水平的内容。

<br>

## 四、更多技术细节

在本节中，我们分析该提案如何支持任意面额，并讨论诸如重新证明、双边直接证明和顺序证明等特殊情况。

### A. 支持任意面额

上述简化的隐私保护加密货币系统仅支持相同面额的加密货币转移。Zcash 通过使用UTXO模型支持任意面额。每笔交易可以有多个输入（每个输入需要公布一个 nullifier ）和多个输出（每个输出需要公布一个coin ID）。创建的每个coin ID必须附带一个加密的面额值。除了证明 nullifier 的有效性之外，每笔交易还必须附带一个额外的证明，证明所创建的加密货币面额总和不超过所花费的加密货币面额总和。图6说明了这个额外的证明。

![image](https://hackmd.io/_uploads/ByBu4x4See.png)

> 图6：ZK-SNARK 证明了一个额外的声明，即加密面额所代表的数字，使得输出端数字之和不超过输入端数字之和。根据具体构造，它可能还需要明确证明所有新创建的硬币面额都是非负的。
> 

这种设计可以通过简单地将存款视为（未加密的）输入，取款视为（未加密的）输出来扩展以支持存款和取款。或者，为了简化分析，可以对设计进行限制。例如，可以只允许部分取款，允许交易有一个加密输入和两个输出：一个未加密输出代表取款，一个加密的“找零”输出代表剩余资金，这些剩余资金可用于未来的取款。

一个自然的问题出现了，即这种设计如何能够扩展以支持隐私池。简单地将其 “原样” 插入隐私池并不理想，因为交易图与我们直观预期的不一致：如果一个用户存入10枚硬币，然后在四次连续取款中花费 1 + 2 + 3 + 4 枚硬币，我们希望将所有四次取款都视为以最初的10枚硬币存款为来源。但我们得到的结果如图7所示：第一次取款以10枚硬币存款为来源，但随后第二次取款以第一次取款产生的9枚硬币找零输出为其来源，依此类推。这在实际中会引发问题，因为它要求ASP验证中间存款并将其添加到关联集中。

![image](https://hackmd.io/_uploads/BJNj4eNrlx.png)

> 图7：在UTXO图中，似乎每次提款的来源都是上一次部分提款的找零输出。但从经济意义上讲，每种情况下的 “真正” 来源都是原始存款。
> 

如果我们希望此示例中的所有四次提款都能够将原始的10枚硬币存款作为其来源，我们需要同时解决两个问题：

（i）确保每次部分提款不会公开与其他提款相关联，以及

（ii）允许每次部分提款将存款作为其关联集的成员进行声明。

如果我们仅支持部分提款（而不是更复杂的多输入多输出交易），并确保每次提款都有一个单一明确的相应 “原始存款”，那么我们有很多直接可行的方法。一种自然且非常可扩展的方法是通过交易传播对某些信息的承诺。例如，我们可以要求一笔交易包含一个承诺 $hash(coin ID+hash(r))$，添加一些随机值 $r$ 以实现盲化，并要求ZK-SNARK，如果父交易本身是一笔提款，那么交易中的承诺与父交易中的承诺指向相同的值，或者如果父交易是一笔存款，则只需证明该承诺指向原始存款的硬币ID。因此，链中的每笔交易都必须包含对原始存款 coin ID 的承诺，并且该值将被证明存在于交易提供的关联集中。

### B. 特殊情况

1）**重新验证**：要从类似隐私池的协议中提取存款，用户需要其秘密存款信息。该秘密信息随后被用于构建关联集成员资格证明。考虑这样一种情况，Alice 提取了她的资金，并创建和公布了一份关联集成员资格证明。之后，她想在一家要求针对不同集合提供证明的商家处消费她的资金。只要Alice保留着她的秘密信息，她就能针对商家的关联集生成一份新的证明。同样，Alice可以针对初始关联集的更新版本生成一份新的证明。保留秘密信息为Alice提供了更大的灵活性，但可能会带来额外的风险。 

另一种情况出现在对特定事件的调查背景下。假设发生了涉及链上加密货币的某些不良行为，初步调查揭示了这些加密货币可能来自的一组可能输入。这可能是因为相关加密货币来自一笔提款，而该提款的关联集是一个小群体，或者是因为链上证据和其他证据相结合，揭示了该事件背后主谋的部分信息。在这种情况下，其他成员可能希望证明自己与该事件无关以证清白，而肇事者的身份就会暴露。或者，如果一个事件存在争议，但许多人即使自己并非责任人也支持该事件，他们可能会拒绝提供这样的证明。

2）**双边直接证明**：在某些情况下，用户可能需要向另一方披露其提款的准确来源。例如，如果 Alice想将她提取的资金存入银行，银行可能会要求提供有关资金来源的完整信息。作为回应，Alice 可以创建一个仅包含她的存款的关联集，并针对该集构建一个证明。我们预计这些证明是例外情况，并且只有在双边共享时才有助于实现部分隐私。此外，共享此证明假定了一个很强的信任假设，即接收者不会进一步分发它。

另一个更高级的选择是，爱丽丝通过零知识证明以下陈述之一为真：（i）“此提款在该关联集中”，或（ii）“我是银行”，或（iii）“根据这个特定的时间戳服务（可以是服务器或区块链），自该证明创建以来已过去超过10秒”。只有实时接收证明（iii）且知道自己并未创建该证明（ii）的银行，才能够信任该证明：如果证明落入他人之手，将很难让接收者相信该证明不是伪造的。这消除了与隐私泄露相关的大部分交易对手风险。

3）**顺序证明**：让我们设想一个更长远的未来场景，在这个场景中，类似隐私池的系统不仅偶尔被使用，而是在绝大多数交易中被使用。这是像Zcash这样注重隐私的系统所期望的世界。它引入了一些在仅偶尔使用隐私池的世界中不会出现的新复杂性。

为了适应这样一个世界，需要对协议进行以下修改：除了存款和取款交易类型外，该协议还需要支持一种内部发送操作，该操作消耗一个现有的 coin ID，并生成一个归他人所有的新 coin ID。从协议分析的角度来看，这相当于发送方将资金提取到接收方的地址，然后接收方立即重新存入，但它通过将步骤数量和链上证明从两个减少到一个，从而提高了效率。

假设 Alice 向 Bob 发送一枚硬币；也就是说，她进行了一次内部发送，（可能是部分地）消耗了 Alice 拥有的一个 coin ID，并使用 Bob 提供的参数创建了一个新的 coin ID。然后 Bob 想立即花费这枚硬币，将其发送给 Carl ，并且他也希望自己的消费交易是私密的。这里就出现了我们面临的挑战：**纳入延迟**。在我们上面提出的许多配置中，关联集提供商（ASPs）不会愿意立即将 Bob 的新硬币添加到他们的关联集中，因为他们需要留意资金来源可能不是 Alice ，而是刚刚从 Alice 钱包中窃取资金的人。设置纳入延迟是为了给 Alice 时间报告这一事件，或者给第三方时间来检测它。

另一个类似的用例是：“Alice”是一个 DeFi 协议，而 Bob 想从该 DeFi 协议中提取资金，并立即使用这些资金私下向 Carl 付款。这种情况少了一个人，但在结构上非常相似。

在快速交易的经济环境中，相同的资金每周可能会周转多次，甚至更频繁，而纳入延迟将构成严重挑战。针对这个问题，一种可能的解决方案可能很简单：如果用户钱包中的硬币没有足够“成熟”到可以进入关联集，用户可以通过非隐私保护交易发送这些硬币。然而，我们提出了一种泄露信息更少的不同替代方案。

当 Bob 向 Carl 付款时，Bob 还会直接将用于生成该笔付款的默克尔分支和秘密交给 Carl。这使得 Carl 能够看到 Bob 所看到的：即来自 Alice 的付款在该硬币的历史记录中。如果后来发现与某个不良行为者相关的大量硬币被存入并迅速重新流通，Carl 将能够证明他的硬币来自与该不良行为者无关的最终来源。

如果 Carl 随后将这些币发送给 David，他会传递来自 Bob 的默克尔分支和秘密，并且也会添加自己的。现在，假设 David 接下来将他的币发送给 Emma，但当他这么做的时候，Alice 所做的存款已被添加到关联集合中。那么，David 就不再需要提供来自 Alice 的默克尔分支和秘密；相反，他可以简单地代表 Alice 生成一个关联集合成员证明。一旦 Bob 的支付被添加到关联集，Bob 的默克尔分支和秘密同样会过时。这个概念围绕着确保每个用户仅获取对所收到资金有信心所需的必要且最少的信息。图8展示了这个示例。

![image](https://hackmd.io/_uploads/SkCRVeNHlx.png)

> 图8：当 David 将他的交易发送给 Emma 时，他需要提供来自他自己、Carl 和 Bob 的默克尔分支和秘密，但不需要 Alice 的，因为 Alice 向 Bob 的支付现在已在关联集中。
> 

在实际中，一枚硬币可能有多个“来源”。也许 Bob 是一位咖啡商贩，从 Alice 那里收到5枚硬币，从Ashley 那里收到4枚硬币，从 Anne 那里收到7枚硬币，并且在一天结束时需要向 Carl 发送15枚硬币用于支付晚餐费用。反过来，David 可能从 Carl 那里收到15枚硬币，又从 Chris 那里收到25枚硬币，并且想向身为交易所的 Emma 存入30枚硬币。在这些更复杂的情况下，我们遵循相同的原则：足够古老以至于已被添加到关联集中的历史记录可以被忽略，而更新的历史记录则需要向前传递。

<br>

## 五、讨论

类似隐私池的系统使用户在金融交易数据方面能够实现更高的隐私保护，同时保留证明自身与已知非法活动无关联的能力。我们预计，诚实的用户会因两个因素的共同作用而受到激励参与此类方案：（i）对隐私的渴望，以及（ii）避免被怀疑的愿望。

### A. 社会共识与关联集合

如果对于哪些资金是 “好的”、哪些是 “坏的” 存在完全一致的共识，该系统将导致一个简单的分离均衡。所有拥有 “好” 资产的用户都有强烈的动机和能力证明自己属于仅包含 “好” 资产的关联集合。另一方面，不良行为者将无法提供该证明。他们仍可以将 “坏” 资金存入池中，但这不会给他们带来任何好处。每个人都可以轻松识别这些资金是从隐私增强协议中提取的，并看到提款所涉及的关联集合包含来自可疑来源的存款。更重要的是，“坏” 资金不会污染 “好” 资金。当从合法存款中提取资金时，其所有者可以简单地将所有已知的 “坏” 存款排除在其关联集合之外。

在没有全球共识的情况下，关于资金被视为 “好” 还是 “坏” 的结论取决于社会视角或司法管辖区，关联集可能会有很大差异。假设存在两个具有不同规则集的司法管辖区。受司法管辖区A和B管辖的主体都可以使用相同的隐私增强协议，并选择发布一份证明，该证明满足其各自司法管辖区的要求。两者都可以在各自的关联集中轻松实现隐私保护，并排除不符合各自司法管辖区规定的提款。如果需要，人们可以针对两个关联集的交集发布成员资格证明，从而可信地证明其提款对应的存款符合两个司法管辖区的要求。

因此，该提案非常灵活，应被视为中立的基础设施。一方面，它具有抗审查性。它允许任何人加入他们选择的关联集，并在自己的社区内保持隐私。另一方面，外部人员可以要求提供针对特定关联集且符合其监管要求的证明。所以，即使在隐私增强协议中有不良行为者组成的社区，只要信息在关联集的构建中得到准确反映，他们就无法混淆存款的可疑来源。

### B. 关联集属性

关联集要发挥作用，需要具备某些属性。这些集合需要准确无误，这样用户才能相信在提取资金后可以安全地使用资金。此外，每个集合的属性应该稳定，也就是说随着时间推移它们不太可能发生变化。这就减少了针对新集合重新验证取款的必要性。最后，为了实现有意义的隐私保护，确保关联集足够大并包含各种各样的存款至关重要。然而，这些特性相互之间存在冲突。一般来说，规模大且多样化的集合可能具有更好的隐私属性，但可能准确性和稳定性较差，而较小的集合更容易维护，但提供的隐私保护较少。

### C. 实际考量与竞争

接受加密资产的受监管实体必须确保其适用的法律法规允许接受此类资金。如今，许多此类实体依赖所谓的交易筛查工具：一种分析区块链以识别潜在可疑活动、与非法地址的关联或其他不合规交易的软件或服务。筛查工具通常通过风险评分来表示与每笔交易相关的风险。该评分基于所转移资金的去向及其交易历史。在这方面，隐私增强协议可能是一个挑战。它们消除了存款与取款之间的可见联系。因此，在存在隐私增强协议的情况下，风险评分必须考虑相关证明，并基于关联集合来分配分数。

交易筛查的工具和服务主要由在区块链分析及相关法律领域都具备专业知识的专业公司提供。理想情况下，这些公司（以及其他所有人）能够获取所有成员资格证明及其相应的关联集，以便为所有交易提供准确的风险评分。因此，我们建议将所有证明存储在区块链上或其他可公开访问的证明存储库中。唯一的例外是规模为 1 的成员资格证明，这类证明是与特定交易对手共享的。出于显而易见的原因，这些证明不应公开。

在链上随时提供证明会带来额外的交易成本，但能减少协调工作，创造公平竞争环境，并降低因筛查工具提供商知晓非公开证明而可能形成准垄断的风险。

隐私池的总体设置非常灵活。通过创建特定的关联集，该协议可以定制以适应多种不同的用例。以下是此类专门关联集的两个示例：（i）商业银行财团可以创建一个关联集，其中仅包含其客户的存款。这确保了针对该集合创建证明的任何取款操作都已在相关银行之一经过了 “KYC“ 和 “AML” 程序，但不会透露哪笔取款属于哪个客户。（ii）在金融中介机构必须记录资金确切来源的情况下，他们可以要求用户针对仅包含用户存款的关联集提供证明。然后，此证明将与中介机构进行双边交换，使他们能够追踪资金，就好像用户从未使用过隐私池一样。虽然这要求用户信任中介机构不会泄露证明，但理想情况下，它允许用户遵守法规，而无需向公众披露信息。

### D. 设计选择与替代方案

基于关联集、零知识证明和自愿披露的设置非常灵活。虽然这对于确保该提案有可能适应不同司法管辖区来说是件好事，但在具体的设计选择上应格外谨慎。特别是，有两种我们反对的潜在调整。我们认为，它们在信任要求方面存在问题，并且可能会产生准垄断性的市场结构。
以下我们简要描述并讨论这些替代方法：

1）集中式访问：执法机构、加密风险评分提供商或类似机构可能获得访问权限查看用户交易之间的关联，同时确保这些交易对其他所有人保密。

2）系统范围的条目白名单：隐私系统可以对哪些类型的用户能够将加密货币存入其资金池施加限制，要么要求他们提供额外的证明，要么要求存款等待一段时间，在此期间，集中式风险评分系统可以拒绝一笔存款。

这两种方法非常相似，因为它们都赋予特定实体特殊权限。这将引发复杂的治理问题：谁有权访问这些信息？谁有权力管理权限？私人公司似乎不是一个好选择，因为任何特殊权限都可能产生寡头垄断的市场结构，即少数几家公司能够访问使他们能够提供这些服务的数据，而其他所有人则无法竞争。

同样，如果将权力赋予公共机构，尤其是在国际背景下，将会出现众多治理和政治问题。即使今天将后门密钥交给一个100%值得信赖、不会将此权力滥用于政治议程且不依赖可能迫使其滥用权力的其他实体的机构，认为这是一场静态博弈也是天真的。组织、其成员、民族国家以及组织内部的政治结构都会随着时间而变化。可能会有外部压力，而且这些特殊特权的存在可能会为不良行为者提供额外的动机，促使他们破坏并影响该组织的治理体系。

此外，组织内部或外部的攻击，或者中央实体代表的失误，都可能产生深远的影响。我们认为应避免创建这样一个单点故障。

话虽如此，我们承认不同的交易规模和情况可能需要不同的证明组合。例如，对于大额交易，许多用户最终可能会在链上提供基本的排除证明，并额外向交易对手提供有关资金来源的更详细信息。

### E. 进一步的研究潜力

虽然本研究概述了基于 zk-SNARK 的隐私增强协议如何在受监管环境中使用，但仍有几个领域值得进一步研究。

首先，必须意识到通过这些协议获得的隐私取决于许多不同因素。关联集不够大、根选择不当以及用户失误，可能会让专注的攻击者将取款与特定存款关联起来。此外，其他用户的选择可能会对你自己的隐私产生不利影响。在极端情况下，池中其他所有人都会发布一个大小为一的成员资格证明，从而揭示他们存款与取款之间的直接联系。显然，这将间接地揭示仅存的存款与取款交易之间的联系。在一个更微妙的例子中，来自各种成员资格证明的约束条件可用于提取信息，并有可能以较高概率将存款与取款关联起来。一旦这些证明中的信息与交易元数据相结合，该协议的隐私属性就可能受到损害。最后但同样重要的是，恶意的 ASP 可能会选择以一种能使其最大化可提取信息的方式来编译提议的关联集，或者通过添加已知对应取款的存款来夸大感知到的匿名性。所有这些问题都需要进一步研究，以评估所提供的隐私属性。同样地，进一步研究分离均衡的属性、模拟在某些假设下好的和坏的参与者会如何表现，以及前者的公开证明会如何影响后者的隐私，这将是很有趣的。最后，法律学者可以进一步研究具体的披露要求。本文概述的提议具有高度适应性，法律专家的见解有助于定制该协议及其周围的生态系统，以确保在各个法律管辖区都符合规定。 

<br>

## 六、结论

在许多情况下，隐私保护与合规监管被认为是相互矛盾的。本文认为，倘若隐私增强协议能让用户证明其资金来源的某些特性，情况未必如此。例如，假设用户能够证明其资金与已知非法来源的存款没有关联，或者证明这些资金属于特定的存款集合，同时不泄露更多信息。

这样的设置可以产生分离均衡，即诚实用户会有强烈的动机证明自己属于某个合规的关联集合，同时在该集合内仍能享有隐私。相反，不诚实的用户则无法提供此类证明。这使得诚实用户能够将自己与自己不同意的第三方存款区分开来，否则这些存款可能会阻碍他们在受监管的环境中使用自己的资金。我们认为，该提议相当灵活，有可能进行调整以满足各种各样的监管要求。

本文应被视为对金融隐私与监管有可能共存的未来做出的一份微薄贡献。我们希望推动讨论，将对话转向更积极、更具建设性的方向。

要扩展和完善这一提议，需要从业者、不同领域的学者、政策制定者和监管机构之间展开合作；最终目标是创造可在受监管环境中使用的隐私增强基础设施。

<br>

## 引用

[1] M. Nadler and F. Schär, "Tornado cash and blockchain privacy: A primer for economists and policymakers," Federal Reserve Bank of St.Louis Review, vol. 105, no. 2, pp. 122-136, 2023.
[2] A. Soleimani, "Privacy pools," 2023, gitHub repository. [Online]. Available: https://github.com/ameensol/privacy-pools
[3] S. Nakamoto, "Bitcoin: A peer-to-peer electronic cash system," 2008. [Online]. Available: https://bitcoin.org/bitcoin.pdf
[4] S. Meiklejohn et al., "A fistful of bitcoins: Characterizing payments among men with no names," 2013. [Online]. Available: https://cseweb.ucsd.edu/~smeiklejohn/files/imc13.pdf
[5] C. Kang et al., "De-anonymization of the bitcoin network using address clustering," 2020. [Online]. Available: http://dpnm.postech.ac.kr/papers/Blocksys/changhoon_blocksys2020.pdf
[6] "Ethereum name service, decentralised naming for wallets, websites, & more,' 2023. [Online]. Available: https://ens.domains/
[7] G. Maxwell, "Coinjoin: Bitcoin privacy for the real world," 2013, accessed: August 22. [Online]. Available: https://bitcointalk.org/?topic=279249
[8] J. Liu et al., "Linkable spontaneous anonymous group signatture for ad hoc groups," 2004. [Online]. Available: https://eprint.iacr.org/2004/027.pdf
[9] B. Goodell et al., "Concise linkable ring signatures and forgery aagainst adversarial keys," 2019. [Online]. Available: https://eprint.iacr.org/2019/654.pdf
[10] M. Moser et al., "An empirical analysis of traceability in the monero blockchain," 2018. [Online]. Available: https://arxiv.org/pdf/1704.04299
[11] "Zcash," 2023. [Online]. Available: https://z.cash/
[12] V. Buterin, "An incomplete guide to rollups," 2021. [Online]. Available:
https://vitalik.ca/general/2021/01/05/rollup.html
[13] M. Petkus, "Why and how zk-snark works," CORR, vol. abs/1906.07221, 2019. [Online]. Available: http://arxiv.org/abs/1906.07221
[14] A. Berentsen, J. Lenzi, and R. Nyffenegger, "An introductiion to zero-knowledge proofs in blockchains and economics," Federal Reserve Bank of St. Louis Review, no. forthcoming, 2023. [Online]. Available https://www.stlouisfed.org/publications/review/2023/05/12/an-introduction-to-zero-knowledge-proofs-in-blockchains-and-economics