条条大路通 MPC？探索隐私基础设施的终局

作者：EQ Labs 来源：equilibrium 翻译：善欧巴，金色财经

我们的隐私系列第 1 部分介绍了“隐私”的含义、区块链网络中的隐私与 web2 隐私有何不同，以及为什么在区块链中难以实现隐私。

本文的主要观点是，如果理想的最终状态是拥有可编程的隐私基础设施，能够处理共享的私有状态而没有任何单点故障，那么所有的道路都通向MPC。我们还将探讨MPC的成熟度及其信任假设，强调替代方法，比较权衡，并提供行业概述。

摆脱过去的束缚，迎接未来

区块链中现有的隐私基础设施旨在处理非常具体的用例，例如私人支付或投票。这是一种相当狭隘的观点，主要反映了区块链目前的用途（交易、转账和投机）。正如Tom Walpo 所说- 加密货币遭受费米悖论： 

除了增加个人自由之外，我们认为隐私是扩大区块链设计空间的先决条件，超越当前的推测性元数据。许多应用程序需要一些私有状态和/或隐藏逻辑才能正常运行： 

• 隐藏状态：绝大多数金融用例需要（至少）对其他用户保密，并且如果没有一些隐藏状态，许多多人游戏的趣味性就会大大降低（例如，如果扑克桌上的每个人都能看到彼此的牌）。 

• 隐藏逻辑：某些用例需要隐藏一些逻辑，同时仍允许其他人使用该应用程序，例如匹配引擎、链上交易策略等。

实证分析（来自 web2 和 web3）表明，大多数用户不愿意为增加隐私而支付额外费用或跳过额外的环节，我们也同意隐私本身并不是卖点。然而，它确实使新的和（希望）更有意义的用例能够在区块链之上存在——让我们摆脱费米悖论。

隐私增强技术（PET）和现代密码解决方案（“可编程密码”）是实现这一愿景的基本构建模块（有关可用的不同解决方案及其权衡的更多信息，请参阅附录） 。

影响我们观点的三个假设

三个关键假设决定了我们对区块链隐私基础设施如何发展的看法：

1. 加密技术将从应用程序开发人员手中抽象出来：大多数应用程序开发人员不想（或不知道如何处理）处理隐私所需的加密技术。期望他们实现自己的加密技术并构建私有应用专用链（例如Zcash或Namada）或在公共链（例如 Tornado Cash）之上的私有应用程序是不合理的。这实在太复杂了，开销也太大了，目前限制了大多数开发人员的设计空间（无法构建需要某些隐私保障的应用程序）。因此，我们认为必须将管理加密部分的复杂性从应用程序开发人员手中抽象出来。这里的两种方法是可编程隐私基础设施（共享私有 L1/L2）或“机密即服务”，后者允许外包机密计算。

2. 许多用例（可能比我们想象的要多）需要共享私有状态：如前所述，许多应用程序需要一些隐藏状态和/或逻辑才能正常运行。共享私有状态是其中的一个子集，其中多方对同一私有状态进行计算。虽然我们可以信任一个中心化方为我们完成这件事并就此打住，但理想情况下，我们希望以信任最小化的方式来做这件事，以避免单点故障。仅靠零知识证明 (ZKP) 无法实现这一点 – 我们需要利用其他工具，例如可信执行环境 (TEE)、完全同态加密 (FHE) 和/或多方计算 (MPC)。 

3. 更大的屏蔽集可最大程度地保护隐私：大多数信息在进入或退出屏蔽集时都会被泄露，因此我们应尽量减少这种情况。在同一区块链上构建多个私有应用程序可以通过增加同一屏蔽集内的用户和交易数量来帮助加强隐私保障。

隐私基础设施的终结

考虑到上述假设，区块链隐私基础设施的最终目标是什么？是否有一种方法适合所有应用程序？是否有一种隐私增强技术可以统领所有应用程序？

不完全是。所有这些都有不同的权衡，我们已经看到它们以各种方式结合在一起。总的来说，我们已经确定了 11 种不同的方法。

目前，在区块链中构建隐私基础设施的两种最流行方法是利用 ZKP 或 FHE。然而，两者都存在根本缺陷：

• 基于 ZK 且具有客户端证明的隐私协议可以提供强大的隐私保障，但不允许多方对同一私有状态进行计算。这限制了表达能力，即开发人员可以构建哪些类型的应用程序。 

• FHE 支持对加密数据和共享私有状态进行计算，但提出了谁拥有该状态的问题，即谁拥有解密密钥。这限制了隐私保障的强度，以及我们可以相信今天的隐私明天仍然如此的程度。

如果理想的最终状态是拥有可编程的隐私基础设施，可以处理共享的私有状态而不会出现任何单点故障，那么两条路都可以通向 MPC： 

请注意，尽管这两种方法最终会趋于融合，但 MPC 的用途不同：

• ZKP 网络：MPC通过实现共享私有状态的计算来增加表达能力。

• FHE 网络：MPC通过将解密密钥分发给 MPC 委员会（而不是单个第三方）来提高安全性 并加强隐私保障。

虽然讨论开始转向更细致入微的观点，但这些不同方法背后的保证仍未得到充分探索。鉴于我们的信任假设归结为 MPC 的假设，需要提出的三个关键问题是：

1. MPC 协议在区块链中能提供的隐私保障有多强？

2. 技术是否足够成熟？如果不够，瓶颈是什么？

3. 考虑到保证的力度及其引入的开销，与其他方法相比它是否有意义？

让我们更详细地解答这些问题。

使用 MPC 分析风险和弱点

每当解决方案使用 FHE 时，人们总是需要问：“谁拥有解密密钥？”。如果答案是“网络”，那么后续问题是：“哪些真实实体构成了这个网络？”。后一个问题与所有以某种形式依赖 MPC 的用例相关。

资料来源：Zama 在 ETH CC 上的演讲

MPC 的主要风险是串通，即有足够多的参与方恶意串通解密数据或盗用计算。串通可以在链下达成一致，并且只有当恶意方采取某些明显行动（勒索、凭空铸造代币等）时才会被揭露。毋庸置疑，这对系统可以提供的隐私保障具有重大影响。串通风险取决于：

• 该协议可以承受多少恶意方？

• 网络由哪些方组成？他们的可信度如何？

• 参与网络的不同方的数量及其分布 – 是否存在常见的攻击媒介？

• 网络是无需许可的还是需要许可的（经济利益与声誉/法律基础）？

• 对恶意行为的惩罚是什么？串通博弈在理论上是最优结果吗？

1. MPC 协议在区块链中能提供的隐私保障有多强？

TLDR：不如我们所希望的那么强大，但比依赖一个集中的第三方要强大。 

解密所需的阈值取决于所选的 MPC 方案 – 很大程度上是活跃度（“保证输出交付”）和安全性之间的权衡。您可以采用非常安全的 N/N 方案，但只要有一个节点离线，它就会崩溃。另一方面，N/2 或 N/3 方案更稳健，但串谋风险更高。 

需要平衡的两个条件是：

1. 秘密信息永远不会泄露（例如解密密钥）

2. 秘密信息永远不会消失（即使 1/3 的参与方突然离开）。

所选方案因实施而异。例如，Zama 的目标是 N/3，而 Arcium 目前正在实施N/N 方案，但稍后还将支持具有更高活性保证（和更大信任假设）的方案。 

在这个权衡边界上，一个妥协的方案是采用混合解决方案： 

• 高信任委员会以例如 N/3 阈值进行密钥处理。

• 计算委员会是轮换的，例如有 N-1 阈值（或多个具有不同特征的不同计算委员会供用户选择）。 

虽然这在理论上很有吸引力，但它也引入了额外的复杂性，例如计算委员会如何与高信任委员会互动。

加强安全保障的另一种方法是在受信任的硬件内运行 MPC，以便将密钥共享保存在安全区域内。这使得提取或使用密钥共享进行协议定义以外的任何操作变得更加困难。至少Zama和Arcium正在探索 TEE 角度。

更细微的风险包括诸如社会工程之类的边缘情况，例如，MPC 集群中的所有公司都雇用了一名高级工程师超过 10 至 15 年。 

2. 技术是否足够成熟？如果不够成熟，瓶颈是什么？

从性能角度来看，MPC 面临的关键挑战是通信开销。它随着计算的复杂性和网络中节点数量的增加而增长（需要更多的来回通信）。对于区块链用例，这会带来两个实际影响：

1. 小型操作符集：为了使通信开销可控，大多数现有协议目前仅限于小型操作符集。例如，Zama 的解密网络目前最多允许 4 个节点（尽管他们计划扩展到 16 个）。根据 Zama 为其解密网络 (TKMS) 发布的初始基准，即使只有 4 个节点的集群，解密也需要 0.5-1 秒（完整的 e2e 流程需要更长的时间）。另一个例子是 Taceo为 Worldcoin 的虹膜数据库实施的 MPC，该数据库有 3 方（假设 2/3 诚实方）。

   资料来源：Zama 在 ETH CC 上的演讲

2. 

3. 许可操作员集：在大多数情况下，操作员集是经过许可的。这意味着我们依赖声誉和法律合同，而不是经济或加密安全。无许可操作员集的主要挑战是无法知道人们是否在链下串通。此外，它需要定期引导或重新分配密钥份额，以便节点能够动态进入/退出网络。虽然无许可操作员集是最终目标，并且正在研究如何扩展 PoS 机制以实现阈值 MPC（例如 Zama），但许可路线似乎是目前最好的前进方向。

替代方法

全面的隐私组合包括：

• FHE 用于委托隐私计算

• ZKP 用于验证 FHE 计算是否正确执行

• 用于阈值解密的 MPC

• 每个 MPC 节点都在 TEE 内运行，以增强安全性

这很复杂，引入了许多未探索的极端情况，开销很大，并且在未来很多年内可能都无法实际实现。另一个风险是，人们可能会因为将多个复杂概念叠加在一起而产生虚假的安全感。我们添加的复杂性和信任假设越多，推断整体解决方案的安全性就越困难。

这值得吗？也许值得，但也值得探索其他方法，这些方法可能会带来显著更好的计算效率，而隐私保证只会略弱一些。正如Seismic 的 Lyron所指出的那样 – 我们应该专注于最简单的解决方案，以满足我们对所需隐私级别和可接受权衡的标准，而不是仅仅为了它而过度设计。

1. 直接使用 MPC 进行通用计算

如果 ZK 和 FHE 最终都回归到 MPC 的信任假设，为什么不直接使用 MPC 进行计算呢？这是一个合理的问题，也是Arcium、SodaLabs （ Coti v2使用）、 Taceo和Nillion等团队正在尝试做的事情。请注意，MPC 有多种形式，但在三种主要方法中，我们这里指的是基于秘密共享和乱码电路 (GC)的协议，而不是使用 MPC 进行解密的基于 FHE 的协议。 

虽然 MPC 已经用于分布式签名和更安全的钱包等简单计算，但使用 MPC 进行更通用计算的主要挑战是通信开销（随着计算的复杂性和所涉及的节点数量的增加而增加）。

有一些方法可以减少开销，例如提前离线进行预处理（即协议中最昂贵的部分）—— Arcium和SodaLabs都在探索这一点。然后在在线阶段执行计算，这会消耗离线阶段产生的一些数据。这大大降低了整体通信开销。

SodaLabs 的下表显示了在其 gcEVM 中执行不同操作码 1,000 次需要多长时间的初始基准（以微秒为单位）。虽然这是朝着正确方向迈出的一步，但仍有许多工作要做，以提高效率并将操作符集扩展到几个节点之外。

来源：SodaLabs

基于 ZK 的方法的好处是，您只将 MPC 用于需要在共享私有状态下进行计算的用例。FHE 与 MPC 的竞争更为直接，并且严重依赖硬件加速。

2. 可信执行环境

最近，人们对 TEE 的兴趣又重新燃起，它既可以单独使用（基于 TEE 的私有区块链或协处理器），也可以与其他 PET（如基于 ZK 的解决方案）结合使用（仅使用 TEE 进行共享私有状态的计算）。

虽然 TEE 在某些方面更为成熟，并且引入的性能开销更少，但它们并非没有缺点。首先，TEE 具有不同的信任假设（1/N），并且提供基于硬件而非软件的解决方案。人们经常听到的批评是围绕SGX 过去的漏洞，但值得注意的是 TEE ≠ Intel SGX。TEE 还需要信任硬件提供商，而硬件价格昂贵（大多数人无法负担得起）。解决物理攻击风险的一个解决方案可能是在太空中运行 TEE来处理关键任务。 

总体而言，TEE 似乎更适合只需要短期隐私的证明或用例（阈值解密、暗盘账本等）。对于永久或长期隐私，安全保障似乎不太有吸引力。

3. 私有 DAC 和其他依赖可信第三方保护隐私的方法

中介隐私可以提供隐私，防止其他用户访问，但隐私保证完全来自对第三方的信任（单点故障）。虽然它类似于“web2 隐私”（防止其他用户的隐私），但它可以通过额外的保证（加密或经济）来加强，并允许验证正确执行。

私有数据可用性委员会 (DAC)就是一个例子；DAC 的成员将数据存储在链下，用户信任他们能够正确存储数据并执行状态转换更新。另一种形式是Tom Walpo 提出的特许序列器。

虽然这种方法在隐私保障方面做出了很大的权衡，但就成本和性能而言，它可能是对低价值、高性能应用程序唯一可行的替代方案（至少目前如此）。例如，Lens Protocol计划使用私有 DAC 来实现私有信息流。对于链上社交等用例，隐私和成本/性能之间的权衡目前可能是合理的（考虑到替代方案的成本和开销）。

4. 隐身地址

隐身地址可以提供与为每笔交易创建新地址类似的隐私保证，但该过程在后端自动进行，并且对用户不公开。有关更多信息，请参阅Vitalik 的这篇概述或这篇深入探讨不同方法的文章。该领域的主要参与者包括Umbra和Fluidkey。

虽然隐身地址提供了一种相对简单的解决方案，但主要缺点是它们只能为交易（付款和转账）添加隐私保证，而不能为通用计算添加隐私保证。这使它们与上面提到的其他三种解决方案有所不同。 

此外，隐身地址提供的隐私保障不如其他替代方案强大。匿名性可以通过简单的聚类分析来打破，特别是当传入和传出的转账不在相似范围内时（例如，收到 10,000 美元，但每天的交易平均花费 10-100 美元）。隐身地址的另一个挑战是升级密钥，如今需要为每个钱包单独升级（密钥存储汇总可以帮助解决这个问题）。从用户体验方面来看，如果账户没有费用代币（例如 ETH），隐身地址协议还需要账户抽象或付款人来支付费用。

我们的论点面临的风险

鉴于快速的发展速度和不同技术解决方案的普遍不确定性，我们认为 MPC 将成为最终解决方案的论点存在一些风险。我们最终可能不需要某种形式的 MPC，主要原因包括：

1. 共享私有状态并不像我们想象的那么重要：在这种情况下，基于 ZK 的基础设施更有可能获胜，因为它比 FHE 具有更强的隐私保证和更低的开销。已经有一些用例表明基于 ZK 的系统在孤立用例中运行良好，例如私有支付协议Payy。

2. 性能上的权衡不值得隐私保障的好处：有人可能会说，具有 2-3 个许可方的 MPC 网络的信任假设与单个中心化参与者并无太大区别，而且成本/开销的大幅增加是不值得的。对于许多应用程序，尤其是低价值、成本敏感的应用程序（例如社交或游戏），这可能是正确的。然而，也有许多高价值用例，由于法律问题或协调摩擦大，协作目前非常昂贵（或不可能）。后者是 MPC 和基于 FHE 的解决方案可以大放异彩的地方。

3. 专业化胜过通用设计：构建新链并引导用户和开发人员社区非常困难。因此，通用隐私基础设施 (L1/L2) 可能难以获得关注。另一个问题涉及专业化；单一协议设计很难覆盖整个权衡空间。在这个世界上，为现有生态系统（机密性即服务）或专门用例（例如支付）提供隐私的解决方案将占上风。然而，我们对后者持怀疑态度，因为它给应用程序开发人员带来了复杂性，他们需要自己实现一些加密技术（而不是将其抽象出来）。

4. 监管继续阻碍隐私解决方案的试验：对于任何构建隐私基础设施和具有某些隐私保障的应用程序的人来说，这都是一个风险。非金融用例面临的监管风险较小，但很难（不可能）控制在无需许可的隐私基础设施之上构建什么。我们很可能在解决监管问题之前解决技术问题。

5. 对于大多数用例来说，基于 MPC 和 FHE 的方案的开销仍然太高：虽然 MPC 主要受到通信开销的影响，但 FHE 团队严重依赖硬件加速来提高其性能。但是，如果我们可以推断 ZK 方面专用硬件的发展，那么在我们获得可用于生产的 FHE 硬件之前，需要的时间将比大多数人想象的要长得多。致力于 FHE 硬件加速的团队包括Optalysys、fhela和Niobium。

概括

归根结底，链条的强度取决于其最薄弱的环节。在可编程隐私基础设施的情况下，如果我们希望它能够处理共享的私有状态而不会出现单点故障，那么信任保证就归结为 MPC 的保证。

虽然这篇文章听起来对 MPC 有所批评，但事实并非如此。MPC 极大地改善了目前依赖中心化第三方的现状。我们认为，主要问题是整个行业存在虚假的信心，问题被掩盖了。相反，我们应该直面问题，专注于评估潜在风险。

然而，并非所有问题都需要使用相同的工具来解决。尽管我们认为 MPC 是最终目标，但只要 MPC 驱动的解决方案的开销仍然很高，其他方法也是可行的选择。我们总是值得考虑哪种方法最适合我们试图解决的问题的特定需求/特征，以及我们愿意做出哪些权衡。

即使你有世界上最好的锤子，也不一定所有的东西都是钉子。