星球日报 | 美联储维持利
V神新文：以太坊内置ZK后，Layer2驶向何方？
2023.12.14
出品 | Odaily星球日报
编译 | Loopy Lu
今日，Vitalik Buterin 在以太坊社区发布了一篇名为《内置 ZK-EVM 可能是什么样子的？》的新文章。这篇文章探讨了以太坊在未来的网络升级中将如何内置自己的 ZK-EVM。
众所周知，在以太坊开发缓慢的背景下，目前几乎主流 Layer 2 都已经拥有了 ZK-EVM，而当以太坊主网封装了自己的 ZK-EVM 之后，主网和 Layer 2 又是否会产生角色定位的冲突呢？Layer 1 和 Layer 2 又该如何有效的分工合作呢？
在本文中，Vitalik Buterin 强调了兼容性、数据可用性和可审计性的重要性，并探索了实现高效和有状态证明者的可能性。此外，文章还探讨了为提高效率实现有状态证明者的可能性，并讨论了 Layer 2 项目在提供快速预确认和 MEV 缓解策略方面的作用。这篇文章反映了在保持以太坊网络灵活性的同时，通过 ZK-EVMs 推进其发展的平衡。
Odaily星球日报对原文进行了编译，文章全文如下：
optimistic rollups 和 ZK rollup 作为以太坊之上的 Layer-2 EVM 协议，都依赖于 EVM 验证。然而，这要求他们信任一个庞大的代码库，如果这个代码库中存在 bug，那么这些虚拟机就有被黑客攻击的风险。这也意味着，ZK-EVM 即便是希望与L1 EVM 保持完全等效，也需要某种形式的治理，以此来将L1 EVM 的改变复制到它们自己的 EVM 实现中。
这种并不是一种理想的情况。因为这些项目正在把以太坊协议中已经存在的功能复制到自身中——以太坊治理已经负责进行升级和修复 bug，ZK-EVM 基本上做的工作只是验证 Layer 1 以太坊区块。在未来几年中，我们预计轻客户端将变得越来越强大，很快就能够使用 ZK-SNARKs 来完全验证L1 EVM 执行。到那时，以太坊网络将实际上拥有一个封装的 ZK-EVM。因此，问题就出现了：为什么不让这个 ZK-EVM 对于 rollups 也是原生可用的呢？
这篇文章将描述“封装 ZK-EVM”的几个版本，分析其权衡、设计挑战以及不走某些特定方向的原因。实现一个协议功能的好处应该与让生态系统处理事务并保持基础协议简单的好处相比较。
我们希望从封装的 ZK-EVM 中获得哪些关键特性？
我们希望从封装 ZK-EVM 中得到哪些关键属性？
基本功能：验证以太坊区块。该协议功能（目前还未确定是操作码、预编译还是其他机制）应该至少能接受预状态根、一个区块和后状态根作为输入，并验证后状态根实际上是在预状态根之上执行该区块的结果。 与以太坊的多客户端兼容。这意味着我们希望避免内置单一证明系统，而是允许不同的客户端使用不同的证明系统。
这也意味着几点：
数据可用性要求：对于任何使用封装 ZK-EVM 证明的 EVM 执行，我们希望保证底层数据是可用的，这样使用不同证明系统的证明者就可以重新证明执行，依赖该证明系统的客户端就可以验证这些新生成的证明。
证明位于 EVM 和区块数据结构之外：ZK-EVM 功能不会真的将 SNARK 作为 EVM 内部的输入，因为不同的客户端会期望不同类型的 SNARK。相反，它可能类似于 blob 验证：交易可以包括需要证明的（预状态、区块体、后状态）声明，操作码或预编译可以访问这些声明的内容，客户端共识规则会分别检查数据可用性和区块中所做声明的证明。
可审计性：如果任何执行被证明，我们希望底层数据是可用的，这样如果出现任何问题，用户和开发者都可以检查它。实际上，这增加了一个更多原因，为什么数据可用性要求很重要。
可升级性：如果发现某个特定 ZK-EVM 方案存在 bug，我们希望能够迅速修复它。这意味着不需要硬分叉就能修复问题。这又增加了一个原因，说明在 EVM 和块数据结构之外的证明很重要。
支持“近似 EVM”：L2s的一个吸引力在于能够在执行层进行创新，并对 EVM 进行扩展。如果某个L2的 VM 只是稍微有点不同于 EVM，那么如果L2可以对与 EVM 相同的部分使用原生的协议内 ZK-EVM，并且只依赖自己的代码来处理不同的部分，这将是很好的。这可以通过设计 ZK-EVM 功能来实现，使得调用者可以指定一个位域或操作码或地址列表，这些将由外部提供的表格而不是 EVM 本身来处理。我们还可以使 gas 成本在一定程度上可定制。
