简介

围绕零知识证明(ZKPs)的潜力所产生的传染性兴奋，使一些人非常着迷。对于这个阵营来说，ZKPs感觉就像一个密码学的天堂，没有什么问题是ZKPs不能解决的。

一些人将ZKPs作为一种全面的隐私解决方案来销售。这是不准确的。这篇文章的目的是对ZKPs能做什么和不能做什么进行诚实的评估 - 特别是当涉及到隐私时。我们还将检查可以与ZKPs一起配对的补充工具，以加强ZKPs。

ZKPs有一些很好的优点，但它们也有局限性。为了摆脱它们无所不能的假象，了解这两点是至关重要的。只有在有了这种认识之后，我们才能负责任地将它们纳入我们的建设工具箱。

ZKPs允许用户在不透露细节的情况下证明知识

零知识证明使用户有可能在不透露任何细节的情况下证明他们知道什么。要做到这一点，必须有一个 "证明者/测试者 "和一个 "验证者"。

有一个关于山洞的流行故事有助于解释ZKPs：

两个朋友，Alice和Jorge，发现了一个山洞。山洞里有两条进出的路，通向中间，那里有一扇门。这扇门上有一个密码，据说可以连接这两条路。

Jorge说他知道这扇门上的密码。爱丽丝想从他那里买到这个密码，但想要他证明他知道这个密码。Jorge不能直接告诉她密码来证明。所以他们都同意进行一个 "零知识 "交流测试。

Alice将告诉Jorge通过其中一条路径进入洞穴。如果他真的有密码，他就可以通过另一条路离开。

零知识证明是这个故事的一个密码学解决方案。它们利用排序器来生成一个 "证明"，不需要双方进行知识交流。

ZKPs提供交易隐私和可扩展性

ZKPs的一个简单用例是识别用户和检查签名。这与它的优势领域完全吻合。

ZCash等项目也利用零知识来提供交易隐私。

ZKPs因其可扩展性而闻名。一个信息包可以被一个轻量级的 "证明 "所取代，缓解了区块链的拥堵，加快了交易速度。这使得ZKPs适合建立一个高度可扩展的layer1，或layer2的扩展解决方案，如零知识rollup。     

ZKPs不能容纳安全计算或可扩展的隐私

ZKPs可以实现 "本地"（在交易层面）的隐私承诺。但它们不能在 "全球"（网络层面、应用程序、多方）层面保密。

例如，为了使DeFi私有化，用户需要能够与一个不可信任的代理--如基于智能合约的DEX--进行交易，同时始终保持其数据的私有性。而这在ZKPs中是不可能的。

当我们从交易领域进入安全计算领域时，ZKPs的隐私就会被打破。

Secret Labs的首席执行官Guy Zyskind解释了这在实践中是如何运作的：

一个中心化的一方（通常称为排序者）在链外执行所有交易（和计算）。这意味着客户直接与这个排序者而不是区块链互动，并向它发送他们的非加密输入数据。排序者在运行所有计算后，产生一个简洁的证明，并将其与输出（通常是更新的状态）一起发送到区块链上。区块链作为验证器，验证该证明是否正确，如果正确，则在不了解学习客户数据的情况下应用状态更改。所有通用的区块链ZK解决方案都使用这种扩展方法。

这很简单。如果你能看到你的数据，你就能证明它。你不能证明与其他人的数据的相似性或差异。谁或什么来做这个？排序器在所有参与者的数据上生成一个证明。

但是，如果用户需要用他们的数据信任一个链外的、集中的排序器......我们又回到了Web2的基本问题。

理论上也有对基础设施层的信息泄露的担忧。例如，ZKPs不能防止交易规模分析或各种其他形式的元数据泄漏，这有可能暴露ZKP交易的信息。

简而言之，ZKPs对于在本地（如点对点交易）保守秘密是很好的。但它们无法在全球/网络范围内保持同样的数据隐私。

这在很大程度上是因为零知识证明不能使智能合约或DEX保密。以及为什么，不幸的是，ZKPs并不是隐私的万能钥匙。

与其他隐私解决方案相比，ZKPs的优势和局限性如何？

在密码学中，很少有一个 "最佳 "方法。这里提到的每个解决方案都有多种结构，可以单独使用或与其他解决方案串联使用，以逐一解决有趣的问题。如下图所示，每一种结构和组合都有取舍和相对优势。

完全同态加密在加密的数据上进行计算而不需要解密 

完全同态加密（FHE）是一个容易理解但极难实现的想法。

想象一下，在一个世界里只有一个单一的用户和一个服务器。该服务器并不保护隐私，我们如何解决隐私问题？

通过FHE，用户可以向服务器发送加密数据，而服务器在她的数据上进行计算，不需要查看原始数据。

FHE是所有现有隐私技术中效率最低的一种

不幸的是，到目前为止，FHE的效率非常低。事实上，FHE是我们所知的所有隐私保护技术中最慢的一种。然而，FHE的计算效率一直在以惊人的速度提高，在未来十年，专门的硬件（CPU → GPU → FPGA → ASIC）将进一步提高计算速度，提高几个数量级。

但即使在5-10年内，使用FHE功能也很可能只对某些用例或智能合约执行的某些部分有意义。例如，你可能想用FHE来存储和操作极其敏感（和小）的数据，如加密密钥或SSN。

FHE无法对用不同密钥加密的数据进行计算

我们如何为这个安全计算问题引入第二个客户端？

让我们假设世界上只有两个客户端。两个客户都有自己的输入，并想对他们的输入计算一个函数。两个人都想要隐私。

使用 "纯 "FHE，不清楚如何做到这一点，因为每个客户都使用自己的密钥来加密他们的数据。FHE无法对用不同密钥加密的数据进行计算。那么我们如何解决这个问题呢？

部分同态加密（PHE）不能支持一般的智能合约

事实证明，需要用很多方法来解决这个问题。除了可以在加密数据上计算任何任意函数的完全同态加密外，还有许多部分同态加密方案（HE或PHE）。这些部分方案可以计算特定的功能--通常是加法或乘法，但不能同时计算（注意，所有功能都可以简化为加法和乘法运算）。这些部分HE方案是几十年前发明的，效率高得多，它们可能足以满足有限的用例，但它们不足以满足安全计算的一般情况。

一些网络旨在使用像PHE这样的部分方案来实现隐私（例如Penumbra和Dero）。然而，重要的是要了解，根据定义，它们不能支持通用的智能合约。这些技术在以隐私为重点的区块链上的应用是新颖的，但它能支持的用例是相当有限的。

有一些非常重要的方法来扩展你可以用这样的部分解决方案来支持的应用范围，但这需要在密码学方面有深厚的专业知识。这些应用往往带来其他难以推理的隐藏权衡。由于这个原因，PHE可能永远不会允许开发者建立具有隐私的任意应用程序。

那么，如果仅靠FHE或部分HE解决方案不能解决多客户安全计算问题......那什么可以呢？

安全的多方计算（MPC）将计算分布在整个系统中

MPC是一种在私有数据上进行计算的分布式系统方法。在这个意义上，它与区块链的基本架构自然契合。

在MPC中，我们没有信任单一的服务器，而是有多个不受信任的服务器，它们共同对客户数据进行计算。改变信任假设会大大增加解决方案的空间。MPC的解决方案是在考虑到多个客户的情况下开发的。因此，服务器结合来自多个用户的数据不存在理论上的问题（与FHE不同）。

有趣的是，MPC可以与FHE结合，创造一个 "阈值FHE"。阈值FHE将一个单一的FHE加密密钥分割成所有服务器之间的共享。

MPC依赖于非共存的安全性

使用FHE（单独）允许用户保持他的秘密加密密钥，而服务器永远无法获得他的数据。

但在MPC中，如果所有的服务器串通起来，他们可以重建私人数据。只要有一个服务器是诚实的，就可以避免这种串通，这个模型就是安全的。

在这一点上需要注意的是，MPC解决方案并不包含密钥。相反，MPC通过给每个服务器一个 "加密 "的数据份额来隐藏数据，这样你就需要所有的份额来 "解密 "数据。此外，每个共享不会透露关于明文数据的任何信息。

在实践中，人们可以定制合谋的阈值，以优化活跃度或隐私。在上面的例子中，所有的密钥共享都需要重建数据，我们获得最大的隐私。

然而，只需要一个服务器就可以对整个系统进行拒绝服务（DoS）攻击。这是因为只需要一台服务器不响应客户的请求，结果就无法计算出来。

另一方面，我们可以只要求½或⅔的密钥共享。这将要求大多数服务器是诚实的，在执行计算的时候不串通。

在MPC中，隐私性比正确性更难解决 

正确性是可以验证的--如果一个交易被篡改，这要么被看到，要么共识甚至停止。然而，人们无法验证对隐私的串通攻击，使其成为一种'无声'的攻击。

如果服务器通过共享密钥进行串通（在系统外），我们将永远不知道他们可以解密数据。为了消除这种攻击矢量，我们可以旨在让尽可能多的服务器运行计算，从而避免串通攻击。

可悲的是，MPC随着各方数量的增加而扩展得很差，而且增加服务器的数量会妨碍灵活性。因此，单靠MPC似乎是不够的，还需要实施其他的技术来使串通变得困难。

TEEs可以使MPC的合谋攻击矢量复杂化

使MPC合谋更加困难的一种方法是强迫分布式系统中的所有服务器使用可信执行环境（下文将详细介绍）。

或者，人们可以通过在许可环境中工作来使合谋行为复杂化，在这种环境中，服务器是（部分）被信任的，如果发生数据泄漏，可以被重新识别出来。这就是Partisia区块链似乎采取的方向：一个半信任的节点链外集执行私人计算，而区块链只存储和验证状态。

可信执行环境（TEE）将计算与CPU的其他部分分开

TEE将处理转移到一个 "黑匣子"，以便计算机的CPU无法访问。这个区域可以存储数据（如加密密钥），并运行不能被机器的主机所篡改的计算。同时，主机也无法提取存储在该区域的任何数据（至少在理论上）。

TEE可以通过要求我们的服务器（或在区块链设置中，服务器）在其TEE内执行所有计算来解决隐私和正确性问题。此外，我们可以要求客户使用只有在服务器的TEE中才有的密钥对他们的输入数据进行加密。

在这种设计下，即使是拥有服务器的主机，都无法接触到客户的数据。这是因为数据只在TEE内进行解密和计算。关于这种系统在实践中是如何工作的，以及加密密钥是如何被保护的，请看Secret Network的技术文件。

另一种考虑TEE的方式是将其作为我们之前想象的简单世界的硬件近似（有一个用户和一个可以正确和私密地运行计算的受信任服务器）。然而，充分利用TEE要比这个世界复杂得多。为了防止审查或DoS攻击，最好还是在区块链这样的分布式系统中使用TEE，而不是依赖单一的服务器。

因为TEE系统通过硬件依赖获得安全，而不是纯粹的密码学，所以它们非常高效。虽然密码学解决方案通常比透明的计算慢几个数量级，但在大多数情况下，TEE的计算时间开销不到40%。这主要是由于要求解密输入和重新加密输出以保护隐私。

令用户担心的TEE的主要缺点是有可能发生旁路攻击。近年来，研究人员展示了他们如何从TEE中提取信息，主要是利用推测执行，这是所有现代处理器为获得效率而使用的方法。虽然这些问题大多可以在软件或硬件中解决，并且在实践中难以利用，但与纯加密技术相比，它们在这种特定的攻击矢量上确实存在着劣势。架构错误（可以影响任何类型的硬件，而不仅仅是安全飞地）也是可能的，并构成了严重的风险，这是不容忽视的。

考虑到这些权衡，TEE目前仍然是最好的实用解决方案，特别是对于低敏感性数据的高性能计算。即使潜在解决方案的核心是加密性质的，TEE也是增强安全性的关键，并能帮助防止串通，同时提高可扩展性。

当与其他区块链隐私解决方案相结合时，ZKPs会被“强化”

例如，构建者可能会将ZKPs与多方计算结合起来，建立一个完全私有的应用程序。也有基于硬件的解决方案（可信执行环境，TEEs）--尽管在使用TEEs时，你可能不需要额外的ZKPs。

多方计算弥补了ZKPs的缺点，因为它可以在加密的即私人数据上进行计算。因此，你可以在智能合约层面保持数据的私密性。

在这个例子中，DEX的内部状态可以被加密，MPC允许你对数据进行计算，并在不解密的情况下更新它。这就始终保持数据的私密性。

最终，ZKP可以在其优势领域有所帮助：验证用户身份、签名和轻量级交易。

Web3隐私的未来并不是一刀切的

正如我们在这次讨论中所看到的，每个隐私解决方案都有其权衡之处。无论你听说过什么，没有一个解决方案可以满足我们所有的隐私需求，并且是零风险的。

负责任地使用任何隐私技术意味着了解其固有的限制。

当这些被清楚地了解后，我们可以将手伸向更广泛的隐私工具箱，并有可能将该技术与补充其各自弱点的解决方案配对。ZKPs、TEEs、MPC和FHE都会带来一些优势和限制。

对用户来说，链上隐私应该是 "正常 "的。为实现这一愿景，意味着对各种隐私工具持开放态度，而不是围绕一个单一的解决方案满足最大的心理需求。