作者:LitaFoundation,翻译:本站xiaozou
“在未来5年内,我们将像谈论区块链协议的应用一样谈论零知识协议的应用。过去几年的突破所释放的潜力将席卷加密主流。”
— Espresso Systems CSO Jill,2021年5月
自2021年以来,零知识证明(ZK)格局已经演变成一个由跨多个领域的原语、网络和应用程序组成的多样化生态系统。然而,尽管ZK在逐渐发展,ZK驱动的rollup(如Starknet和zkSync Era)的推出标志着该领域的最新进展,但对于ZK用户和整个加密领域来说,ZK的绝大部分仍然是一个谜。
但时代在变。我们认为,零知识加密是一种强大的、普适工具,可用于扩展以及保护软件安全。简单地说,ZK是加密大规模采用的桥梁。再次引用Jill的话,无论是web2还是web3,任何涉及到零知识证明(ZKP)的东西都将创造出巨大的价值(包括基础价值和投机价值)。加密领域最优秀的人才正在努力更新迭代,使ZK经济可行、生产就绪。即便如此,在我们设想的模式成为现实之前,行业需要做的还有很多。
将ZK采用与比特币采用进行比较,比特币从边缘爱好者论坛的互联网货币演变为贝莱德(BlackRock)批准的“数字黄金”的一个原因就是,开发者和社区创作内容的激增,培养了人们的兴趣。就目前而言,ZK存在于气泡中的气泡中。信息是分散极化的,文章里要么充斥着晦涩难懂的术语,要么过于外行,除了重复使用的例子之外,没有传达任何有意义的信息。似乎所有人(专家和外行)都知道什么是零知识证明,但没有人能描述它实际上是如何工作的。
作为贡献于零知识范式的团队之一,我们希望揭开我们工作的神秘面纱,帮助更广泛的受众建立理解和分析ZK系统和应用程序的规范基础,以推动相关各方之间的教育宣传和讨论,使相关信息得以传播扩散。
本中,我们将介绍零知识证明和零知识虚拟机的基础知识,对zkVM的运作过程进行高层次的总结,最后对zkVM的评估标准进行分析。
什么是零知识证明(ZKP)?
简而言之,ZKP使一方(prover证明者)能够向另一方(verifier验证者)证明他们知道某事物,但无需透露该事物的具体内容或任何其他信息。更具体地说,ZKP证明了对一段数据或对计算结果的认知,而不透露该数据或输入内容。创建零知识证明的过程涉及一系列数学模型,将计算结果转换为证明代码成功执行的在其他情况下无意义的信息,这些信息将于稍后被验证。
在某些情况下,验证经过多轮代数转换和密码学构建的证明所需的工作量比运行计算所需的工作量要少。正是这种安全性和可扩展性的独特组合使零知识加密成为如此强大的工具。
zkSNARK:零知识简洁非交互式知识论证
·依赖于初始(受信或不受信)设置过程来建立用于验证的参数
·要求证明者和验证者之间至少有一次交互
·证明较小,易于验证
·像zkSync、Scroll和Linea这样的rollup使用基于SNARK的证明
zkSTARK:零知识可扩展透明知识论证
·无需受信设置
·通过使用可公开验证的随机性来创建无需信任的可验证系统,即生成可证明的随机参数来进行证明和验证,从而提供高透明度。
·高度可扩展,因为它们可以快速(并非总是)生成和验证证明,即使底层见证(数据)很大。
·证明者和验证者之间不需要交互
·代价是STARK会生成更大的证明,这比SNARK更难验证。
·证明比一些zkSNARK证明更难验证,但相对于其他证明更易验证。
·Starknet和zkVM(如Lita、Risc Zero和Succinct Labs)都使用STARK。
(注意:Succinct bridge使用SNARK,但SP1是基于STARK的协议)
值得注意的是,所有的STARK都是SNARK,但并非所有的SNARK都是STARK。
虚拟机(VM)是运行程序的程序。在上下文中,zkVM是一种虚拟计算机,它被实现为生成零知识证明的系统、通用电路或工具,用于为任何程序或计算生成zkVM。
zkVM不要求学习复杂的数学和密码学来设计和编码ZK,让任何开发人员都可以执行用他们喜欢的语言编写的程序并生成ZKP(零知识证明),从而更容易与零知识集成和交互。从广义上讲,大多数zkVM都意味着包括附加到执行程序的虚拟机的编译器工具链和证明系统,而不仅仅是虚拟机本身。下面,我们总结了zkVM的主要组件及其功能:
每个组件的设计和实现都由zkVM的证明(SNARKs或STARKs)和指令集架构(ISA)的选择来控制。传统上,ISA指定了CPU的能力(数据类型、寄存器、内存等)以及CPU在执行程序时执行的操作顺序。在上下文中,ISA确定可由VM解释和执行的机器码。选择ISA可以在zkVM的可访问性和可用性,以及证明生成过程的速度和效率方面产生根本性的差异,并支持任何zkVM的构建。
下面是一些zkVM及其组件的示例,仅供参考。
现在,我们将重点关注每个组件之间的高层交互,以便在后面的文章中提供一个框架,用于理解代数和加密过程以及zkVM的设计权衡。
下图是一个抽象的、一般化的zkVM流程图,当程序在zkVM组件之间移动时,进行格式(输入/输出)的拆分和分类。
zkVM的流程一般如下:
(1)编译阶段
编译器首先将使用传统语言(C、C++、Rust、Solidity)编写的程序编译成机器码。机器码的格式由所选的ISA来决定。
(2)VM阶段
VM执行机器码并生成执行跟踪,这是底层程序的系列步骤。它的格式由算法的选择和多项式约束集来决定。常见的算法方案包括Groth16中的R1CS、halo2中的PLONKish算法以及plonky2和plonky3中的AIR。
(3)验证阶段
证明者接收跟踪并将其表示为一组受一组约束限制的多项式,本质上是通过数学映射事实将计算转换为代数。
证明者使用多项式承诺方案(PCS)提交这些多项式。承诺方案是一个协议,它允许证明者创建一些数据X的指纹,这被称为对X的承诺,然后使用对X的承诺来证明关于X的事实而同时不泄露X的内容。PCS就是指纹,计算约束的“预处理”简明版本。这允许证明者使用验证者在接下来的步骤中提出的随机值来证明有关计算的事实,现在用多项式方程来表示。
证明者运行一个多项式交互Oracle证明(PIOP)来证明所提交的多项式代表了满足给定约束条件的执行轨迹。PIOP是一个交互式证明协议,其中证明者向多项式发送承诺,验证者用随机字段值响应,证明者提供对多项式的评估,类似于使用随机值“求解”多项式方程以概率方式来说服验证者。
Fiat-Shamir启发式的应用;证明者以非交互模式运行PIOP,在这种模式下,验证者的行为仅限于发送匿名随机挑战点。在密码学中,Fiat-Shamir启发式将交互式知识证明转换为用于验证的数字签名。这一步加密了证明并使其成为零知识证明。
证明者必须说服验证者,关于它发送给验证者的多项式承诺,声称的多项式评估是正确的。为了做到这一点,证明者产生一个“evaluation”或“opening”证明,由多项式承诺方案(指纹)提供。
(4)验证者阶段
验证者通过遵循证明系统的验证协议来检查证明,要么使用约束,要么使用承诺。验证者根据证明的有效性接受或拒绝结果。
总之,zkVM证明可以证明,对于给定的程序、给定的结果和给定的初始条件,存在一些输入,使程序从给定的初始条件执行产生给定的结果。我们可以将该语句与流程结合起来,得到关于zkVM的以下描述。
zkVM证明将证明,对于给定的VM程序和给定的输出,存在一些输入,导致给定的程序在VM上执行时产生给定的输出。
我们评估zkVM的标准是什么?换句话说,我们应该在什么情况下说一个zkVM比另一个更好?实际上,答案取决于用例。
Lita的市场研究表明,对于大多数商业用例,在速度、效率和简洁性之间,最重要的属性要么是速度,要么是内核时间效率,这取决于应用程序。一些应用对价格敏感,希望将证明过程优化为低能耗和低成本的,对于这些应用而言,内核时间效率可能是最重要的优化指标。其他应用程序,特别是金融或交易相关的应用程序,对延迟非常敏感,需要优化速度。
大多数公开的性能比较只关注速度,速度当然很重要,但却不是性能的全面衡量。还有一些重要的属性可以衡量zkVM的可靠性,其中大多数都达不到生产标准,即使是市场领先的老牌企业。
我们建议按照以下标准对zkVM进行评估,并将其分为两小类:
基线:用于度量zkVM的可靠性
·正确性
·安全性
·信任假设
性能:用于衡量zkVM的能力
·效率
·速度
·简洁性
(1)基线:正确性、安全性和信任假设
在评估关键任务应用程序的zkVM时,应该将正确性和安全性作为基准。需要有足够的理由对正确性有信心,并且需要有足够强的声明安全性。此外,对于应用程序来说,信任假设需要足够弱。
如果没有这些属性,zkVM对应用程序来说可能比毫无用处更糟糕,因为它可能无法按照指定的方式执行,并使用户暴露于黑客攻击和漏洞攻击之下。
正确性
·VM必须按预期执行计算
·证明系统必须满足其声称的安全属性
正确性包含三大属性:
·稳健性:证明系统是真实的,因此它所证明的一切都是真的。验证者拒绝接受虚假陈述的证据,只接受输入产生实际计算结果的计算结果。
·完备性:证明系统是完备的,能够证明所有的真实陈述。如果证明者声称它可以证明计算的结果,它必须能够产生验证者可接受的证明。
·零知识证明:与知道结果本身相比,拥有一个证明并不能揭示更多关于计算输入的信息。
你可能拥有完整性而没有稳健性,如果证明制度证明了包括虚假陈述在内的一切,显然它是完备的,但并不健全。而你也可能拥有健全性但没有完整性,如果证明系统证明了一个程序的存在,但不能证明计算,显然它是健全的(毕竟,它从来没有证明过任何虚假陈述),但不是完整的。
安全性
·与可靠性、完整性和零知识证明的公差有关
在实践中,所有三个正确性属性都具有非零公差。这意味着所有的证明都是对正确性的统计概率,而不是绝对的确定性。公差是指一个属性失效的最大可容忍概率。零公差当然是理想的,但是在实践中,zkVM并没有在所有这些属性上实现零公差。完美的稳健性和完备性似乎与简洁性并不相容,并且没有已知的方法可以实现完美的零知识证明。衡量安全性的一种常用方法是以安全性bit为单位,其中1 / (2^n)的公差称为n bit安全性。bit越高,安全性越好。
如果一个zkVM是完全正确的,这并不一定意味着它是可靠的。正确性仅意味着zkVM满足其声称的公差范围内的安全属性。这并不意味着所声称的公差低到足以进入市场。此外,如果zkVM足够安全,也并不意味着它是正确的,安全性指的是声称的公差,而不是实际实现的公差。只有当zkVM既完全正确又足够安全时,才能说zkVM在声称的公差范围内是可靠的。
信任假设
·假设证明者和验证者的诚实性,以得出zkVM可靠运行的结论。
当zkVM具有信任假设时,通常采用可信设置过程的形式。在使用该证明系统生成第一个证明之前,ZK证明系统的设置过程将运行一次,以生成一些称为“设置数据”的信息。在可信设置过程中,一个或多个个体生成一些随机性,这些随机性被合并到设置数据中,并且需要假设这些个体中至少有一个删除了他们合并到设置数据中的随机性。
实践中有两种常见的信任假设模型。
“诚实的大多数”信任假设表明,人数为N的一组人中,超过一半的人在与系统的某些特定交互中表现是诚实的,这是区块链常用的信任假设。
“1 / N”信任假设表明,在人数为N的一组人中,这些人中至少有一个人在与系统的某些特定交互中表现为诚实的,这是基于MPC的工具和应用程序通常使用的信任假设。
人们普遍认为,在其他条件相同的情况下,没有信任假设的zkVM比需要信任假设的zkVM更安全。
(2)zkVM三难困境:zkVM中速度、效率和简洁性的平衡
速度、效率和简洁性都是可扩展的属性。所有这些因素都会增加zkVM的最终用户成本。如何在评估中对它们进行权衡取决于应用程序。通常,最快的解决方案并不是最有效或最简洁的,最简洁的解决方案并不是最快或最有效的,以此类推。在解释它们之间的关系之前,让我们先来定义一下各个属性。
速度
·证明者生成证明的速度有多快
·以挂钟时间计算,即计算从开始到结束所经过的时间
应该根据具体的测试程序、输入和系统来定义和衡量速度,以确保可以对速度进行定量评估。这个指标对于延迟敏感类的应用程序来说是至关重要的,在这些应用程序中,证明的及时可用性是必不可少的,但是它也带来了更高的开销和更大的证明。
效率
·证明者消耗的资源,越少越好。
·近似于用户时间,即程序代码所花费的计算机时间。
证明者消耗两种资源:内核时间和空间。因此,效率可以细分为内核时间效率和空间效率。
内核时间效率:prover跨所有内核运行的平均时间乘以运行prover的核心数量。
对于单核prover来说,内核时间消耗和速度是一回事。对于在多核系统上以多核模式运行的多核功能prover来说,内核时间消耗和速度不是一回事。如果一个程序在5秒内充分利用了5个内核或线程,那么这将是25秒的用户时间和5秒的挂钟时间。
空间效率:指已使用的存储容量,如RAM。
将用户时间作为运行计算所消耗的能量的代理是非常有趣的。在几乎所有内核都被充分利用的情况下,CPU的能量消耗应该保持相对恒定。在这种情况下,一个受CPU限制的、主要是用户模式的代码执行所花费的用户时间应该大致与代码执行所消耗的瓦时(即能量)成线性比例。
从任何具有足够规模的证明操作的角度来看,节约能源消耗或计算资源的使用应该是一个有趣的问题,因为证明的能源费用(或云计算费用)是相当大的操作成本。由于这些原因,用户时间是一个有趣的衡量标准。较低的证明成本允许服务提供商将较低的证明价格传递给成本敏感型客户。
这两种效率都与证明过程的能量消耗和证明过程所使用的资金量有关,而资金量又与证明的财务成本有关。为了使衡量效率的定义可操作,该定义必须与一个或多个测试程序、每个程序的一个或多个测试输入以及一个或多个测试系统相关。
简洁性
·生成的证明的大小和验证它们的复杂性
简洁性是三个不同指标的组合,按证明验证的复杂性进一步细分为:
·证明大小:证明的物理大小,通常以千字节为单位。
·证明验证时间:验证证明所需的时间。
·证明验证空间:证明验证时的内存使用情况。
验证通常是单核操作,因此在此情境中,速度和内核时间效率通常是一回事。与速度和效率一样,简洁性的定义需要指定测试程序、测试输入和测试系统。
定义了每个性能属性后,我们将演示优化一个属性而非其他属性所产生的影响。
·速度:快速的证明生成导致证明更大,但证明验证速度较慢。生成证明消耗的资源越多,效率越低。
·简洁性:Prover需要更多的时间来压缩证明。但证明验证速度很快。证明越简洁,计算开销就越高。
·效率:最大限度地减少资源使用,将减缓证明生成的速度,降低证明的简洁性。
一般来说,针对一方面进行优化意味着另一方面得不到优化,因此需要进行多维分析,以便在逐个案例的基础上选择最佳解决方案。
在评估中对这些属性进行权衡的一个好方法可能就是为每个属性定义可接受的程度,然后确定哪些属性是最重要的。应该对最重要的属性进行优化,同时在所有其他属性上保持足够好的水平。
下面我们总结了各属性及其关键考虑因素: