Vitalik：将ZK-EVM封装到以太坊主网会是什么样

原文标题：What might an “enshrined ZK-EVM” look like

作者：Vitalik，以太坊创始人；来源：ethereum官网；翻译：0xjs@金色财经

以太坊之上的 2 层 EVM 协议（包括乐观rollup和 ZK rollup）依赖于 EVM 验证。然而，这要求他们信任大型代码库，如果该代码库中存在错误，这些虚拟机就有被黑客攻击的风险。此外，这意味着即使 ZK-EVM 想要与 L1 EVM 保持完全相同，也需要某种形式的治理，将对 L1 EVM 的更改复制到自己的 EVM 实现中。

这种情况不是最理想的，因为这些项目正在复制以太坊协议中已经存在的功能，并且以太坊治理已经负责进行升级和修复错误：ZK-EVM 基本上完成与验证 1 层以太坊区块相同的工作！此外，在接下来的几年里，我们预计轻客户端会变得越来越强大，并且很快就会达到使用 ZK-SNARK 来完全验证 L1 EVM 执行的程度。届时，以太坊网络将有效地拥有内置的ZK-EVM。那么问题来了：为什么不让ZK-EVM原生地用于rollup呢？

这篇文章将描述可以实现的“封装ZK-EVM（enshrined ZK-EVM）”的几个版本，并讨论权衡和设计挑战，以及不朝特定方向发展的原因。应权衡实现协议功能的好处与将事情交给生态系统并保持基本协议简单的好处。

我们希望从ZK-EVM中获得哪些关键属性？

基本功能：验证以太坊区块。协议功能（到目前为止，无论是操作码、预编译还是其他机制，都处于开放状态）应该（至少）接受前状态根、区块和后状态根作为输入，并验证后状态根实际上是在前状态根之上执行区块的结果。

与以太坊的多客户端理念兼容。这意味着我们希望避免采用单一的证明系统，而是允许不同的客户端使用不同的证明系统。这又暗示了几点：

       数据可用性要求：对于使用 ZK-EVM 进行验证的任何 EVM 执行，我们希望保证底层数据可用，以便使用不同证明系统的证明者可以重新证明执行，并且客户端依赖于该证明系统可以验证那些新生成的证明。

      证明存在于 EVM 和区块数据结构之外：ZK-EVM 功能实际上不会将 SNARK 作为 EVM 输入，因为不同的客户端会期望不同类型的 SNARK。相反，它的工作方式可能类似于 blob 验证：交易可能包括需要证明的（前状态、区块体、后状态）语句，操作码或预编译可以访问这些语句的内容，并且客户端共识规则将分别检查数据可用性以及区块中提出的每个声明的证据是否存在。

可审计性。如果任何执行得到验证，我们希望底层数据可用，以便如果出现任何问题，用户和开发人员可以检查它。实际上，这又增加了数据可用性要求如此重要的一个原因。

可升级性。如果发现某个特定的 ZK-EVM 方案存在错误，我们希望能够快速修复它。这意味着不需要硬分叉来修复。这又增加了 EVM 和区块数据结构之外的证明如此重要的另一个原因。

支持almost-EVM（准EVM）。L2 的部分吸引力在于能够在执行层进行创新，并对 EVM 进行扩展。如果给定的 L2 的 VM 与 EVM 只有一点点不同，那么如果 L2 仍然可以使用原生协议内 ZK-EVM 来处理与 EVM 相同的部分，并且只依赖自己那部分不同的代码，那就太好了。这可以通过设计 ZK-EVM 功能来实现，允许调用者指定由外部提供的表而不是 EVM 本身处理的位字段或操作码列表或地址。我们还可以在一定程度上允许Gas成本进行定制。

“开放”vs“封闭”多客户端系统

“多客户端理念”可能是此列表中最固执己见的要求。可以选择放弃它并专注于一种 ZK-SNARK 方案，这将简化设计，但代价是成为以太坊更大的“哲学支点”（因为这实际上是放弃以太坊的长期坚持的多客户理念）并以引入更大的风险为代价。在长远的未来，如果形式化验证技术变得更好，走这条路可能会更好，但目前风险似乎太大了。

另一种选择是封闭的多客户端系统，其中协议内有一组固定的证明系统。例如，我们可能决定使用三个 ZK-EVM：PSE ZK-EVM、Polygon ZK-EVM和Kakarot。一个区块需要提供这三个中两个的证明才有效。这比单一证明系统更好，但它使系统的适应性较差，因为用户必须为现有的每个证明系统维护验证者，合并新证明系统将不可避免地存在政治治理过程等。

这激发了我对开放式多客户端系统的偏好，其中证据被放置在“区块之外”并由客户端单独验证。个人用户可以使用他们想要验证区块的任何客户端，只要至少有一个证明者为该证明系统创建证明，他们就能够这样做。证明系统将通过说服用户运行它们来获得影响力，而不是通过说服协议治理流程。然而，正如我们将看到的，这种方法确实具有更高的复杂性成本。

我们希望ZK-EVM实现具有哪些关键属性？