链上追溯匿名控制的屏蔽池

本文介绍了一种新的机制，用于防止不良行为者滥用基于屏蔽池的隐私系统。目标是向更广泛的以太坊社区介绍这个想法，并获得关于以下方面的反馈：

• 技术可行性，
• 与以太坊社区共享的价值观的一致性，
• 促进基于屏蔽池的隐私解决方案更广泛采用的潜力。

在简短的介绍和对问题的解释之后，我们提出了一个理想化的提议系统版本，以尽可能简单的形式展示这个想法。然后，我们用技术术语讨论了该系统可能实现的具体实例，并分析了由此产生的权衡和与理想化版本的偏差，之后我们将其与清白证明（Proofs of Innocence）（当前最先进的解决方案）进行比较。

预备知识

屏蔽资产的想法已经存在近十年了，最早由 ZCash 推广并投入生产。此后，许多类似的协议已经被构建并部署为以太坊和其他 EVM 链上的智能合约。这些协议包括 TornadoCash、Railgun、Privacy Pools 和 Blanksquare，这些是我们本文的主要关注点（我们将它们称为屏蔽池）。为了本文的目的，我们采用以下最大程度简化的这些协议模型（遵循 TornadoCash）：有两种操作，deposit（存款）和 withdraw（取款）：

• deposit（存款）— 用户在合约中存入 1 ETH，并将包含 1 ETH 和用户“消费密钥（spend key）”的哈希“票据（note）”添加到合约中的 Merkle 树中，
• withdraw（取款）— 用户取出之前通过 deposit（存款）存入的 1 ETH。通过揭示所谓的“零知识证明(nullifier)”来花费相应的票据。

有关技术细节，请参考 TornadoCash 白皮书、ZeroCash 论文 或任何最近的说明。主要思想是，withdraw（取款）操作不能与任何特定的 deposit（存款）操作相关联，因此所有用户的 ETH 混合在一起。我们注意到，现在许多协议允许不同的存款和取款金额、将票据拆分为多个取款、使用 ERC20 代币等——可以进行这些修改，并且本文中的所有想法仍然适用于更通用的协议。类似地，一些屏蔽池允许屏蔽到屏蔽的转移；本文提出的系统也可以支持此功能，但为了简单起见，我们不讨论它。

在部署区块链隐私系统时，一个重要的考虑因素是不良行为者滥用的问题。一个典型的例子是黑客从链上合约窃取代币，然后使用屏蔽池来清洗这些资金（使执法部门难以追踪）。围绕这个问题的伦理和监管考虑已经被广泛讨论，并且超出了本文的范围。我们专注于技术方面。我们进行比较的参考解决方案是清白证明（Proofs of Innocence）（例如，参见 Buterin 等人的这篇论文）。以下是它的一个粗略总结（目前在 Privacy Pools 中实现）：

• 在进行存款时，deposit_id 进入由链下 compliance_system（合规系统）维护的队列。
• compliance_system 花费一定的时间（实际上在 1 小时到 7 天之间）验证存款不是非法的。如果确认存款是干净的，则此信息由 compliance_system 发布在链上，并且 deposit_id 被添加到 Merkle 树允许列表（出于技术原因需要）。

• 用户有两种方式执行 withdraw（取款）：

  • Regular（常规）：仅当 deposit_id 在允许列表中时才可能。然后用户可以私下取款。
  • Ragequit（退出）：始终可能。用户可以取款，但必须将 deposit_id 与交易一起发布，这使其可以与存款相关联，因此不是私有的。
• compliance_system 可以向允许列表添加新条目，也可以删除它们（至少在 Privacy Pools 的情况下）。

简而言之，PoI（清白证明）系统通过拒绝基于公共信息（追踪链上资金）的非法或可疑资金来保护屏蔽池免受非法存款的侵害。

理想化的追溯匿名控制系统

我们提出了一个替代清白证明（Proofs of Innocence）的系统，称为追溯匿名控制（Retroactive Anonymity Control，简称 RAC）。在本节中，我们介绍该协议的一个 理想化 版本，这意味着为了实现 RAC 的目的，假设存在完美的密码学。我们使用这种方法来关注系统的基本属性，而不是实现细节。在本文的后面，我们将提供三种实现 RAC 的具体方法，并讨论由此产生的权衡。

对于 RAC，我们对正常的屏蔽池操作进行以下调整：

• 对于每个 deposit（存款）操作，用户生成一个新的 view_key（可以理解为：256 位）。
• 对于 deposit（存款）和 withdraw（取款），用户都附加 MAC(view_key) —— 一种“签名”，允许验证签名者，但仅当密钥已知时。具体来说，可以理解为 MAC(view_key) = (salt, hash(view_key, salt))。
• 该协议强制用户对 deposit（存款）和 withdraw（取款）使用相同的 view_key，例如通过将 view_key 保存在票据中。然而，MAC(view_key) 是随机化的，因此外部各方无法在没有 view_key 的情况下将 deposit（存款）链接到 withdraw（取款）。

让我们分析一下我们获得了什么：

• 每个 (deposit, withdrawal)（存款，取款）对都有一个唯一的（且可执行的）view_key。
• 给定存款（或取款）的 view_key，任何人都可以通过屏蔽池链接（并因此解除匿名）特定的转移。
• 默认情况下，用户生成 view_key 并仅为自己持有，这使得附加的 MAC 只是随机噪声。

RAC 系统由以下组件组成：

• compliance_control（合规控制）— 以太坊地址，代表实体，负责做出关于通过屏蔽池对转移进行潜在解除匿名的决策。
• compliance_execution（合规执行）— 以太坊智能合约，负责揭示 compliance_control 请求的 view_key。它通常依赖于一些链下活动。

以下是具有 RAC 的屏蔽池的工作方式：

1. 用户始终可以 deposit（存款）和 withdraw（取款），没有任何限制。没有允许列表，也没有等待期。
2. 如果 在任何时候 检测到 deposit（存款）（或 withdraw（取款））来自非法来源，并且 compliance_control 决定底层资金不应受益于匿名性，则 compliance_control 对 compliance_execution 合约进行 deanonymize(...) 调用，输入指向特定的 deposit（存款）或 withdraw（取款）。
3. 在收到 deanonymize(...) 调用后，compliance_execution 合约异步地公开输出所请求的 deposit（存款）或 withdraw（取款）的 view_key。这允许任何人链接相应的 deposit（存款）和 withdraw（取款），从而有效地将此转移从匿名集中移除。

以下是一些评论：

• 显然，密码学的魔力发生在 compliance_execution 中，我们将在后面的章节中解释如何做到这一点。现在，让我们假设这是可能的。
• compliance_control 是唯一可以通过 compliance_execution 调用解除匿名的一方 —— 因此，我们希望它不是一个单一的中心化参与者，而是一个 DAO 或一个多成员的“合规委员会”。如何实例化此实体的细节超出了本文的范围。
• 请注意，我们不必信任 compliance_execution 的输出，因为可以根据 MAC(view_key) 验证 view_key 的正确性（这是 MAC 的关键属性）。

简短总结：在 RAC 中，用户可以始终自由地存款和取款，但链上实体（DAO 或类似实体）称为 compliance_control，它可以随时追溯地解除任何 (deposit, withdraw)（存款，取款）对的匿名性。这通过链上请求透明地发生，并且生成的 view_key 也被发布在链上供所有人查看。

\ image1169×572 91.3 KB

具体实例化

上一节描述了理想化的协议，但没有解释如何实例化 compliance_execution。我们现在讨论使用三种不同的密码学技术实现此目的的三种方法。我们按照从最实际（且最容易实现）到最不实际（最难实现）的顺序呈现它们。

实例化 1：TEE 网络

我们假设存在用于非对称、SNARK 友好的加密的密钥对 (sk, pk)（可以使用适用于某个群的 ElGamal），并且除了 MAC(view_key) 之外，用户还在每个交易中发布 Enc_pk(view_key)（deposit（存款）和 withdraw（取款））。换句话说，用户在每个交易中都使用密钥 pk 加密他们的 view_key，只有持有 sk（TEE）的一方才能解密它。

这个想法很简单。我们实例化一组 TEE，由各种独立的各方运营。理想情况下，运行 TEE 的副本应该是无需许可的，但鉴于 最近的攻击，这很棘手，但并非根本不可能。每个 TEE 都持有 sk 密钥的副本。从工程角度来看，密钥生成协议和密钥在 TEE 之间的分发并非完全微不足道，但它已被很好地理解，并且已经是 TEE 的标准做法。每个 TEE 运行一个大致执行以下操作的程序：

• 要实例化你的 sk，请从运行同一程序的另一个 TEE 复制它（省略细节）。
• 如果你持有你的 sk，则永远不要以明文形式泄露它。如果运行同一程序的另一个 TEE 请求 sk，则通过加密通道提供它（省略细节）。

• 收到 deanonymize(finality_proof, args) 请求后，执行：

  • 运行以太坊轻客户端以验证 finality_proof 是对以太坊上 compliance_execution 合约的 deanonymize(args) 调用的正确最终性证明。
  • 从 args 中恢复 Enc_pk(view_key)，并使用 sk 解密它以了解 view_key。
  • 以明文形式输出 view_key。

实际上，这意味着每当 compliance_control 请求对特定存款或取款解除匿名时，任何 TEE 运营商都可以调用他们的“魔盒”来检索 view_key（他们只需要提供一个有效的最终性证明，以便 TEE 知道该请求确实发生在以太坊上）。然后，运营商在链上提交 view_key（合约可以验证正确性）。

由此产生的安全保证是：

• 只要至少有一个诚实的运营商，协议就是实时的 —— 也就是说，compliance_control 的解除匿名请求将得到回应。
• 即使所有运营商都是不诚实的，只要 TEE 本身没有受到破坏，协议的匿名性就会得到保留。
• 如果由于某种原因，所有 TEE 的副本同时崩溃，并且所有 sk 的副本都丢失了，那么该协议将无法再执行解除匿名操作。
• 如果任何 TEE 受到破坏，并且其运营商恢复了 sk，那么该运营商可以秘密地解除所有用户（过去、现在和未来）的匿名性。可以通过定期轮换 sk 来降低这种影响。

实例化 2：MPC 委员会

与第一个 TEE 实例化类似，我们假设一个密钥对 (sk, pk) 和一个固定的 N 节点委员会，该委员会 (1) 使用 DKG 生成 (sk, pk)，以及 (2) 使用 t-of-N 阈值解密协议为链上的解除匿名请求提供服务。这可以使用现有的解决方案来实现，例如 Shutter。

根据解密协议的确切细节，安全属性略有不同，但大致上我们可以得到：

• 只要有足够多的委员会节点诚实行事（并且不丢失其密钥份额），该协议就是实时的。
• 除非大部分节点串通并恢复密钥 sk，否则协议的匿名性会得到保留。否则，串通的节点可以解除所有用户（过去、现在和未来）的匿名性。

实例化 3：见证加密

这种实例化仍然处于科幻领域，但由于 WE 正在被积极研究，它将来可能会变得可行。

这里的想法是没有“主密钥”了。相反，用户将一个见证加密的 view_key 附加到他们的每个交易，其中见证是以下数据：

• 以太坊最终性证书（可以理解为无状态轻客户端使用的数据）对 compliance_control 调用 compliance_execution 合约的合约调用，要求解除用户发送的交易的匿名性。

对于不熟悉见证加密的读者来说，这听起来可能令人困惑，但主要思想是在见证加密中，任何可以有效验证的数据都可以用作解密密钥。在我们的设置中，我们只希望在 compliance_control 发出解除匿名请求时才解密，因此“密钥”必须是此类请求已发生的证明。

与清白证明的比较

在与 PoI 进行比较时，我们考虑实例化 1 和 2，因为第三个实例化尚不实用。

在对抗不良行为者方面的有效性

由于 RAC 机制是追溯性的，并且可以随时下令解除匿名，因此它比 PoI 更有效。RAC 可以工作而 PoI 不行的一种情况是，当一个参与者带着非法资金进入，但他们的非法行为在存款很久之后（晚于验证窗口）才变得明显。在那个时候，资金可能已经被提取，因此即使从允许列表中删除 deposit_id 也无济于事。然而，RAC 仍然可以解除转移的匿名性。一个很好的例子是 对 Mirror 协议的这个漏洞利用，该漏洞利用在七个月内未被发现。

复杂性和鲁棒性

RAC 系统明显更复杂，因此更有可能存在错误或容易受到多层攻击（取决于是否使用 TEE 或 MPC）。此外，协议的活性（处理解除匿名请求的能力）在实践中更难维护（密钥丢失、所有 TEE 崩溃等）。由于这些原因，RAC 可以被认为鲁棒性较差。

进入门槛

由于 RAC 中的 compliance_control 是追溯性的，因此它可以比 PoI 中的 compliance_system 宽松得多。有以下几个原因：

• PoI 必须快速做出决定，因为用户实际上在等待批准；在不确定的情况下，拒绝存款更安全。
• PoI 不应允许 —— 或者必须非常小心地处理 —— 循环，即用户取款然后再次存款的情况。RAC 允许这样做，并且如下所述（可组合性），这种行为对于某些应用程序来说是很自然的。
• PoI 可能需要拒绝来自不太知名的 CEX 或通常不太受信任的中心化方的存款，而 RAC 可以接受存款，并且只有在有关于特定存款的索赔时才会在以后解除匿名。

安全和信任假设

无论我们使用 TEE 还是 MPC 来实例化 RAC，都需要新的假设来保持系统中的匿名性。

在 PoI 中，一旦用户从屏蔽池中取款，就可以保证他们不会再被解除匿名（即使他们的存款条目后来从允许列表中删除）。在 RAC 中，没有这样的保证，用户可能会担心：“如果将来，我的私人记录由于漏洞而泄露怎么办？” 这些担忧可以部分缓解（参见“备注”部分），但永远无法完全消除。

可组合性

与现有公共 DeFi 协议的可组合性是屏蔽池得以采用的一个重要因素。一个典型的流程可能是：

• 从屏蔽池 withdraw（取出）代币 A，
• 在 Uniswap 上 swap（交换）代币 A 为代币 B，
• 将代币 B deposit（存入）回屏蔽池。

这种模式是“循环”（取款并存入相同的资金）的一个例子，并且可能是恶意行为者试图将 deposit_id 重置为一个新的 deposit_id。在 PoI 中允许这样的存款是有问题的，因为从允许列表中删除条目的效果会大大降低。

RAC 不受此问题的影响，因此可以说是更具可组合性。

备注

1. 上面描述的关于 RAC 的一个重要担忧是，可以对任意旧的用户互动执行解除匿名请求，因此用户永远无法保证他们的历史记录会被永久遗忘。可以通过引入解除匿名范围来解决这个问题 —— 例如，永远不能解除超过一年的活动的匿名性。这可以通过每年轮换 (pk, sk) 密钥对来实现（TEE 可以被编程为忘记密钥，MPC 委员会可以重新运行设置）。

2. 恶意行为者可能尝试针对 RAC 的一种可能的实际攻击是积极的循环。例如，假设一个恶意行为者持有 100 万 USDT，并使用相同的资金连续执行 1,000 次 deposit → withdraw。为了解开追踪，compliance_control 实体需要执行 1,000 个连续的解除匿名请求，这可能是一个耗时且在操作上存在问题的事情。缓解措施包括：

   • 费用： 如果屏蔽池对存款或取款收取百分比费用（就像最先进的解决方案一样），那么大量资金的积极循环对于攻击者来说会变得非常昂贵。
   • 最低存款金额： 攻击的一个更恶意的版本是将 100 万分成许多小额存款，并分别循环它们。如果存在合理的最低存款限额，这将变得不那么有问题。

结论

我们介绍了一种通过链上 compliance_control 地址控制的追溯性解除匿名来保护屏蔽池免受不良行为者侵害的新思路。与 PoI 的比较当然不详尽，并且 RAC 的许多方面都可以改进。因此，我们要求对这个想法提供反馈 —— 请留下评论，无论是技术性的还是其他方面的；所有这些对我们都有价值。

Blanksquare 团队。

• 原文链接： ethereum-magicians.org/t...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～