zkVMs, 电路和优化博弈

这篇文章由 Aligned 的联合创始人兼首席技术官 @mauro_aligned 撰写，最初发表在 Aligned 博客上。

在过去的一年中，在在线讨论和 zk 会议中，以下问题不断出现。

“我们应该构建电路还是 zkVM？”“如果是 zkVM，它们应该使用像 RISC-V 这样的流行 CPU 指令吗？”

这些争论通常被框定为二元选择，我们不得不在几乎没有数据的情况下选择一方，并且没有充分权衡每种替代方案的利弊。

在实践中，优化、工程约束和安全问题都使情况变得复杂。在这篇文章中，我将论证正确的答案不仅仅是追求原始的理论速度。而是关于瓶颈在哪里，团队迭代的速度有多快，以及生态系统的弹性如何。

接下来是对两种讨论的探索：电路与 zkVM，以及 zkVM 架构的未来，无论是为零知识定制设计还是基于通用 RISC 设计。

在此过程中，将会对系统的工作方式进行一些高层次的概述，但不会深入研究数学或密码学。重点是情景和权衡，着眼于时间和资源如何影响未来的决策。

电路(Circuits) 与 虚拟机(Vms)

总是出现的第一个问题是，电路是否是可行方案，还是虚拟机才对。

一个显而易见的答案是“电路可以更快”。这是真的，但这掩盖了大部分故事。

电路之于 zkVM，就像汇编之于 Rust 或 C 等高级语言。你通常可以从汇编中榨取更多的性能，但它更难，更容易出错，并且需要更多的时间。

想想构建一个完整的以太坊执行客户端。用汇编完成所有工作和用 Rust 完成的，你犯错的几率有多大？时间、金钱和人力成本是多少？

当然，如果时间是无限的，一个伟大的团队可能会胜过编译器。但完美是交付的敌人。当你手工制作每一个优化时，市场可能已经发生了变化，代码虽然速度快，但可能无法维护。

因此，虚拟机与电路的问题很像这样。我们是使用更高级别的工具让我们行动更快，还是从头开始构建一切来追求原始速度。

当然，我仍然没有给出足够的信息来回答这个问题。如果电路以三倍的成本给你带来二十倍的性能，你可能会选择它们。

所以，这就引出了一个问题：性能提升是否值得额外的复杂性？

许多团队正在从用于 zk-EVM 的定制电路转向更简单的架构，这一事实表明团队目前如何权衡这些因素，在接下来的章节中，我们将探讨这些权衡如何发挥作用。

优化重要事项

在实践中，工程选择很少是全有或全无的。就像汇编和高级语言一样，有时正确的做法是将两者结合起来。

在 zkVM 中，这通常意味着为繁重的操作添加定制电路，然后让通用虚拟机处理其余部分。要了解为什么这种组合会产生如此大的影响，有助于更仔细地研究优化，这就是阿姆达尔定律发挥作用的地方。

早在 1967 年，吉恩·阿姆达尔就提出了一个非常简单的计算机系统经验法则。它指出，从优化系统的某个部分获得的速度提升取决于你实际在那里花费的时间。如果你 80% 的时间都花在一个地方，那么优化就非常重要。如果只有 5%，那么无论你把它做得多快，几乎都无关紧要。

现在想想一个 zkVM。假设我们有一个证明速度比定制电路慢十倍的 zkVM，并且我们发现 80% 的证明时间都花在了 keccak 上。

因此，我们决定将优化工作重点放在这个瓶颈上。我们工作了几个星期，创建了一个专门用于 keccak 的优化电路，然后将其嵌入到我们的虚拟机中。通过此更改，它不再慢 10 倍；现在仅比定制电路慢大约三倍。

我们的工作继续进行，我们找到了另一个热点，modexp。我们也为此添加了一个电路。我们重复这个过程，经过几次优化后，我们的虚拟机不再慢 10 倍。现在它具有竞争力，并且开销不像以前那样重要了。

如果我们在一年而不是几年内交付这台机器，我们就赢了。

实际上，这正是我们所看到的。像用于表示 EVM 的定制电路，在纸面上看起来更好，但实际上它们正在被 zk-VM 替代。

它们更容易构建，更容易优化，并且由于团队可以更快地迭代，因此最终它们运行得也更快。

过去感觉慢得难以忍受的东西现在已经足够快，可以实时证明以太坊的执行。这种变化并非来自一个聪明的技巧，而是来自对简单且通用设计的稳定优化。

一个拥有简单设计的小而专注的团队胜过大多数专业项目。

隐藏的成本：Trace 生成

到目前为止，我主要关注证明性能。但故事不仅仅有证明性能。当你实际构建一个 zkVM 时，证明只是一个更大的管道中的一部分，可能看起来像：

• 生成你想证明的 trace，或 witness

• 将该 trace 分成几部分并证明每个部分

• 将已证明的部分连接在一起

当然，这是简化的，但关键是，在你可以证明任何东西之前，你首先必须生成 trace。

生成 trace 基本上是逐步运行计算，并编写一个包含足够信息的日志，以验证每个步骤的状态。对于像 EVM 这样的东西，这仅仅意味着执行区块并保存一些额外的数据。

事实证明，这部分非常重要。一旦证明者本身得到很好的优化，trace 生成通常会成为瓶颈。主要原因是 trace 生成本质上是顺序的。你必须按顺序执行每个指令才能知道下一个状态是什么。

这个瓶颈解释了为什么许多从事 zkVM 工作的最强大的团队现在都在投入大量精力来优化 trace 生成。但是，只有当 trace 始终具有相同的结构时，这种努力才是直接的。如果你为一个系统构建了一个完美的电路，你也需要构建一个同样优化的 trace 生成器来匹配它。

这就是为什么整个管道很重要，而不仅仅是证明者本身。

指令集问题

那么，拥有自定义指令集的机器怎么样？我们是否可以构建一个专门为零知识证明优化的虚拟机？这是否会给我们带来两全其美？

这种方法提出了与电路与虚拟机辩论不同的一组权衡。

虽然 zkEVM 电路通常比 RISC-V zkVM 更复杂，但自定义的 zk 友好指令集可能比 RISC-V 更简单、更快。挑战在于，我们需要一些方法让人们实际在我们的虚拟机中构建应用程序。

今天，这通常意味着以下两件事之一：

• 使用自定义编译器创建自定义语言

• 为 Rust 等语言创建自定义编译器，以适应特殊的指令集

还有第三条技术上可行但今天没有被广泛追求的路径。你可以首先以标准 RISC-V 为目标，然后将其转换为你自己的更高效的指令集，而不是在标准 RISC-V 或完全自定义的解决方案之间做出选择。

这类似于许多现代 CPU 的工作方式。我们看到的汇编更像是一个 API 而不是真正的指令。CPU 将这些指令转换为一个更简单的内部集合，然后实际执行。以同样的方式，我们可以有一个转换器，将 RISC-V 转换为自定义指令。

这种设计中的难点在于转换步骤。要么它必须自动找出如何利用你的专用虚拟机的本地功能，要么开发人员需要某种方式通过高级语言传递这些提示。

除了工具的复杂性之外，我们还必须权衡性能优势。一些估计表明，自定义的 zk 友好虚拟机可能比 RISC-V 快三到六倍。

不过，可能需要更多的测量来帮助指导决策。再次，工程复杂性和潜在好处之间的平衡将是决定每种替代方案的关键考虑因素之一。

为什么多样性很重要

到目前为止，我们主要讨论了工程复杂性和效率。但这些并不是唯一重要的事情。一旦这些系统能够保护真正的价值，我们还必须考虑安全性。

系统越简单，发现和修复问题的难度就越小。活动部件越多，攻击面就越大。

如果我们要使用这些可验证的机器来保护以太坊和我们的金融系统，那么代码需要是人们可以实际检查的东西。但即便如此，错误仍然会发生。

这就是为什么多样性是关键。即使一种设计被证明是最快的，如果不存在单一故障点，以太坊和更广泛的生态系统也会更安全。我们不希望出现编译器或共享库中的一个错误就足以破坏一切的未来。

作为一个社区，我们需要多个团队构建不同的设计。架构、语言和实现的多样性是保持系统弹性的关键。

拥有多个有竞争力的选择才是真正安全的关键。

• 原文链接： x.com/alignedlayer/statu...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～