ZK-Score:零知识证明的硬件衡量标准

345 阅读19分钟

1.简介

零知识证明(ZKPs)即将成长为主流技术之一,在经历这些成长的困难时,我们着眼于已经完成这种转变的更成熟的技术-AI,以此为借鉴。并认识到建立一个清晰框架来比较不同ZK技术栈的重要性。如下面我们要谈论的一样,这个问题仍是复杂且开放的。我们认为,一个很好的第一步将是使用ZK Score: 在硬件层面确定每焦耳证明(the proofs-per-Joule)数量的上限。

Zk Score

Zk Score

2.孪生姐妹:How We Benchmark AI

我们可以从AI的工作中获得一些灵感。到2023年,AI是一项比ZK成熟得多的技术。因为人工智能训练的速度超过了摩尔定律,人工智能随着计算的进步而进步。因此,AI系统的性能完全依赖于硬件加速。在AI基准测试(AI benchmark)竞赛中,竞争者是硬件设备,以及运行它们的配套软件。通常情况下,相同的芯片(例如Nvidia H100)会用于多个不同的设备,并最终相互竞争。

最广为人知的基准测试工具是由MLCommons(一个由学术界、研究实验室和行业的AI领导者组成的联盟)开发的一套名为MLPerf[1]的测试组件。MLPerf是一个随时间而不断发展,维护良好的项目。在最近的2023年版本中,MLPerf首次开始衡量大型语言模型(LLM)的性能。

我们假设,为零知识证明(ZK)设计一套公平、易于重现且快速的基准测试套件,至少与为人工智能(AI)设计基准测试一样困难。那让我们暂时考虑一下LLM(大型语言模型)的训练基准。要重现它们可能需要花费数百万美元,因此人们发明了一些巧妙的方法来测量它们。看看MLCommons哲学页面上的这句令人敬畏的话。

“ML and artificial intelligence have been around for decades, but even today the technology is fragmented, bespoke, and poorly understood. We believe that we can unlock the next stage of AI/ML adoption by creating useful measures of quality and performance.”

听起来耳熟吗?

MLPerf是一个由多个测试组成的竞赛,它包含了几个赛道,允许全面覆盖并以不同的方式比较机器学习系统。

  • 基准测试的基本测量单位是吞吐量,即每秒能处理多少个样本或查询。选择使用样本还是查询取决于两种不同的场景:离线处理和服务器查询
  • 围绕吞吐量的功率测量。
  • 参与者也可以为网络性能提交他们的测试结果
  • 最受欢迎的赛道是进行直接比较(称为“封闭”赛道),在这个赛道中,所有参与者必须使用相同的模型和优化方法。还有一个“开放”赛道,允许团队使用任何他们想要的配置,只要能够达到正确的(超过预设阈值或以其他方式定义的)结果。"

几个要点。首先,MLPerf成为行业标准需要来自数十个组织的支持:从小型到大型的初创公司、大学以及大型企业;以及来自多样化利益相关者的支持:云计算平台、半导体公司、研究人员和应用开发者。其次,MLPerf始于2018年,最近才推出了第八版,即3.1版本。要知道,规模化产品中的人工智能技术也才有大约10年的历史。MLPerf提醒我们,需要持续的努力和奉献,才能得以保持“以架构中立、具有代表性且可复现的方式对机器学习(ML)系统性能进行行业标准基准测试”。这个领域不断向前发展,其基准测试工具也在不断进步。

在将零知识证明(ZK)与人工智能(AI)进行类比时,需要注意一个区别。在ZK中,输出是可验证的计算。这是一个二元结果;我们要么达到了某些安全参数所要求的性质(e.g,soundness),要么没有达到。而在AI领域,我们是在构建智能。我们可以根据系统执行特定任务的表现来衡量其优劣。例如,根据目标的不同,任务可能是分类或对语言模型进行专门的整体评估[2]。在某种程度上,这使我们的工作更加简单,前提是我们能够将安全强度标准化。

3.ZK硬件性能简介

如今,大多数零知识证明(ZK)计算都在CPU上运行。GPU、FPGA和ASIC都是ZK证明计算的合法目标设备。我们建议观看这个出色的 演讲[3],以了解更多关于这些设备之间差异的信息。

不幸的是,我们自己行业内的硬件社区仍在努力与既定的规范和标准保持一致。SuperScalar最近的一篇关于Aleo Prover的博客文章[4]就说明了这一点。Aleo是一种区块链,它通过设计使用零知识证明(ZKP)来保护隐私。它还以类似于挖矿的方式,在共识层面使用ZKP。简而言之,如果你的证明吞吐量高,你挖矿成功的概率就更高,随之而来的是获得更多的奖励。

在上述博客文章中,基于FPGA技术的新型K10矿机(以下简称K10矿机),与Nvidia RTX 3090 GPU(以下简称3090 GPU)进行了比较: Source SuperScalar:PPS stands for proofs per second.

在这里,请读者思考几个问题

  1. 3090 GPU有什么特别之处?为什么不将新型K10矿机与更新、更好的Nvidia RTX 4090 GPU进行比较呢?
  2. 仅比较吞吐量是否真的有意义?如果以吞吐量作为比较指标,为什么不取一个CPU主机,连接4×3090 GPU,以获得总吞吐量为28K PPS,并称之为K12呢?现实世界中的FPGA零知识证明(ZK) Prover与GPU Prover类似,多个PCIe卡插入一个主机CPU。

在进一步讨论之前,我们想简要介绍一个在硬件领域重要的术语:总拥有成本(TCO) 。定义上比较宽泛,我们可以说TCO是购买设备的成本(CAPEX),加上设备在其生命周期内的运营成本(OPEX),减去在设备生命周期结束时出售设备的收入(RESALE)

回到我们的例子,即基于GPU与基于FPGA的Aleo矿机。我们最初的目标是在比较它们的性能之前,先将两种设备的总拥有成本(TCO)等同起来。根据对供应商的查询,单个K10矿机的成本是4500美元,而根据howmuch.one[5]的数据,购买单个3090 GPU的成本在700美元(新的)到500美元(二手)之间。因此,一个K10矿机的价格可以买到七到九个3090 GPU。

关于运营开支,我们可以假设电费是固定的,对两者都是一样的。SuperScalar的文章指出,K10矿机的功耗是1200瓦。注意,这个数字是依应用而定的。根据技术规格,3090 GPU的总耗散功率(TDP)是350瓦。这并不意味着如果我们实施同样的应用,就会消耗这么多电力,但为了这次分析,让我们假设最坏的情况,即需要最大功率。

现在,我们可以通过功率来进行标准化:生成一个证明需要多少焦耳? (瓦特(W)定义为每秒一焦耳) Source: SuperScalar. K10 prover’s power consumption

对于K10矿机,我们计算得出:24000 PPS/1200W = 20证明/焦耳

对于3090 GPU,我们计算得出:7000 PPS/350W = 20证明/焦耳

这些计算显示,K10矿机相比3090 GPU并无优势.换句话说,由于两者的功耗相同,我们生成证明的成本也相同。无论我们拥有多少K10矿机或3090 GPU,这都无关紧要。

有趣的事实是:对于Nvidia RTX 4090 GPU,其成本为1500美元(在本文撰写时),我们计算得出16000 PPS/450W > 35证明/焦耳。所以,用你的美元可以得到更多的证明!

最后,我们考虑到转售价格。在这里,我们可以假设3090 GPU将保留更多的价值。我们有确凿的数据表明[6],一年使用的二手3090 GPU几乎没有价值贬值(将2022年10月的价格与2023年10月的价格进行比较),并且我们知道3090 GPU可以轻松地用于游戏、科学等其他用途。另一方面,K10矿机是一台专用的挖矿机器,不幸的是,我们没有任何关于其转售价格的数据。因此,比较转售价值是不切实际的。当然,依靠历史数据并不能预测未来的价格,而这正是计算总拥有成本(TCO)时所需的。

这是否意味着3090 GPU比K10矿机更好或更差?很难说,因为涉及到TCO,而且很难标准化。 例如,如果一台设备的物理尺寸比另一台大得多怎么办?也就是说,数据中心机架上的实际占用空间不同,因此会影响成本和TCO。此外,还有其他几个因素需要考虑。包括但不限于:电力基础设施、维护和可靠性。根据上述信息,我们的观点是,就硬件产品中的ZK性能测量而言,我们离黄金标准还有很长的路要走。

所以我们需要ZK Score

4: ZK Score

ZK Score的主要价值在于其简洁性。目前,ZK领域深入参与中间件和基础设施研发。在应用层面的活动非常少。继续我们的Aleo例子,基金会开发了一个运行应用程序的prover,但我们还不知道哪些应用程序会成为杀手级应用。ZKML也是如此。我们知道我们想要使用哪种机器学习,基础设施越来越好,但目前还没有真正的用例在大规模运行。这就是为什么我们认为目前作为第一步,我们应该专注于基础设施基准测试,从硬件开始。

就在这个早期阶段,我们已经可以谈论设计用于高效运行ZK Prover的各种用例的设置和系统。比如,K10矿机是一个基于FPGA的系统,可以支持有限的ZK协议集。Nvidia DGX[7]是一种现成的设备,配备了8xH100卡,可以编程运行任何ZK协议,但在效率方面产生不同的结果。此外,我们可以采用AWS F1实例(FPGA),通过局域网(LAN)连接到另一个带有Nvidia T4 GPU的实例,并称之为第三个系统。显然,我们可以预期每个系统的性能不同,但我们如何将它们相互排名呢?

理解哪个系统更高效非常重要,这样可以指导我们在未来几年内的努力,以改善ZK基础设施。例如,如果K10矿机具有最佳的ZK Score,我们希望看到更多的工作专注于最大化FPGA的潜力,更多针对这种设备的中间件,对K10矿机变体的实验,以及与更多应用的集成。

最直接的ZK Score是吞吐量/功率。这也是根据人工智能基准测试的最佳实践。区别在于,对于AI,我们测量端到端样本的吞吐量。ZK的等效方法是测量每秒证明的吞吐量。然而,正如我们稍后将展示的那样,这增加了复杂性,使排名更加困难。

只要我们没有标准化的测试套件,在引入最小偏见的情况下,我们能做到的最好的是直接在硬件本身上测量与ZK相关的操作。即便如此,我们必须区分高级和低级原语,并倾向于更低级的原语,以减少复杂性。我们在这种权衡中失去的是准确性,我们只能大致估计系统所达到的吞吐量上限。

4.1 Low-level Primitives for ZK Hardware

现在,我们采取更具体的方法来确定ZK Score的候选者。在ZKP中(就像在密码学的许多其他地方一样)使用的算术是模运算,模乘法比模加法使用得更频繁。更复杂原语上的算术运算,特别是在一些流行的ZK协议中使用的椭圆曲线,可以分解为多个模乘法和加法。事实上,就像任何算术一样,加法和乘法构成了一个完整的功能性语言,我们可以用它来表达任何ZK协议。模乘法有两种流行的算法:Barret和Montgomery

它们覆盖了大多数现有实现。这些算法自1980年代以来就存在,并经历了多年的实战测试。尽管在模乘器领域仍有一些活跃的研究[8],但它们通常最终成为Barret或Montgomery的扩展或变体。由于这些算法处于如此成熟的状态,可以安全地假设对这一层的进一步优化是不太可能的

在上一层,我们有椭圆曲线(EC)算术,从基本的点加法到向量运算,如多标量乘法(MSM)。EC密码学在2000年初开始广泛使用,此后一直受到越来越多的关注,包括在区块链密码学中。它是一个比模算术领域更广的领域。一个EC群可以属于几个具有共同属性的家族之一。椭圆曲线点加法有多种公式,甚至表示一个EC点也可以有多种方式。EC密码学加速也是一个较新的领域。硬件中用于MSM的算法仍在探索中(参见ZPRIZE[9])。从这里开始,更高层留下了广泛的设计空间用于优化。

我们建议进行最准确的同类比较,是依赖于模乘法(mod mults)作为我们测量吞吐量的单位。请注意,这种行为像是一种上限。如果被测试的系统能够每秒产生X个mod mults,而对于一个EC加法,我们需要,比如说,5个mod mults,那么理想的EC加法吞吐量将被X除以5的结果上限。我们可以在栈上移动时使用相同的规则

4.2 Fields, Not a Field

尽管我们聚焦在每秒的模乘法操作(MMOPS)上,但仍然需要更精细的分辨率。根据多种因素和协议要求,ZK系统可以使用不同的字段来实现。如果我们对31位或64位字段的MMOPS进行基准测试,可能会得到与256位或384位字段的MMOPS不同的结果。这里可能没有中间地带,因此最好的方法是对所有感兴趣的位大小运行基准测试。也许将来,会有一些聪明的方法来对这些字段加权,以获得累积的ZK Score。

4.3 Normalizing by Power

正如我们在TCO讨论中看到的,为了使不同系统能够平等对待,需要审视几个要素。在构成TCO的三个主要要素中,只有OPEX是可测量的。同一设备的CAPEX和转售价格可能有显著差异,且难以量化或比较。OPEX最接近的近似值将是系统在运行其设计运行的工作负载时的电费。也就是说,我们需要在相同的时间单位内测量功耗。该测量单位是瓦特。因此,我们得出的ZK Score定义是:

4.4 Summary

随着ZK领域的持续发展,对可靠基准测试标准的需求显而易见。零知识证明(ZKP)的演变是一个充满复杂性的不断变化的目标,这使得进行测量变得具有挑战性。幸运的是,我们可以从人工智能社区解决这个问题的方式中获得灵感。基于这一点,我们建议将ZK Score作为解决比较苹果对苹果问题的第一步。ZK Score以简单性和确定性为驱动,它将允许我们通过基于模乘法吞吐量的上限来评估和比较不同的ZK系统,这些系统可以在给定时间框架内运行,并且会按功耗进行标准化。在第二部分中,我们将讨论ZK Score的现有替代方案。

5: ZKP 比较方法的陷阱

为了展示在量化分析和测量ZKP性能方面的挑战,我们将引用文献中使用的一些流行方法,并讨论每种方法的一些缺点。

5.1 复杂性理论

一些ZK论文将比较限制在理论层面,动机很明确。复杂性理论提供渐近性能,通常使用大O表示法来指示诸如Prover运行时间等指标如何基于输入大小增长。这种比较形式非常清晰,允许立即得出结论:如果一个证明者需要O(N)时间,另一个证明者需要O(NlogN)时间,那么显然O(N)的证明者更好。仅依靠这种方法存在一些问题。两者的根本原因都是复杂性理论并不很好地反映现实世界:

  1. 当我们比较两个具有相同复杂度的协议时,没有考虑决定哪个更好的常数因子。例如,假设对于一个群元素操作,我们需要三个字段元素操作,这意味着下面图表中第一行和第二行的比例是3。但是,如果第一行的实际性能(去除大O表示法)是N个群操作,或3N个字段操作,而第二行的实际性能是50N个字段操作呢?没有这些信息,我们无法判断哪个在实践中更好。
  2. ZK工程是混乱的。复杂性理论视角避开了相关的实现细节。有时细节会包含一些重要的事情,比如内存需求(不要与证明大小混淆,在这里我们指的是证明在计算过程中使用多少内存)。其他时候是一些其他隐藏的缺失成本。让我们看一下来自Lasso[10]的一个图表。注意这句话,“除了报告的O(N)字段操作,Hyrax和Dory还需要大约O(N^½)的加密工作来计算评估证明。”工程是权衡的艺术。当我们实现一个协议时,我们被迫做出多个决策,基于系统要求、可用硬件、编程语言等。这些事情需要考虑在内 Source Lasso

5.2 增加 POC 实现

一些论文进一步实现了他们的ZK协议。论文中描述通常针对可用的硬件的系统设置。这种方法有两个问题。

  1. 是我们想要比较哪个系统或协议。理想情况下,我们希望将一个实现与所有其他实现进行比较。但在实践中,如今用于证明生成的设计空间如此多样,以至于几乎从未进行过同类之间的比较。让我们看看Hyperplonk论文下面的表格,我们看到Hyperplonk与Ark-Spartan相比较。然而,这两个系统使用了完全不同的算术化技术,即R1CS和Plonk+。以倒数第二个应用(rollup)为例,R1CS系统的约束数量是Plonk+约束的32倍。因此,证明者运行时间的测量意义不清楚,因为输入测试向量的大小不同。
  2. 是应用的选择。看表格的最后一行,zkEVM应用从未以R1CS格式表达,因此无法测量。与AI做类比,就像将分类模型与LLM进行比较一样。理论上,它们都可以运行分类应用,但一个并不是为此专门设计的,而另一个则为此优化。我们预计各种协议会被优化/适用于不同的应用,但这使得理解比较为不同应用设计的两个协议背后的逻辑变得难以理解。

Source HyperPlonk

Source HyperPlonk

5.3 端到端的基准测试工具。

像EF zkalc[11]、The Pantheon of ZKP[12],和ZK bench[13]这样的最新努力,正以与复杂性理论方法完全相反的方式来看待这个问题。这意味着,它们试图运行所有现有的ZK框架,并实现任何缺失的部分。通过这种以工程为导向的方法,我们旨在理解各种协议的性能,考虑到输入大小作为一个变量。这种方法有几个问题。

  1. 实现的电路可能没有完全优化,主要是因为ZK DSLs仍处于初期阶段。
  2. 与我们在前一个案例中看到的类似,通过查看结果很难得出有意义的结论。下面的图表似乎表明所有的框架都大致具有相同的性能。

Source zk-bench

Source zk-bench

结论

虽然使用复杂性理论、比较实施数据和使用端到端基准测试工具已经尝试规范比较ZKP的方法,但它们都存在缺陷。我们撰写这篇文章的动机不是要质疑,而是为了激励ZK社区制定可能类似于AI的方法和标准,更准确地反映ZKP的性能。最终目标是一种公平、可重现且快速的方式,来进行现实世界的比较分析。我们提出ZK Score供您考虑,并作为实现该目标的潜在第一步。

联系我们

Discord: discord.com/invite/qkBV…

Twitter: twitter.com/Ingo_zk

Github: github.com/ingonyama-z…

YouTube: www.youtube.com/@ingo_zk

参考资料

[1]

MlPerf: mlcommons.org/2023/09/mlp…

[2]

helm: crfm.stanford.edu/helm/latest…

[3]

intro to zk hardware by TonyWu: www.youtube.com/watch?v=yC5…

[4]

SuperScalar Launches the World’s First ZKP FPGA Miner K10 and K11 for Aleo: medium.com/@SuperScala…

[5]

howmuch.one: howmuch.one/product/ave…

[6]

howmuch.one关于gpu价格: howmuch.one/product/ave…

[7]

Nvidia DGX: www.nvidia.com/en-us/data-…

[8]

模乘研究: github.com/ingonyama-z…

[9]

ZPRIZE: zprize.hardcaml.com/msm-overvie…

[10]

Lasso: people.cs.georgetown.edu/jthaler/Las…

[11]

zkalc: crypto.ethereum.org/blog/zkalc

[12]

The Pantheon of ZKP: blog.celer.network/2023/08/04/…

[13]

zk bench: zkbench.dev/

本文使用 markdown.com.cn 排版