查看原文
其他

ZK-Score:ZK 硬件排名标准

PlanckerDAO 2024-03-11

Editor's Note

原作者:@OmerShlomovits, @lucyw_earth

原文:https://zkproof.org/2023/10/23/zk-score-blog/
本文基于 Miles 已有翻译之上,对某些段落和语句做了二次优化。

The following article is from Ingonyama CN Author Miles

简介

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

Zk Score

孪生姐妹:How We Benchmark AI

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

最广为人知的基准测试工具是由 MLCommons[1](一个由学术界、研究实验室和行业的 AI 领导者组成的联盟)开发的一套名为 MLPerf[2]的测试组件。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 版本[3]。要知道,规模化产品中的人工智能技术也才有大约 10 年的历史。MLPerf 提醒我们,需要持续的努力和奉献,才能得以保持「以架构中立、具有代表性且可复现的方式对机器学习 (ML) 系统性能进行行业标准基准测试」。这个领域不断向前发展,其基准测试工具也在不断进步。

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

ZK 硬件性能简介

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

不幸的是,我们行业内的硬件社区仍在努力与既定的规范和标准保持一致。SuperScalar 最近一篇关于 Aleo Prover 的博客文章[6] 就说明了这一点。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),减去在设备生命周期结束时出售设备的收入。

回到我们的例子,即基于 GPU 与基于 FPGA 的 Aleo 矿机。我们最初的目标是在比较它们的性能之前,先将两种设备的总拥有成本(TCO)等同起来。根据对供应商的查询,单个 K10 矿机的成本是 4500 美元。而根据 howmuch.one[7]的数据,购买单个 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 proofs/Joule

对于 3090 GPU,我们计算得出:7000 PPS/350W = 20 proofs/Joule

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

有趣的事实是:对于 Nvidia RTX 4090 GPU,其成本为 1500 美元(在撰写本文时的价格),我们计算得出 16000 PPS/450W > 35 proofs/Joule。也就是每焦耳能产生超过 35 个证明,每秒可以处理 16000 个 PPS,功耗是 450瓦。这意味着你花的每一分钱都能得到更多的证明!

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

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

所以我们需要 ZK Score。

ZK Score

ZK Score 的主要价值在于其简洁性。目前,ZK 领域深入参与中间件和基础设施研发。在应用层面的活动非常少。还用 Aleo 例子,基金会开发了一个运行应用程序的 prover,但我们还不知道哪些应用程序会成为杀手级应用。零知识机器学习(ZKML)也是如此。虽然我们明确了要采用的机器学习(ML)技术,并且技术支持方面(比如计算能力、数据处理能力等)也在持续变得更加完善,但是现实中还没有看到哪些应用是在大规模地、实际运作中使用这些技术的。这就是为什么我们认为目前作为第一步,我们应该专注于基础设施基准测试,从硬件开始。

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

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

最直接的 ZK Score 是吞吐量/功率。这也是根据 AI 基准测试的最佳实践。区别在于,对于 AI,我们测量端到端样本的吞吐量。ZK 的等效方法是测量每秒证明的吞吐量。然而,这增加了复杂性,使排名更加困难,这点我们会在后面解释。

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

4.1 Low-level Primitives for ZK Hardware

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

它们覆盖了大多数现有实现。这些算法自 1980 年代以来就存在,并经历了多年的实战测试。尽管在模乘器领域仍有一些活跃的研究[10],但它们通常最终成为 Barret 或 Montgomery 的扩展或变体。因为这些算法已经非常成熟了,所以我们可以放心地认为:对这一层面进一步优化的可能性不大

在上一层,我们有椭圆曲线(EC)算术,从基本的点加法到向量运算,如多标量乘法(MSM)。EC 密码学在 2000 年初开始广泛使用,此后一直受到越来越多的关注,包括在区块链密码学中。这个领域比简单的数字运算要广泛得多,因为椭圆曲线有好几种类型,每种都有它们的特点。甚至,我们表示椭圆曲线上的点的方式都有很多种。现在,人们还在探索如何在硬件上加速这种椭圆曲线的计算,EC 密码学加速也是一个较新的领域。硬件中用于 MSM 的算法仍在探索中(参见 ZPRIZE[11])。随着我们往技术的更高层次走,会有更多的新东西出现,也就意味着有很多机会去做优化。

我们建议为了进行最精准的同类直接比较,应该依赖于模乘法(mod mults)作为我们测量吞吐量的单位,这相当于一种上限,也就是把这个当作一个最大可能性的标准来看。如果一个被测试的系统每秒能产生 X 个模乘,而我们做一个 EC 加法需要,比方说,5 个模乘,那么理想的 EC 加法吞吐量的上限就是 X 除以 5。我们可以应用同样的规则,随着我们的技术栈往更高层次走。

4.2 多个而非单一领域

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

4.3 按功率标准化

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

4.4 总结

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

5.ZKP 比较方法的陷阱

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

5.1 复杂性理论

一些 ZK 论文将比较限制在理论层面,动机很明确。复杂性理论提供渐近性能,通常使用大写的 O 表示法来指示诸如Prover 运行时间等指标如何基于输入大小增长。这种比较形式非常清晰,可以立即得出结论:如果一个证明者需要 O(N)时间,另一个证明者需要 O(NlogN) 时间,那么显然 O(N) 的证明者更棒,因为较低的时间复杂度通常意味着在大量输入的情况下算法更有效率。但是,严格依赖这种方法有几个问题。两者的根本原因在于,复杂性理论并不能很好地反映现实世界:

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

5.2 增加 POC 实现

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

第一个问题是我们想要比较哪个系统或协议?理想情况下,我们希望将一个实现与所有其他实现进行比较。但在实践中,如今用于证明生成的设计空间如此多样,以至于几乎从未进行过同类之间的比较。让我们看看 Hyperplonk[13]论文下面的表格,我们看到 HyperplonkArk-Spartan 相比较。然而,这两个系统使用了完全不同的算术化技术,即 R1CS 和 Plonk+。以倒数第二个应用(rollup)为例,R1CS 系统的约束数量是 Plonk+ 约束的 32 倍。因此,由于输入测试向量的大小不同,证明者运行时间的测量意义不清楚。

第二个问题是应用的选择。看表格的最后一行,zkEVM 应用从未以 R1CS 格式表达,因此无法测量。与 AI 做类比,就像将分类模型与 LLM 进行比较一样。理论上,它们都可以运行分类应用,但一个并不是为此专门设计的,而另一个则为此优化。我们知道每种协议都可能更适合某种特定的用途,所以当你试图比较两个各自为不同事情打造的协议时,弄清楚为啥要这么比就变得有点复杂了。

Source HyperPlonk

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

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

  • 首先,实现的电路可能没有完全优化,主要是因为ZK DSLs仍处于初期阶段。
  • 其次,与我们在前一个案例中看到的类似,通过查看结果很难得出有意义的结论。下面的图表似乎表明所有的框架都大致具有相同的性能。
Source: zk-bench, Fig. 8 – SHA 256 execution time

5.4 结论

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



参考资料
[1]

MLCommons: https://mlcommons.org/

[2]

MLPerf: https://mlcommons.org/2023/09/mlperf-results-highlight-growing-importance-of-generative-ai-and-storage/

[3]

3.1 版本: https://mlcommons.org/2023/09/mlperf-results-highlight-growing-importance-of-generative-ai-and-storage/

[4]

一个全面的专业评估: https://crfm.stanford.edu/helm/latest/

[5]

不错的演讲: https://www.youtube.com/watch?v=yC5VN6l5kXM

[6]

SuperScalar 最近一篇关于 Aleo Prover 的博客文章: https://medium.com/@SuperScalar_io/superscalar-launches-the-worlds-first-zkp-fpga-miner-k10-and-k11-for-aleo-1b987512e7f2

[7]

howmuch.one: https://howmuch.one/product/average-nvidia-geforce-rtx-3090-24gb/price-history

[8]

确凿的数据表明: https://howmuch.one/product/average-nvidia-geforce-rtx-3090-24gb/price-history

[9]

Nvidia DGX: https://www.nvidia.com/en-us/data-center/dgx-platform/

[10]

活跃的研究: https://github.com/ingonyama-zk/papers/blob/main/multi_precision_fast_mod_mul.pdf

[11]

ZPRIZE: https://zprize.hardcaml.com/msm-overview.html

[12]

Lasso: https://people.cs.georgetown.edu/jthaler/Lasso-paper.pdf

[13]

Hyperplonk: https://eprint.iacr.org/2022/1355.pdf

[14]

EF zkalc: https://crypto.ethereum.org/blog/zkalc

[15]

The Pantheon of ZKP: https://blog.celer.network/2023/08/04/the-pantheon-of-zero-knowledge-proof-development-frameworks/

[16]

ZK bench: https://zkbench.dev/



Ingonyama 联系方式
Discord: https://discord.com/invite/qkBVXBpFc4
Twitter:https://twitter.com/Ingo_zk
Github:https://github.com/ingonyama-zk

YouTube:https://www.youtube.com/@ingo_zk


推荐阅读

ZKP 底层协议 | 理解 PLONK

ZKP 底层 | # MSM - Barrett Reduction 公式推导



/ About  Plancker


PlanckerDAO 是一个专注建设以太坊生态的社区,我们为开发者、产品经理和研究员提供多方面支持,致力于与以太坊共建人类的数字化美好未来。

Website:https://plancker.org/

Forum:http://forum.plancker.org/

Telegram:https://t.me/PlanckerDAO

Notion:https://planckerdao.notion.site/

Twitter:https://twitter.com/PlanckerDAO

继续滑动看下一个

ZK-Score:ZK 硬件排名标准

向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存