摘要：昨天，Vitalik在他的博客中更新了一篇名为《Whatmightan“enshrinedZK-EVM”looklike?因此，我们可以直接快速的从文章标题了解Vitalik这篇文章的意图：探讨将零知识证明（ZK）版本的以太坊虚拟机（EVM）作为核心或官方部分，整合到以太坊协议中的可能性。...
昨天，Vitalik 在他的博客中更新了一篇名为《What might an “enshrined ZK-EVM” look like?》的文章，系统性的阐述了以太坊集成ZK-EVM的可行性、方法和预期效果等内容。
EVM的未来发展往往关联到多种与基础设施相关的叙事或方向变化，值得我们进行阅读和研究。
但考虑到该文章涉及太多技术细节，中文媒体和社区中大部分的材料都只是对该文章进行简单的翻译，很容易让人摸不清文章的来龙去脉和观点。
因此，深潮对该文章进行了解读，试图以更通俗的方式来还原Vitalik的写作思路和观点，为各位读者提供参考。
标题的单词暗示：将ZK-EVM奉为正统
如果仅看直接翻译的文章，你很看get到英文语境下的某种暗示或自然表达。
在Vitalik这篇文章的标题中，出现了一个不怎么常用的英文单词 --- ”enshrined“。
简单查阅GPT或英文词典你就可以看到：
"Enshrined" 这个词在英文中原本的意思是“奉为神圣”，常用于形容将某物或某人的地位、重要性或价值提升到极高的水平，好比将其放置在一个神圣或受保护的位置上。
在法律或宗教文本中，"enshrine" 通常指的是将某些原则、权利或信仰正式地并且以尊重的方式记录或保留下来。
而在技术或软件领域，"enshrined" 通常意味着将某项技术、功能或原则正式地并且重要地集成到系统、框架或协议中。这通常意味着该技术或功能被认为是基础性的、核心的，或者至关重要的，因此被正式地并且持久地纳入系统。
因此，我们可以直接快速的从文章标题了解Vitalik这篇文章的意图：
探讨将零知识证明（ZK）版本的以太坊虚拟机（EVM）作为核心或官方部分，整合到以太坊协议中的可能性。
这也就是说，以太坊或许之后不只是将ZK-EVM作为一个附加组件来看待。
ZK-EVM的过去：L2形式的“外挂组件”，非原生
对不熟悉以太坊EVM和相关L2解决方案的读者来说，Vitalik 探讨将ZK-EVM作为以太坊主网的正式部分，很容易让人想到另一个问题：
在以前，ZK-EVM和以太坊是什么关系？以前ZK-EVM不是以太坊的“正式部分”吗？
让我们做一个非常轻度且快速的科普：
- 以太坊虚拟机（EVM）：以太坊网络的核心，负责执行智能合约代码。所有在以太坊上运行的智能合约都是通过EVM来执行的。
- 零知识证明（ZK）：一种加密技术，允许一方（证明者）向另一方（验证者）证明某个陈述是真实的，而无需透露除了这个陈述之外的任何信息。这种技术在加密货币和区块链领域中被用来增强交易的隐私性和安全性。
- ZK-EVM的作用：结合了EVM的功能和零知识证明的隐私保护特性。它允许在保持交易数据私密的同时，验证交易的有效性。这意味着可以在不公开交易具体内容的情况下，证明交易是符合智能合约和区块链规则的。
- ZK-EVM与以太坊主网的关系：ZK-EVM可以作为一种解决方案，它在保持以太坊虚拟机兼容性的同时，引入了零知识证明，使得执行的交易可以保持私密。在早期，ZK-EVM更多的是作为第二层（Layer 2）解决方案出现，即它建立在以太坊主网之上，为主网提供额外的隐私保护和扩展性功能。
因此，现在的ZK-EVM大多以L2的形式出现，而不是直接在以太坊L1的设计中存在。通俗来说，是外挂组件。
比较知名的ZK-EVM解决方案大家都知道了，例如Starknet、zkSync、Polygon Hermez以及Scroll等。
有了以上背景知识储备后，再去理解Vitalik的博客就变得容易了很多。
为什么要在以太坊里内置原生ZK-EVM？
顺着上文逻辑，你可能会问：ZK-EVM的L2方案做的好好的，为什么Vitalik试图讨论将ZK-EVM直接纳入以太坊的核心设计中？
Vitalik非常言简意赅的给出了回答：
- 对大型代码库的依赖:当前的Layer 2解决方案，如Optimistic Rollups和ZK Rollups，依赖于EVM验证。这意味着它们必须信任一个庞大的代码库。如果代码库中存在漏洞，这些虚拟机（VMs）可能面临被黑客攻击的风险。
- 治理问题: 即使是希望与L1 EVM保持完全等效的ZK-EVMs，也需要某种形式的治理机制，以便将L1 EVM中的更改复制到它们自己的EVM实现中。这增加了复杂性和潜在的不一致性风险。
- 功能重复:Layer 2项目复制了以太坊协议中已经存在的功能。以太坊治理已经负责进行升级和修复漏洞。ZK-EVM在本质上执行的工作与验证L1以太坊区块的工作相同。
- 未来的轻客户端发展: 随着轻客户端变得越来越强大，并很快能够使用ZK-SNARKs来完全验证L1 EVM执行，以太坊网络将有效地拥有一个内置的ZK-EVM。这提出了一个问题：为什么不为rollups也提供这种原生的ZK-EVM呢？
通过探讨这些问题，Vitalik阐明了将ZK-EVM纳入以太坊核心设计的动机--- 主要是为了解决依赖外部代码库的风险、简化治理过程、减少功能重复，并利用以太坊网络本身具备的能力。
内置ZK-EVM，应该长什么样？
那么以太坊如果要内置ZK-EVM，应该具备怎样的功能和特性？Vitalik进一步给出了思路：
- 基本功能：ZK-EVM的核心功能是验证以太坊区块。这意味着它应该能够接受一个前状态根（pre-state root）、一个区块和一个后状态根（post-state root）作为输入，并验证后状态根确实是执行该区块后的结果。
- 与以太坊多客户端哲学的兼容性：ZK-EVM应该避免只采用单一的证明系统，而是允许不同的客户端使用不同的证明系统。这涉及到数据可用性的要求，以及证明应该独立于EVM和区块数据结构之外的考虑。
- 审计性：如果任何执行被证明，那么底层数据应该是可用的，以便在出现问题时用户和开发者可以检查。
- 可升级性：如果发现特定的ZK-EVM方案存在漏洞，应该能够快速修复，而不需要进行硬分叉。
- 支持几乎相同的EVM（almost-EVMs）：ZK-EVM应该支持在执行层面的创新和对EVM的扩展。如果一个给定的L2的VM只是稍微不同于EVM，那么它仍然可以使用原生的协议内ZK-EVM来处理与EVM相同的部分，并仅依赖于它们自己的代码来处理不同的部分。
注意，这个almost-EVMs可能有读者不了解，实际上Vitalik之前也提到过类似观点，他认为有些ZK-EVM解决方案在执行时不应严格要求和EVM一模一样，而是可以变得“有些接近”于原始的EVM。
在Vitalik提出的ZK-EVM框架中，对almost-EVMs的支持意味着ZK-EVM可以更灵活地适应各种不同的需求和场景。这使得ZK-EVM不仅能够服务于完全遵循标准EVM规范的应用，也能够支持那些需要或希望进行轻微调整的系统。
内置ZK-EVM，在不同以太坊客户端上怎么跑？
顺着思路继续看Vitalik的原文，在这里很容易犯迷糊：怎么又突然讲到客户端的事情了？
回顾上文，你会发现Vitalik的阐述逻辑非常清晰：
“我想让ZK-EVM变成以太坊内置组件 --- 为什么要这么干？---这么干应该满足哪些功能？”
因此，下一个讨论点实际上变成了：这么干，具体落地时在不同的客户端上怎么运行？
Vitalik给出了2个方向，即在开放的多客户端系统运行，或者在封闭的多客户端系统运行。
- 开放式系统：更符合以太坊的去中心化和创新精神，允许社区根据需要开发和采用新的证明技术。
- 封闭式系统：可能更易于管理和维护，但可能限制了系统的长期适应性和创新潜力。
此外，后文中Vitalik也谈到了做ZK-EVM更看重速度的重要性，如果ZK-EVM能够快速生成证明，它将更加适合集成到以太坊主协议中，因为它能够更好地满足网络的性能需求和用户的体验期望。
然而，实现这一目标需要克服重大的技术和工程挑战。Vitalik在这部分内容中明确了这些挑战，并提出了可能的解决方案和方法。
ZK-EVM具体在以太坊上怎么实现？
Vitalik也给出了ZK-EVM可能的实现方式。
他提出了一种新的交易类型——ZK-EVM声明交易（ZKEVMClaimTransaction），以及如何在以太坊网络中处理和验证这些交易。
由于这部分过于技术，建议没有基础的读者可以直接跳过技术细节。我们直接来看他的设计思路和大意：
- 引入的容器类型，用于在网络中传递ZK-EVM相关的声明。
- 在共识层，提出了一条新规则，即只有当客户端看到每个声明的有效证明后，才接受区块。
- 用户在ZK-EVM证明中，可以替换他们的执行客户端，但执行客户端仍然被用于生成证明和构建区块，以及节点存储和索引数据。
- 不同的ZK-EVM实现可能有不同的证明方法，但他们都可以互相验证和接受证明。
此外，Vitalik 在这部分内容中讨论了对“almost-EVMs”（几乎等同于以太坊虚拟机的系统）的支持，这是ZK-EVM功能的一个期望目标。
这些系统内置了一些额外的特性，可能包括新的预编译合约、操作码、合约编写选项（比如可以选择在标准EVM或完全不同的虚拟机中编写，例如Arbitrum Stylus），甚至是支持同步交叉通信的多个并行EVM。
同时，Vitalik Buterin 讨论了ZK-EVM内如何支持带状态（stateful）的验证者，以及为什么这样做是有益的：
为什么支持状态验证者？
- 数据效率：状态验证者可以提高数据的压缩效率。一个完全无状态的系统需要所有数据在每次交易时都可用，这可能导致数据重复和浪费。状态验证者可以存储之前的状态信息，减少必须传输和处理的数据量。
- 减少数据冗余：如果某个数据片段已经由前一个区块或交易提供，那么在随后的证明中就没有必要再次提供它，因为它已经是“已知”的。
- 系统性能：带状态的系统允许更有效的计算和验证，因为它们可以利用已知的信息，而不是每次都从零开始。
至于如何支持，原文中涉及太多的技术细节，在此难以做深入解读，我们只需要明白：
"支持状态验证者" 意味着在ZK-EVM中引入一个机制，使得系统能够记住和利用之前的状态，而不是在每次操作时都完全无状态。这样可以提高系统的整体性能，减少所需的数据传输，同时允许更高效的计算。这是对ZK-EVM设计的一个扩展，目的是提高其在真实世界应用中的可行性和效率。
内置了ZK-EVM，其他做类似事情的L2怎么办？
在文章的最后，Vitalik稍微跳出了严肃的技术讨论，转而思考另外一个问题，即如果ZK-EVM变成了以太坊L1内置的功能，其他那些做ZK的L2，它们的角色会有什么变化？
在Vitalik的设想中，如果真要这么做，L2后续更多的可能要承担”辅助位“的角色，在以下几个方面发挥补充作用：
- 快速预确认：单时隙最终性（single-slot finality）可能会使Layer 1的处理速度变慢，而Layer 2项目可以提供快速的预确认服务，这些服务由Layer 2自身的安全机制支持，延迟时间远低于一个时隙。这些服务将继续是Layer 2独有的职责。
- 最小可提取价值（MEV）缓解策略：这可能包括加密的内存池、基于声誉的排序器选择和Layer 1不愿实施的其他功能。Layer 2可以实施这些策略来减少MEV对用户交易的影响。
- 对EVM的扩展：Layer 2项目可以引入对EVM的重大扩展，为其用户提供显著的价值。这包括支持“几乎是EVM”（almost-EVMs）的版本，或完全不同的方法，例如支持WASM的Arbitrum Stylus和对SNARK友好的Cairo语言。
- 面向用户和开发者的便利性：Layer 2团队通过吸引用户和项目加入他们的生态系统并让他们感到受欢迎来完成大量工作；他们通过捕获网络内的MEV和拥堵费用来获得报酬。即使ZK-EVM被集成到以太坊协议中，这种模式也将继续存在。
注意，目前这些都只是Vitalik个人的想法，还没有正式付诸实践。
但从这篇博客来看，Vitalik对以太坊自己做ZK-EVM的初衷、方法、功能和额外影响等都考虑的非常清楚，显然也不是临时起意。
从EVM，到性能更好的EVM，再到兼顾ZK的EVM，Vitalik作为以太坊的设计者，在让他的作品以递进的方式变得更加完善；
当然，在这个过程中他从未排斥过其他的L2解决方案的思路，但似乎也从未放弃以原生的方式将以太坊变得更好。
至于这个ZK-EVM的原生思路是否真的会通过，还要等到这些博客中的思路变成具体的提案才能见分分晓。
不过可以确定地是，当技术革新将至，整个生态也必将风起云涌。
