优化零知识证明系统Reverie:无需可信设置的高效方案

本文介绍Trail of Bits开发的Reverie零知识证明系统,通过多方计算协议编译实现高效证明生成,支持流式验证,无需可信设置,适用于复杂计算场景,性能基准测试显示可处理数亿逻辑门。

Reverie:优化的零知识证明系统 - Trail of Bits博客

零知识证明曾仅是理论探讨,近年来已广泛应用于Zcash和Monero等区块链系统。然而,大多数区块链应用的ZK证明在证明大小和性能之间做出了不适合其他用例的权衡。这些协议通常需要复杂的可信设置阶段,并为证明大小优化而牺牲证明者时间。许多潜在的ZK证明应用如此复杂,以至于Zcash使用的ZK-SNARK协议需要数天(甚至数月)才能运行。鉴于此,我认为为想要尝试ZK证明的工程师提供替代权衡方案非常重要。

在Trail of Bits实习期间,我实现了一个ZK证明系统Reverie,该系统优化证明者效率且不需要任何可信设置。这些优化以证明大小为代价,但Reverie允许证明通过网络流式传输并增量验证,从而避免一次性将大型证明加载到内存中。Reverie也可在crates.io上作为reverie-zk使用。

本文其余部分将解释Reverie背后的底层ZK证明系统并提供性能基准。由于证明系统使用安全多方计算(MPC)技术,我将从概述MPC基础知识开始,然后展示如何使用MPC构建ZK证明。

MPC入门

玩家分别拥有秘密输入X、Y、Z,并在不揭示X、Y或Z的情况下计算f(X, Y, Z)。

多方计算协议的目标是允许对不同方的输入进行分布式函数计算,而各方不向彼此透露其输入。

例如:

  • 在不透露单个投票值的情况下统计投票。
  • 在不透露客户数据库的情况下计算共享客户数量。
  • 在私有数据集上训练/评估机器学习模型而不共享机密数据。

零知识证明和多方计算具有概念相似性,但存在关键差异:

  • MPC允许对私有数据进行计算,而零知识证明仅允许各方证明私有数据的属性。
  • MPC协议是交互式的(其非交互式表亲是功能加密),要求各方在线。零知识证明可以是交互式或非交互式的。

在本文中,通过描述如何将多方计算协议“编译”为零知识证明系统,我们看到这两种原语确实相关。这是一个美丽的理论结果:本质上,在零知识证明中检查函数输出总是比使用多方计算计算函数更高效。

此外,它还可以在实践中导致非常简单、具体高效的证明系统,应用包括实用的后量子签名方案。正如我们将看到的,这是一个非常通用和多功能的构建零知识证明系统的框架。

密码编译器

我们现在探索如何将一系列“密码编译器”应用于任何MPC协议以获得非交互式零知识证明系统。密码编译器使用密码工具从现有协议生成新协议。协议设计中“编译器”的优势在于它们是通用的:任何满足一组属性的输入协议将产生一个新协议,其中保证保持一组新属性。换句话说,您可以以黑盒方式组合密码原语,以“机械方式”派生新协议。

IKOS编译器

给定能够计算函数“g(x)”的MPC协议,IKOS编译器产生函数“g”的输入/输出对(w, o)的零知识证明系统:它使证明者能够说服验证者它知道秘密输入“w”,使得“g(w) = o”对于某个输出“o”,例如,如果“g(x) = SHA-256(x)”证明它知道SHA-256的输入“w”导致给定哈希“o”而不揭示原像(“w”)。

在高层次上,当证明者本地运行“g(x)”的MPC协议,其中输入“w”在玩家之间共享时,完成此操作。例如,在三个玩家的情况下,可以通过选择随机X、Y、Z满足X + Y + Z = w来完成。这样,仅知道两个输入X、Y、Z不会揭示任何关于w的信息。然后使用多方计算协议计算函数f(X, Y, Z) = g(X + Y + Z)。为防止作弊,验证者要求证明者揭示一部分玩家的输入和通信,并检查它们是否正确运行。

IKOS密码编译器

更精确地说,IKOS编译器接受:

  • 一个MPC协议。
  • 一个密码承诺方案(如下所述)。

并产生一个交互式(公共硬币)零知识证明协议。密码承诺方案由一个函数“Commit”组成,该函数接受一个密钥和一个消息,然后返回一个“承诺”Commit(key, msg) -> commitment,具有以下属性:

  • 找到具有相同承诺的不同消息是棘手的(如抗碰撞哈希函数)。
  • 辨别承诺是否从给定消息创建是棘手的(使用随机密钥,承诺隐藏msg,如加密)。

承诺可以从密码哈希函数构建,例如通过使用HMAC构造。对于承诺的物理类比,可以想到一个信封:您可以将一封信放入信封并密封它(计算“Commit(key, msg)”),信封将隐藏信的内容(“隐藏”),但不允许您用另一封信替换该信(“绑定”)。后来,可以打开信封以揭示内容(通过向某人提供“key”和“msg”并让他们重新计算承诺)。

使用密码承诺,MPC协议“编译”如下:

  • 证明者通过模拟玩家运行协议“在头脑中”执行f(X, Y, Z)的MPC协议:本地运行每个玩家,就好像它们是分布式的一样。您可以将其视为证明者在虚拟机内执行每个玩家的代码并记录它们之间的网络流量,或者证明者扮演一种MPC木偶剧院,其中它扮演协议中每个玩家的角色。
  • 证明者记录协议执行期间不同玩家发送和接收的所有内容。我们称之为每个玩家的“视图”:玩家在协议期间看到的一切。证明者然后承诺每个玩家的视图(“将其放入信封”)并将承诺(“信封”)发送给验证者。
  • 验证者要求证明者提供一部分视图(在我们的示例中为2个)。
  • 验证者然后检查提供视图的两方之间的对应关系是否兼容:玩家发送和接收协议指定的消息。

如下所示。

证明者在“虚拟/想象”方之间执行MPC协议并记录它们的视图。验证者检查这些声称视图的子集之间的一致性。

注意:“公共硬币”部分仅意味着验证者通过选择随机数简单响应证明者:在这种情况下是打开的索引,即验证者没有必须对证明者隐藏的“秘密”以防止他作弊。这将在后面相关。

为什么这有效?我们需要说服自己两件事:

** Soundness:如果证明者作弊,它会被抓住** 假设证明者没有输入X、Y、Z使得f(X, Y, Z) = 1。如果它正确执行了MPC协议,则计算不会返回预期输出“o”(因为MPC协议正确计算f)。因此证明者必须在“头脑中”执行MPC协议时作弊。为了作弊,证明者必须要么:

  • 在一个玩家中作弊,例如让玩家错误地进行本地计算。
  • 在玩家对之间的通信中作弊,例如假装玩家A从玩家B收到消息,而玩家B从未发送。

这两种方式涵盖了在MPC协议中作弊的唯一方式:要么让玩家违反协议,要么颠覆模拟通信介质。

现在考虑具有对等通道的3个玩家的情况(如在Alice、Hare和Hatter之间说明)。那么作弊证明者必须至少在玩家对之间作弊。由于它承诺所有三个玩家的视图,这些承诺中至少有一对必须不一致:如果验证者打开这对,它观察到要么一个玩家在作弊,要么两个玩家之间的消息不匹配。由于有三对承诺,作弊证明者被抓住的概率至少为⅓。

为了“提高soundness”(以更高概率抓住作弊证明者),零知识证明并行重复:让证明者多次运行MPC协议,然后挑战它从每次重复中打开两个方。这样,作弊证明者在N次重复后成功的概率在N中指数下降。

** Zero-knowledge:验证者什么也学不到** 当两个视图被打开时,验证者了解到两个玩家的消息和输入。由于承诺方案隐藏未打开玩家的视图,且MPC协议确保玩家输入的隐私,验证者不会了解到未打开玩家的输入(示例中的Y),因为输入如上所述共享,提供两个输入(示例中的X、Z)不会泄漏关于“w”的信息。

Fiat-Shamir编译器

Fiat-Shamir转换移除交互式验证者(教授)。

Fiat-Shamir转换/编译器接受:

  • 一个公共硬币零知识证明系统。
  • 一个(特别强的)哈希函数。

并产生一个非交互式零知识证明。

Fiat-Shamir转换的基本观察如下:由于验证者所做的只是选择随机数,我们可以让证明者掷骰子,然后打开骰子显示的索引。然后每个人都可以验证打开的视图是否一致。

只有一个明显问题:作弊证明者当然可以假装骰子掷出它想要的任何结果(例如不打开作弊的玩家对)。Fiat-Shamir转换通过本质上使用哈希函数“以可验证随机方式掷骰子”来解决此问题。

这是通过让证明者哈希他的消息(对每个玩家视图的承诺)来完成的,哈希摘要然后用作随机挑战(例如解释为表示要打开哪些玩家的整数序列)。

作弊证明者当然可以尝试更改其消息并重新计算哈希,直到获得允许他作弊的挑战,然而,这仅对应于在验证者允许他尝试任何次数的设置中多次运行交互式协议。因此,作弊证明者在交互式协议中成功的概率通过作弊证明者可用的计算量放大,例如,如果交互式协议允许证明者以概率2^{-128}作弊,则对手必须计算哈希预期2^{127}次才能作弊;这显然不可行。

注意:实际上,Fiat-Shamir转换需要“随机预言机”[参见:https://blog.cryptographyengineering.com/2011/09/29/what-is-random-oracle-model-and-why-3/ 了解更多细节],一个无法真正实例化的证明工件。然而在实践中,用“良好哈希函数”替换“随机预言机”,其中哈希函数的输出“看起来随机”就足够了。

Reverie

这最终将我们带到Reverie。Reverie是KKW 2018中描述的MPC-in-the-head证明系统的高效Rust实现,通过将前两个编译器应用于特别简单的MPC协议派生。由于证明系统适用于任何环(例如有限域、复合整数模或向量空间),Reverie设计为既快速又灵活,足以支持任何环中的计算。

由于上述MPC-in-the-head范式非常通用,且KKW中的技术非常容易推广,Reverie也设计为通用且易于扩展。这使得更容易添加功能,例如在证明系统内在环之间移动以及向电路添加“随机门”。

优化

为提高性能,Reverie使用许多实现技巧:

  • 大量使用比特切片。由于底层MPC协议中的各方都并行执行相同的简单操作,我们可以通过将玩家状态连续打包在内存中,然后用单个操作(在传统64位寄存器或使用SIMD指令)并行操作所有玩家来显著提高性能。Reverie从不操作单个玩家的状态。
  • 并行性。由于证明系统需要多次重复以进行“soundness放大”,每个重复可以轻松委托给单独线程以实现线性性能提升。
  • 快速密码原语。Reverie使用Blake3和ChaCha12,因为这些被发现是最快的密码原语(密码哈希函数和伪随机函数),同时仍提供非常舒适的安全边际。
  • 流式证明者和流式验证者。Reverie允许以流式方式生成和验证证明:这使得验证者可以在证明者仍在生成和传输证明时验证证明。这意味着Reverie的证明和验证组件完全异步。

基准测试

为基准测试Reverie,我们测量了在此电路上验证SHA-256压缩函数的速度。Reverie在(32核)AMD EPYC 7601上平均约20 SHA-256压缩/秒:

SHA-256压缩应用数量 证明生成时间 AND门 XOR门 证明大小
100 4.76 s 2,227,200 9,397,400 22 MB
1000 50.39 s 22,272,000 93,974,000 220 MB
10000 482.97 s 222,720,000 939,740,000 2.2 GB

结论

Reverie是在主导的SNARK范式之外创建高性能零知识证明的第一步,它相对轻松地处理数亿个AND/XOR门。该项目带有一个简单的“伴侣”程序(在“companion”子目录中),使得使用Reverie相对容易。立即在Github和crates.io上尝试!

如果您喜欢这篇文章,请分享: Twitter LinkedIn GitHub Mastodon Hacker News

页面内容 MPC入门 密码编译器 IKOS编译器 Fiat-Shamir编译器 Reverie 优化 基准测试 结论 最近帖子 我们构建了MCP一直需要的安全层 利用废弃硬件中的零日漏洞 Inside EthCC[8]:成为智能合约审计员 使用Vendetect大规模检测代码复制 构建安全消息传递很难:Bitchat安全辩论的细致入微的看法 © 2025 Trail of Bits. 使用Hugo和Mainroad主题生成。

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计