简介
关于零知识证明技术 (ZKPs) 的潜力，一些人感到兴奋并沉迷其中。这种情况下，ZKPs 就像是密码学上的涅磐境界，好像没有任何问题是 ZKPs 无法解决的。
有人将 ZKPs 描述为综合性的隐私解决方案，这是不准确的。本文的目的是对 ZKPs 能做和不能做的内容进行诚实的评估，特别是在涉及隐私方面。我们还将研究可以与 ZK 搭配使用以加强 ZKPs 的工具。
ZKPs 具有一些出色的优点，但也有局限性。了解两者之间的区别是至关重要的，只有这样，我们才能负责任地将它们纳入自己的工具箱中进行构建。
ZKPs允许用户在不透露任何细节的情况下证明自己的知识
零知识证明使用户能够证明他们知道某些信息，而不透露任何细节。为此，必须有一个“证明者/测试者”和一个“验证者”。
有一个关于洞穴的故事来解释 ZKPs：
两个朋友，Alice 和 Jorge，发现了一个洞穴。这个洞穴有两条通往中心处的路径，那里有一扇门。这扇门上有一个代码，据说连接了这两条路径。
Jorge 声称自己知道门上的代码。Alice 想从他那里购买这个代码，但想要证明他确实知道它。Jorge 不能直接告诉她代码以证明他的知识。因此，他们都同意进行一个“零知识”的交换测试。
Alice 让 Jorge 通过其中一条路径进入洞穴。如果他确实知道代码，他就可以通过另一条路径出来。
零知识证明是这个故事的一个加密解决方案。它利用一个序列生成“证明”，而两个当事人之间不需要进行任何知识交换。
ZKPs 提供了交易隐私和可扩展性。
ZKPs 的一个简单用例是识别用户和检查签名。这完全符合它的强项。
像 ZCash 这样的项目还利用零知识来提供交易隐私。
ZKPs 以其可扩展性而闻名。一份信息可以用轻量级“证明”替换，从而减轻区块链拥堵并加快交易速度。这使得 ZKPs 适用于构建高度可扩展的 layer 1 或 layer 2 扩展解决方案，如 zero-knowledge rollups。
ZKPs 无法实现安全计算或可扩展隐私。
ZKPs 可以在“本地”（在交易级别）实现隐私承诺。但是它们无法在“全局”（网络级别、应用程序、多方）级别保密。
例如，为了使 DeFi 变得私密，用户需要能够与无信任代理进行交易，例如基于智能合约的 DEX，同时始终保持其数据的隐私。但是使用 ZKPs 无法实现这一点。
当我们从交易进入安全计算领域时，ZKPs 的隐私保障就会出现问题。
Secret Labs 的首席执行官 Guy Zyskind 解释了这种情况的实际运作方式：
中心化的一方（通常被称为序列器）在链下执行所有交易（和计算）。这意味着客户端直接与这个序列器进行交互，而不是与区块链进行交互，并将它们的非加密输入数据发送给它。序列器在运行所有计算后，生成一个简明证明，并将其与输出（通常是更新后的状态）一起发送到区块链上。区块链作为验证器，验证证明是否正确，如果正确，就应用状态更改，而不直接了解客户端的数据。所有通用区块链ZK解决方案都使用这种拓展方法。
很简单，如果你可以看到你的数据，你可以证明它。你无法证明与另一个人的数据的相似性或差异。谁或什么可以做到这一点呢？序列器对所有参与者数据生成一个证明。
但是，如用户需要信任链下的中心化序列器来管理他们的数据……我们回到了Web2的基本问题。
还存在关于基础架构层信息泄露的理论问题。例如，零知识证明不能防止交易大小分析或其他形式的元数据泄露，这些可能会揭示有关 ZKP 交易的信息。
简而言之，ZKP 非常适用于在本地保密（例如点对点交易）。但是，在全球/网络范围内，它们无法保护同样的数据隐私。
这在很大程度上是因为，零知识证明无法使智能合约或 DEX 保密。这也是为什么不幸的是，ZKP 并不是解决隐私问题的万灵药。
与其他隐私解决方案相比，ZKP的优势和限制如何？
在密码学领域中，很少存在“最优”方法。这里提到的每种解决方案都有多种构建方式，并且可以单独使用或与其他解决方案结合使用，以逐个解决有趣的问题。正如下面的图表所示，每种构建和组合都有权衡和相对优势。
全同态加密可以在加密数据上进行计算，而无需解密
全同态加密(FHE)是一个容易理解但极难实现的想法。
想象一下，有一个单一的用户和一个服务器。该服务器不保护隐私。我们如何解决隐私问题？
通过 FHE，用户可以将加密数据发送到服务器，服务器可以在不需要查看原始数据的情况下对其进行计算。
FHE 是现有所有隐私技术中最低效的
不幸的是，到目前为止，FHE一直非常低效。事实上，我们知道 FHE 是所有保护隐私技术中最慢的。然而，FHE 计算的效率正在以惊人的速度提高，并且专用硬件 (CPU → GPU → FPGA → ASIC) 将在未来十年内进一步提高计算速度几个数量级。
但即使在未来5-10年，使用 FHE 的能力只针对某些用例或智能合约执行的某些部分才有意义。例如，您可能希望使用 FHE 存储和操作极其敏感（且很小）的数据，如加密密钥或 SSN。
FHE 无法对使用不同密钥加密的数据进行计算
那么，我们如何将第二个客户端引入到这个安全计算问题中呢？
假设世界上只有两个客户端。两个客户端都有自己的输入，并希望对其输入进行函数计算。两者都想要隐私保护。
使用“纯” FHE，由于每个客户端使用自己的密钥加密其数据，因此不清楚如何处理这种情况。FHE 无法对使用不同密钥加密的数据进行计算。那么我们该如何解决这个问题呢？
半同态加密（PHE）无法支持一般的智能合约
事实证明，解决这个问题需要使用许多方法。除了全同态加密（Fully Homomorphic Encryption，FHE），可以对加密数据进行任意函数计算外，还有许多半同态加密方案（HE 或 PHE）。这些部分方案可以计算特定功能 —— 通常是加法或乘法，但不能同时计算两者（请注意，所有函数都可以归结为加法和乘法操作）。这些 PHE 方案几十年前就被发明出来并且更加高效，它们可以满足一些有限的用例，但对于安全计算的一般情况则不足以支持。
一些网络旨在使用像 PHE 这样的部分方案实现隐私（例如 Penumbra 和 Dero）。然而，重要的是要了解，根据定义它们无法支持通用智能合约。这些技术应用于以隐私为中心的区块链是新颖的，但它所能支持的用例是相当有限的。
有一些与众不同的方法可以扩展像 PHE 这样的部分解决方案所支持的应用程序范围，但这需要深入的加密专业知识。这些应用经常带来其他难以推理的隐藏的权衡。因此，PHE 可能永远不会允许开发人员构建具有隐私的任意应用程序。
因此，如果 FHE 或部分 HE 方案单独无法解决多客户端安全计算问题……那么可以采用什么方法呢？
安全多方计算（MPC）将计算分布在系统中。
MPC 是一种分布式系统的方法，用于计算私有数据。从这个意义上讲，它与区块链的基本架构非常契合。
在 MPC 中，我们不再信任单个服务器，而是有多个不受信任的服务器共同运行客户端数据上的计算。改变信任假设极大地增加了解决方案空间。MPC 解决方案是针对多个客户端开发的。因此，与 FHE 不同，不存在服务器合并多个用户数据的理论问题。
有趣的是，MPC 可以与 FHE 结合使用，创建“阈值全同态加密”（Threshold FHE）。阈值 FHE 将单个 FHE 加密密钥分为所有服务器之间的份额。
MPC 依赖于非串谋安全（security by non-collusion）的概念
仅使用 FHE 可以让用户保留其加密密钥，而服务器永远无法访问她的数据。
但是，对于 MPC，如果所有服务器串谋起来，它们可以重构私有数据。只要有一个诚实的服务器，就可以避免这种串谋，模型就是安全的。
此时需要注意的是，MPC 解决方案不包含密钥。相反，MPC 通过为每个服务器提供“加密”的数据份额来隐藏数据，因此你需要 所有份额才能“解密”数据。此外，每个份额本身并不揭示明文数据的任何信息。
在实践中，人们可以根据要优化的性能选择串谋门限来进行调整，是为了优化存活性还是隐私。在上述示例中，需要所有密钥份额才能重构数据，这样我们就获得了最大的隐私。
然而，只需一台服务器就可以对整个系统发起拒绝服务（DoS）攻击。这是因为只需一台服务器不响应客户端请求，结果就无法计算。
另一方面，我们可以仅要求使用 1/2 或 2/3 的密钥份额。这将需要多数服务器诚实且在执行计算时不串通。
在 MPC 中，隐私问题比正确性问题更加难以解决
正确性是可以验证的 – 如果交易被篡改，这要么是可见的，要么达成共识。然而，我们无法验证对隐私的串谋攻击，因此这是一种“无声”的攻击。
如果服务器通过共享密钥串通在一起（在系统外），我们将永远不知道它们能够解密数据。为了消除这种攻击方式，我们可以尽可能让更多的服务器运行计算，从而避免串通攻击。
不幸的是，MPC 随着参与方数量的增加而扩展性较差，增加服务器数量会妨碍存活性。因此，似乎仅靠 MPC 还不足以满足需求，需要实施其他技术来防止串通。
基于可信执行环境（TEE）的解决方案可以使 MPC 的串谋攻击更加复杂
使 MPC 勾结更加困难的一种方法是强制分布式系统中的所有服务器使用可信执行环境（更多内容见下文）。
或者，可以通过在许可环境中工作来使串通复杂化，其中服务器（部分）受信任，如果发生数据泄漏，可以重新识别。这就是 Partisia Blockchain 似乎正在采取的方向：一组半信任节点的链下执行私有计算，区块链仅存储和验证状态。
可信执行环境 （TEE） 将计算与 CPU 的其余部分分开
可信执行环境（TEE）可以将处理过程移至“黑匣子”中，使其对计算机的 CPU 不可访问。该区域可以存储数据（如加密密钥）并运行计算，机器的主人无法篡改。另外，主机也无法提取该区域中存储的任何数据（至少在理论上是如此）。
通过要求服务器（或在区块链设置中，服务器）在其 TEE 中执行所有计算，并要求客户端使用仅在服务器 TEE 中可用的密钥对其输入数据进行加密，TEE 可以解决隐私和正确性问题。
采用这种设计，即使是拥有服务器的主机也无法访问客户端的数据。这是因为数据只在 TEE 中解密和计算。有关此类系统在实践中如何工作以及如何保护加密密钥的更多信息，请查看 Secret Network 技术文档。
另一种思考 TEE 的方法是将其视为我们之前想象的简单世界的硬件近似（单个用户和单个可信服务器都能够进行正确和隐私保护的计算）。然而，充分利用 TEE 要比那个世界复杂得多。为了防止审查或 DoS 攻击，最好使用分布式系统（如区块链）中的 TEE，而不是依赖于单个服务器。
由于 TEE 系统通过硬件依赖而非纯加密来保证安全，因此它们非常高效。虽然加密解决方案通常比明文计算慢几个数量级，但在大多数情况下，使用 TEE 的计算时间开销不到 40%。这主要是因为需要解密输入并重新加密输出以保护隐私.
TEE 的主要缺点是可能会遭受侧信道攻击，这也是用户担心的问题。近年来，研究人员已经展示了如何利用大部分现代处理器使用的 speculative execution 方法从 TEE 中提取信息。虽然大多数这些问题可以在软件或硬件上解决，并且在实践中难以被利用，但与纯加密技术相比，在这个特定的攻击向量上它们确实存在劣势。架构错误（可能影响任何类型的硬件，而不仅仅是安全隔离）也是可能的，构成了严重的风险，不应忽视。
考虑到这些权衡，TEE 仍然是目前最好的实际解决方案，特别是对于低敏感性数据的高性能计算。即使潜在解决方案的核心性质是加密的，TEE 仍然是增强安全性并可以帮助防止勾结，同时提高可扩展性的关键。
ZKP 在与其他区块链隐私解决方案结合使用时得到“强化”
例如，构建器可以将 ZKP 与多方计算相结合，以构建完全私有的应用程序。还有基于硬件的解决方案（可信执行环境，TEE），尽管在使用 TEE 时可能不需要额外的 ZKP。
多方计算通过启用加密（即私有数据）的计算来弥补 ZKP 的缺点。因此，您可以在智能合约级别保持数据的私密性。
在此示例中，DEX 的内部状态可以加密，MPC 允许您对数据执行计算并更新它，而无需解密它。这样可以始终保持数据的私密性。
最终，ZKP 可以在其优势领域提供帮助：验证用户身份、签名和轻量级交易。
Web3 隐私的未来不是一刀切的
正如我们在本次讨论中看到的那样，每个隐私解决方案都有其权衡取舍。无论您听到了什么，都没有单一的解决方案可以满足我们所有的隐私需求并且零风险。
使用任何隐私技术负责任地构建都意味着了解其固有的局限性。
当这些被清楚地理解时，我们可以触及更广泛的隐私工具箱，并有可能将该技术与补充其各自弱点的解决方案配对。ZKP，TEE，MPC 和 FHE 都带来了一些优势和局限性。
链上隐私对用户来说应该是“正常的”。朝着这一愿景前进意味着对各种隐私工具持开放态度，而不是围绕单一解决方案陷入最大心态。
微信扫一扫 
