原作：Vitalik Buterin

碳排放：

     TL;DR

• 多客户端理念（multi-client philosophy）是一种未被充分讨论但非常重要的、以太坊维护其安全性和去中心化的方式；

• ZK-EVM的兴起如何影响以太坊链验证方式是一个未被充分讨论但非常重要的、并即将要到来的重大事项；

• 多客户端的理念由架构去中心化的技术效益和政治去中心化的社会效益两者驱动的，并为两者服务；

• 未来 ZK-EVM 将通过基于SNARK证明的L1验证方式进入L1；

• 开放的客户端 ZK-EVM 生态系统是理想的发展方向。

多客户端理念是一种未被充分讨论但非常重要的、以太坊维护其安全性和去中心化的方式。以太坊有意没有一个默认的“参考客户端”，相反，仅有一个协作管理的规范（目前的共识规范由可读但运行速度较慢的Python编写）并且有多个团队实现这一规范（也称为“客户端”），这些客户端是用户目前实际建立并运行以太坊节点的方式。

图：以太坊客户端类型及部署比例

每个以太坊节点运行一个共识客户端和一个执行客户端。截至今天，没有共识或执行客户端占网络的 2/3 以上。如果在其类别中份额低于 1/3 的客户端出现错误，则网络将照常运行。如果在其类别中占有 1/3 到 2/3 份额的客户端（例如 Prysm、Lighthouse 或 Geth）出现错误，链将继续添加区块，但它会停止敲定区块（finalizing block），从而为开发人员提供时间进行干预。

ZK-EVM的兴起如何影响以太坊链验证方式是一个未被充分讨论但非常重要的、并即将要到来的重大事项。基于SNARK证明的EVM执行已经开发多年，该技术正被基于ZK-rollups的Layer2协议积极使用。其中一些 ZK-Rollup今天在主网上很活跃，并且很快就会有更多。但从长远来看，ZK-EVM 不期望仅仅被用于Rollup，我们也想用其来验证Layer1的执行情况（另请参阅：Verge）。

这时，ZK-EVM 实际上成为第三种类型的以太坊客户端，对网络安全的重要性与执行客户端和共识客户端一样重要。那么ZK-EVM 将如何与多客户端理念交互？困难的部分之一已经完成：以太坊已经有多个正在积极开发的 ZK-EVM。但其他困难的部分仍然存在：我们如何为zk创建一个“多客户端”生态系统来验证以太坊区块的正确性？这个问题带来了一些有趣的技术挑战，但眼前的问题是这样的权衡是否值得。

以太坊的多客户端理念是一种去中心化，就像一般的去中心化一样，人们可以关注架构去中心化的技术效益，也可以关注政治去中心化的社会效益。最终，多客户端的理念是由两者驱动的，并为两者服务。

技术去中心化的主要好处很简单：它降低了一个软件中的一个错误导致整个网络灾难性崩溃的风险。这种风险在2010 年的比特币溢出漏洞事件中真实发生过。当时，比特币客户端代码没有检查交易输出的总和是否溢出（通过总和超过最大整数2^64−1回绕到零)，所以有人利用这一漏洞做了一笔交易，给了自己数十亿比特币。该漏洞在数小时内被发现，并迅速在网络中完成了修复和部署工作，但如果当时有一个成熟的生态系统，这些比特币就会被交易所、跨链桥和其他途径所接受，攻击者可能早已卷巨款而逃。但如果有五个不同的比特币客户端，他们不太可能都有相同的错误，因此一旦发生这类事故，整个网络会立即出现共识分歧，而分歧中有错误的一方可能会输掉。

使用多客户端方法来最小化灾难性错误的风险仍然需要权衡：这种情况下用户会遇到共识失效（consensus failure）的bug。比如，如果您有两个客户端，则客户端对某些协议的规则有细微编码差异的风险，虽然两种方式都是符合规则的，但分歧会导致区块链硬分叉。在以太坊的历史上发生过一次（还有其他更小的分叉，其中运行旧版本代码网络的一部分被分叉）这类严重的分叉。单一客户端机制的捍卫者指出，共识失效是不采用多客户端实现的原因：如果只有一个客户端，则该客户端必然会为自己辩护。他们关于客户数量如何转化为风险的模型可能如下所示：

图：共识失效风险与客户端类型数的关系

但Vitalik本人并不认同单一客户端机制，首先 (i) 2010 年比特币的灾难性错误非常重要， (ii)并且实际上永远不会只有一个客户端。后一点在2013 年的比特币分叉中表现得最为明显：由于两个不同版本的比特币客户端之间存在分歧而发生了分叉，其中一个版本在单个块中可以修改的对象数量上有一个偶然的、未被记录的限制。因此，理论上一个客户端在事实上通常是两个客户端，理论上五个客户端事实上可能是六个或七个客户端 - 所以我们应该走在风险曲线的右侧，并且至少有几个不同的客户端。

垄断客户端开发人员处于拥有大量政治权力的位置。如果客户端开发人员提出更改，而用户不同意，理论上他们可以拒绝下载更新版本，或者在没有其的情况下创建一个分叉链，但实际上用户通常很难做到这一点。如果不当的协议更改与必要的安全更新捆绑在一起怎么办？如果主要团队威胁说如果他们不按他们的方式行事就退出怎么办？或者，如果垄断客户端的团队最终成为唯一拥有最强大协议专业知识的群体，而使生态系统中其他人处于不利地位，无法有效判断客户端团队提出的技术方案，从而使客户端团队有很大的空间来推动其特定的目标和价值观，而这与更广泛的社区并不匹配。

在2013-2014 比特币 OP_RETURN 战争的背景下，一些参与者公开支持歧视区块链的一些特别用途。这激发了以太坊对协议政治的担忧，也是以太坊早期采用多客户端理念的重要促成因素，这旨在让小群体更难做出此类决定。以太坊生态系统特有的担忧——即避免权力集中在以太坊基金会内部——为这一方向提供了进一步的支持。2018 年，基金会决定有意不实施以太坊 PoS 协议（即现在所谓的“共识客户端”），而将该任务完全留给外部团队开发。

如今，ZK-EVM 正在积极地被用于Rollup。这通过允许昂贵的 EVM 执行仅在链下发生几次来增加扩展性，而其他人只需验证链上发布的SNARKs即可证明 EVM 执行结果的正确性。它还允许一些数据（特别是签名）不包含在链上，从而节省 gas 成本。这给了我们很多可扩展性的好处，可扩展计算与 ZK-EVM 和可扩展数据与数据可用性采样的结合可以让扩展走得更远。

然而，今天的以太坊网络也有一个不同的问题，一个再多的 L2 扩容也无法自行解决的问题：L1 难以验证，以至于没有多少用户真正运行自己的节点。相反，大多数用户只是信任第三方工具提供商。Helios和Succinct等轻客户端正在采取措施解决该问题，但轻客户端远非全验证节点：轻客户端仅验证称为同步委员会（sync committee）的随机验证器子集的签名，而不会验证该链是否实际上在遵循协议规则。为了让我们进入一个用户可以实际验证链是否遵守规则的世界，我们必须做一些不同的事情。

随着时间的推移，我们可以将L1每个区块的 gas 目标从 1500 万减少到 100 万，足以让一个区块包含一个 SNARK 和一些存款和取款操作，但其他的不多，从而使几乎所有的用户活动强制移动到L2协议中。这样的设计仍然可以支持在每个块中提交许多Rollup：我们可以使用由定制构建器（customized builders）运行的链下聚合协议来从多个L2协议收集多个SNARK证明，并将它们组合成单个 SNARK证明。这时，L1的唯一功能是成为L2协议的清算中心，验证它们的ZKP并偶尔促成它们之间的大额资金转移。

图：选项一的可能技术解决方案图解

这种方法可能有效，但它有几个重要的弱点：

1. 缺乏向后兼容性，因为许多现有的基于L1 的应用程序在经济上变得不可行。高达数百或数千美元的用户资金可能会陷入困境，因为费用变高后甚至会超过清空这些账户的成本。这可以通过让用户签署消息以选择协议内大规模迁移到他们选择的 L2 来解决（参见此处的一些早期实施想法）但这增加了过渡的复杂性，而且要让它的成本真正足够低，无论如何都需要在L1进行某种SNARK。当涉及到SELFDESTRUCT这样的操作码时，Vitalik本人通常支持打破向后兼容性，但在这种情况下，折衷似乎不那么有利。

2. 可能仍然无法使验证成本足够低。理想情况下，以太坊协议应该不仅在笔记本电脑上而且在手机、浏览器扩展程序甚至其他链中都应该易于验证。第一次同步链，或者长时间离线后同步，应该也很容易。笔记本电脑节点可以在大约 20 毫秒内验证 100 万gas，但即使这样也意味着在离线一天后需要 54 秒进行同步（假设单slot敲定将slot时间增加到 32 秒），而对于手机或浏览器扩展，则每个块需要几百毫秒，并且会造成不可忽视的电池损耗。这些数字是可控的，但仍不理想。

3. 即使在 L2 优先的生态系统中，L1 至少在某种程度上可以负担得起也是有好处的。如果用户在注意到新的状态数据不再可用时可以提取资金，Validiums可以从更强大的安全模型中受益。如果的L2跨链transfer操作的最小规模进一步变小在经济上可行，套利（尤其是小币种套利）将变得更加有效。

因此，尝试找到一种使用 ZK-SNARKs 来验证L1的方法似乎更合理。

第一类（完全等效于以太坊）ZK-EVM可用于验证L1的 EVM 执行。我们可以编写更多的 SNARK 代码来验证区块的共识方面。这将是一个具有挑战性的工程问题：今天，ZK-EVM 需要几分钟到几小时来验证以太坊区块，并且实时生成zk证明需要（i）改进以太坊本身以删除对 SNARK 不友好的组件，（ii）或者通过专门的硬件获得巨大的效率提升 ，(iii)或者通过更多的并行化来改进架构。然而，没有根本的技术原因去阻止三者的实现——所以Vitalik本人希望即使需要很多年，它也最终会完成。

这是ZKEVM与多客户端交集的地方：如果我们使用 ZK-EVM 来验证L1，要使用哪个 ZK-EVM？

1. 单一的客户端 ZK-EVM 机制：放弃多客户端范式，并选择我们用来验证区块的单一 ZK-EVM。

2. 封闭的多客户端 ZK-EVM 生态系统：就一组特定的多个 ZK-EVM 达成一致并达成共识，并有一个共识层协议规则，即一个区块需要来自该集合中超过一半的 ZK-EVM 的证明才能被认为是有效的.

3. 开放的多客户端 ZK-EVM 生态系统：不同的客户端有不同的 ZK-EVM 实现，每个客户端在接受一个块为有效之前等待与自己的实现兼容的证明。

对Vitalik本人来说，（3）似乎是理想的，至少在我们可以形式化证明所有 ZK-EVM 能实现彼此等效并完成技术改进之前，我们可以选择一个最高效的。(1) 会牺牲多客户端范式的好处，并且 (2) 会关闭开发新客户端的可能性并导致更加集中的生态系统。(3) 有挑战，但至少目前这些挑战似乎比其他两个选项的挑战要小。

实施 (3) 不会太难：每个ZK-EVM类型的证明可能都有一个P2P子网络，使用一种ZK-EVM类型证明的客户端将监听相应的子网络并等待直到他们得知验证者认为其证明有效。

(3) 的两个主要挑战可能如下：

1. 延迟挑战：恶意攻击者可能会延迟发布一个块，以及对一个客户端有效的证明。生成对其他客户端有效的证明实际上需要很长时间（即使是 15 秒）。这段时间足够长去创建一个临时分叉链并中断主链的几个slot。

2. 数据效率低下：ZK-SNARKs 的一个好处是可以从块中删除仅与验证相关的数据（有时称为“见证数据（witness data）”）。例如，一旦你验证了一个签名，你就不需要将签名保存在一个块中，你可以只存储一个表示签名有效的bit，并在块中存储一个证明，以确认所有有效签名都存在。但是，如果我们希望能够为一个块生成多种ZK-EVM类型的证明，则需要实际发布原始签名。

延迟挑战可以通过在设计单slot敲定协议时更加谨慎来解决。单slot敲定协议可能需要每个slot进行超过两轮的共识，因此可能需要第一轮包含区块，并且只需要节点在第三轮（或最后一轮）签名之前验证证明。这确保了在发布区块截止时间和预计证明可用时间之间始终有一个重要的时间窗口可用。

数据效率问题必须通过单独的协议来聚合与验证相关的数据来解决。对于签名，我们可以使用ERC-4337 已经支持的BLS聚合。另一类验证相关的数据是用于隐私的ZK-SNARKs，当然这些数据往往有自己的聚合协议。

值得一提的是，基于SNARK证明的L1验证有一个重要的好处：链上 EVM 执行不再需要由每个节点验证，这使得大大增加EVM的执行数量成为可能。这可以通过大幅提高L1 的 gas limit，或通过引入受保护的rollup来完成，或两者兼而有之。

使一个开放的多客户端 ZK-EVM 生态系统运行良好需要大量的工作。但值得庆幸的是，这项工作的大部分正在发生或无论如何都会发生：

• 我们已经有多个强大的ZK-EVM实现。这些实现还不是第一类ZK-EVM（完全等同于以太坊），但其中许多正在积极朝着这个方向发展。

• 在Helios和Succinct等轻客户端上的工作最终可能会变成对以太坊链的 PoS 共识端进行更全面的 SNARK 验证。

• 客户端可能会开始尝试使用 ZK-EVM 来证明自己的以太坊区块执行，特别是当我们有无状态态客户端并且没有技术需要去直接重新执行每个区块来维护状态时。我们可能会从客户端通过重新执行来验证以太坊区块，到大多数客户端通过检查SNARK证明来验证以太坊区块，这将是一个缓慢而渐进的过渡。

• ERC-4337 和 PBS 生态系统可能会很快开始使用 BLS 和证明聚合等聚合技术，以节省 gas 成本，并且目前BLS 聚合的工作已经开始。

有了这些技术，未来看起来非常美好。以太坊区块会比今天更小，任何人都可以在他们的笔记本电脑甚至他们的手机或浏览器扩展程序中运行一个全验证节点，这一切都会发生，同时保留以太坊多客户端理念的优点。

从长远来看，一切皆有可能。也许 AI 会增强形式化验证程度，使其可以轻松证明 ZK-EVM 实现的等效并识别导致它们之间差异的所有错误，这甚至可能是现在就要开始着手开发的项目。如果这种基于形式化验证的协议能够成功，则需要建立不同的机制以确保该协议的政治去中心化持续进行；也许到那时，协议将被视为“完整的”，不可变型规范将更加强大。但即使这是更长远的未来，开放的多客户端 ZK-EVM 生态系统似乎是一个必经之路，无论如何都有可能发生。

从短期来看，这仍然是一段漫长的旅程。ZK-EVM就在这里，但 ZK-EVM 在L1真正可行将需要它们首先改进为第一类ZK-EVM，并使证明产生足够快以使其可以实时发生。有了足够的并行化（这是可行的，但要实现这一点仍然需要做很多工作），共识变化（如提高 KECCAK、SHA256 和其他哈希函数预编译的 gas 成本）也将是以太坊蓝图的重要组成部分。也就是说，过渡的第一步可能比我们预期的要早：一旦我们切换到Verkle 树和无状态客户端，客户端就可以开始逐渐使用 ZK-EVM，并且可以自行过渡到“开放的客户端 ZK-EVM 生态系统”。

原作：Vitalik Buterin

碳排放：

     TL;DR

• 多客户端理念（multi-client philosophy）是一种未被充分讨论但非常重要的、以太坊维护其安全性和去中心化的方式；

• ZK-EVM的兴起如何影响以太坊链验证方式是一个未被充分讨论但非常重要的、并即将要到来的重大事项；

• 多客户端的理念由架构去中心化的技术效益和政治去中心化的社会效益两者驱动的，并为两者服务；

• 未来 ZK-EVM 将通过基于SNARK证明的L1验证方式进入L1；

• 开放的客户端 ZK-EVM 生态系统是理想的发展方向。

多客户端理念是一种未被充分讨论但非常重要的、以太坊维护其安全性和去中心化的方式。以太坊有意没有一个默认的“参考客户端”，相反，仅有一个协作管理的规范（目前的共识规范由可读但运行速度较慢的Python编写）并且有多个团队实现这一规范（也称为“客户端”），这些客户端是用户目前实际建立并运行以太坊节点的方式。

图：以太坊客户端类型及部署比例

每个以太坊节点运行一个共识客户端和一个执行客户端。截至今天，没有共识或执行客户端占网络的 2/3 以上。如果在其类别中份额低于 1/3 的客户端出现错误，则网络将照常运行。如果在其类别中占有 1/3 到 2/3 份额的客户端（例如 Prysm、Lighthouse 或 Geth）出现错误，链将继续添加区块，但它会停止敲定区块（finalizing block），从而为开发人员提供时间进行干预。

ZK-EVM的兴起如何影响以太坊链验证方式是一个未被充分讨论但非常重要的、并即将要到来的重大事项。基于SNARK证明的EVM执行已经开发多年，该技术正被基于ZK-rollups的Layer2协议积极使用。其中一些 ZK-Rollup今天在主网上很活跃，并且很快就会有更多。但从长远来看，ZK-EVM 不期望仅仅被用于Rollup，我们也想用其来验证Layer1的执行情况（另请参阅：Verge）。

这时，ZK-EVM 实际上成为第三种类型的以太坊客户端，对网络安全的重要性与执行客户端和共识客户端一样重要。那么ZK-EVM 将如何与多客户端理念交互？困难的部分之一已经完成：以太坊已经有多个正在积极开发的 ZK-EVM。但其他困难的部分仍然存在：我们如何为zk创建一个“多客户端”生态系统来验证以太坊区块的正确性？这个问题带来了一些有趣的技术挑战，但眼前的问题是这样的权衡是否值得。

以太坊的多客户端理念是一种去中心化，就像一般的去中心化一样，人们可以关注架构去中心化的技术效益，也可以关注政治去中心化的社会效益。最终，多客户端的理念是由两者驱动的，并为两者服务。

技术去中心化的主要好处很简单：它降低了一个软件中的一个错误导致整个网络灾难性崩溃的风险。这种风险在2010 年的比特币溢出漏洞事件中真实发生过。当时，比特币客户端代码没有检查交易输出的总和是否溢出（通过总和超过最大整数2^64−1回绕到零)，所以有人利用这一漏洞做了一笔交易，给了自己数十亿比特币。该漏洞在数小时内被发现，并迅速在网络中完成了修复和部署工作，但如果当时有一个成熟的生态系统，这些比特币就会被交易所、跨链桥和其他途径所接受，攻击者可能早已卷巨款而逃。但如果有五个不同的比特币客户端，他们不太可能都有相同的错误，因此一旦发生这类事故，整个网络会立即出现共识分歧，而分歧中有错误的一方可能会输掉。

使用多客户端方法来最小化灾难性错误的风险仍然需要权衡：这种情况下用户会遇到共识失效（consensus failure）的bug。比如，如果您有两个客户端，则客户端对某些协议的规则有细微编码差异的风险，虽然两种方式都是符合规则的，但分歧会导致区块链硬分叉。在以太坊的历史上发生过一次（还有其他更小的分叉，其中运行旧版本代码网络的一部分被分叉）这类严重的分叉。单一客户端机制的捍卫者指出，共识失效是不采用多客户端实现的原因：如果只有一个客户端，则该客户端必然会为自己辩护。他们关于客户数量如何转化为风险的模型可能如下所示：

图：共识失效风险与客户端类型数的关系

但Vitalik本人并不认同单一客户端机制，首先 (i) 2010 年比特币的灾难性错误非常重要， (ii)并且实际上永远不会只有一个客户端。后一点在2013 年的比特币分叉中表现得最为明显：由于两个不同版本的比特币客户端之间存在分歧而发生了分叉，其中一个版本在单个块中可以修改的对象数量上有一个偶然的、未被记录的限制。因此，理论上一个客户端在事实上通常是两个客户端，理论上五个客户端事实上可能是六个或七个客户端 - 所以我们应该走在风险曲线的右侧，并且至少有几个不同的客户端。

垄断客户端开发人员处于拥有大量政治权力的位置。如果客户端开发人员提出更改，而用户不同意，理论上他们可以拒绝下载更新版本，或者在没有其的情况下创建一个分叉链，但实际上用户通常很难做到这一点。如果不当的协议更改与必要的安全更新捆绑在一起怎么办？如果主要团队威胁说如果他们不按他们的方式行事就退出怎么办？或者，如果垄断客户端的团队最终成为唯一拥有最强大协议专业知识的群体，而使生态系统中其他人处于不利地位，无法有效判断客户端团队提出的技术方案，从而使客户端团队有很大的空间来推动其特定的目标和价值观，而这与更广泛的社区并不匹配。

在2013-2014 比特币 OP_RETURN 战争的背景下，一些参与者公开支持歧视区块链的一些特别用途。这激发了以太坊对协议政治的担忧，也是以太坊早期采用多客户端理念的重要促成因素，这旨在让小群体更难做出此类决定。以太坊生态系统特有的担忧——即避免权力集中在以太坊基金会内部——为这一方向提供了进一步的支持。2018 年，基金会决定有意不实施以太坊 PoS 协议（即现在所谓的“共识客户端”），而将该任务完全留给外部团队开发。

如今，ZK-EVM 正在积极地被用于Rollup。这通过允许昂贵的 EVM 执行仅在链下发生几次来增加扩展性，而其他人只需验证链上发布的SNARKs即可证明 EVM 执行结果的正确性。它还允许一些数据（特别是签名）不包含在链上，从而节省 gas 成本。这给了我们很多可扩展性的好处，可扩展计算与 ZK-EVM 和可扩展数据与数据可用性采样的结合可以让扩展走得更远。

然而，今天的以太坊网络也有一个不同的问题，一个再多的 L2 扩容也无法自行解决的问题：L1 难以验证，以至于没有多少用户真正运行自己的节点。相反，大多数用户只是信任第三方工具提供商。Helios和Succinct等轻客户端正在采取措施解决该问题，但轻客户端远非全验证节点：轻客户端仅验证称为同步委员会（sync committee）的随机验证器子集的签名，而不会验证该链是否实际上在遵循协议规则。为了让我们进入一个用户可以实际验证链是否遵守规则的世界，我们必须做一些不同的事情。

随着时间的推移，我们可以将L1每个区块的 gas 目标从 1500 万减少到 100 万，足以让一个区块包含一个 SNARK 和一些存款和取款操作，但其他的不多，从而使几乎所有的用户活动强制移动到L2协议中。这样的设计仍然可以支持在每个块中提交许多Rollup：我们可以使用由定制构建器（customized builders）运行的链下聚合协议来从多个L2协议收集多个SNARK证明，并将它们组合成单个 SNARK证明。这时，L1的唯一功能是成为L2协议的清算中心，验证它们的ZKP并偶尔促成它们之间的大额资金转移。

图：选项一的可能技术解决方案图解

这种方法可能有效，但它有几个重要的弱点：

1. 缺乏向后兼容性，因为许多现有的基于L1 的应用程序在经济上变得不可行。高达数百或数千美元的用户资金可能会陷入困境，因为费用变高后甚至会超过清空这些账户的成本。这可以通过让用户签署消息以选择协议内大规模迁移到他们选择的 L2 来解决（参见此处的一些早期实施想法）但这增加了过渡的复杂性，而且要让它的成本真正足够低，无论如何都需要在L1进行某种SNARK。当涉及到SELFDESTRUCT这样的操作码时，Vitalik本人通常支持打破向后兼容性，但在这种情况下，折衷似乎不那么有利。

2. 可能仍然无法使验证成本足够低。理想情况下，以太坊协议应该不仅在笔记本电脑上而且在手机、浏览器扩展程序甚至其他链中都应该易于验证。第一次同步链，或者长时间离线后同步，应该也很容易。笔记本电脑节点可以在大约 20 毫秒内验证 100 万gas，但即使这样也意味着在离线一天后需要 54 秒进行同步（假设单slot敲定将slot时间增加到 32 秒），而对于手机或浏览器扩展，则每个块需要几百毫秒，并且会造成不可忽视的电池损耗。这些数字是可控的，但仍不理想。

3. 即使在 L2 优先的生态系统中，L1 至少在某种程度上可以负担得起也是有好处的。如果用户在注意到新的状态数据不再可用时可以提取资金，Validiums可以从更强大的安全模型中受益。如果的L2跨链transfer操作的最小规模进一步变小在经济上可行，套利（尤其是小币种套利）将变得更加有效。

因此，尝试找到一种使用 ZK-SNARKs 来验证L1的方法似乎更合理。

第一类（完全等效于以太坊）ZK-EVM可用于验证L1的 EVM 执行。我们可以编写更多的 SNARK 代码来验证区块的共识方面。这将是一个具有挑战性的工程问题：今天，ZK-EVM 需要几分钟到几小时来验证以太坊区块，并且实时生成zk证明需要（i）改进以太坊本身以删除对 SNARK 不友好的组件，（ii）或者通过专门的硬件获得巨大的效率提升 ，(iii)或者通过更多的并行化来改进架构。然而，没有根本的技术原因去阻止三者的实现——所以Vitalik本人希望即使需要很多年，它也最终会完成。

这是ZKEVM与多客户端交集的地方：如果我们使用 ZK-EVM 来验证L1，要使用哪个 ZK-EVM？

1. 单一的客户端 ZK-EVM 机制：放弃多客户端范式，并选择我们用来验证区块的单一 ZK-EVM。

2. 封闭的多客户端 ZK-EVM 生态系统：就一组特定的多个 ZK-EVM 达成一致并达成共识，并有一个共识层协议规则，即一个区块需要来自该集合中超过一半的 ZK-EVM 的证明才能被认为是有效的.

3. 开放的多客户端 ZK-EVM 生态系统：不同的客户端有不同的 ZK-EVM 实现，每个客户端在接受一个块为有效之前等待与自己的实现兼容的证明。

对Vitalik本人来说，（3）似乎是理想的，至少在我们可以形式化证明所有 ZK-EVM 能实现彼此等效并完成技术改进之前，我们可以选择一个最高效的。(1) 会牺牲多客户端范式的好处，并且 (2) 会关闭开发新客户端的可能性并导致更加集中的生态系统。(3) 有挑战，但至少目前这些挑战似乎比其他两个选项的挑战要小。

实施 (3) 不会太难：每个ZK-EVM类型的证明可能都有一个P2P子网络，使用一种ZK-EVM类型证明的客户端将监听相应的子网络并等待直到他们得知验证者认为其证明有效。

(3) 的两个主要挑战可能如下：

1. 延迟挑战：恶意攻击者可能会延迟发布一个块，以及对一个客户端有效的证明。生成对其他客户端有效的证明实际上需要很长时间（即使是 15 秒）。这段时间足够长去创建一个临时分叉链并中断主链的几个slot。

2. 数据效率低下：ZK-SNARKs 的一个好处是可以从块中删除仅与验证相关的数据（有时称为“见证数据（witness data）”）。例如，一旦你验证了一个签名，你就不需要将签名保存在一个块中，你可以只存储一个表示签名有效的bit，并在块中存储一个证明，以确认所有有效签名都存在。但是，如果我们希望能够为一个块生成多种ZK-EVM类型的证明，则需要实际发布原始签名。

延迟挑战可以通过在设计单slot敲定协议时更加谨慎来解决。单slot敲定协议可能需要每个slot进行超过两轮的共识，因此可能需要第一轮包含区块，并且只需要节点在第三轮（或最后一轮）签名之前验证证明。这确保了在发布区块截止时间和预计证明可用时间之间始终有一个重要的时间窗口可用。

数据效率问题必须通过单独的协议来聚合与验证相关的数据来解决。对于签名，我们可以使用ERC-4337 已经支持的BLS聚合。另一类验证相关的数据是用于隐私的ZK-SNARKs，当然这些数据往往有自己的聚合协议。

值得一提的是，基于SNARK证明的L1验证有一个重要的好处：链上 EVM 执行不再需要由每个节点验证，这使得大大增加EVM的执行数量成为可能。这可以通过大幅提高L1 的 gas limit，或通过引入受保护的rollup来完成，或两者兼而有之。

使一个开放的多客户端 ZK-EVM 生态系统运行良好需要大量的工作。但值得庆幸的是，这项工作的大部分正在发生或无论如何都会发生：

• 我们已经有多个强大的ZK-EVM实现。这些实现还不是第一类ZK-EVM（完全等同于以太坊），但其中许多正在积极朝着这个方向发展。

• 在Helios和Succinct等轻客户端上的工作最终可能会变成对以太坊链的 PoS 共识端进行更全面的 SNARK 验证。

• 客户端可能会开始尝试使用 ZK-EVM 来证明自己的以太坊区块执行，特别是当我们有无状态态客户端并且没有技术需要去直接重新执行每个区块来维护状态时。我们可能会从客户端通过重新执行来验证以太坊区块，到大多数客户端通过检查SNARK证明来验证以太坊区块，这将是一个缓慢而渐进的过渡。

• ERC-4337 和 PBS 生态系统可能会很快开始使用 BLS 和证明聚合等聚合技术，以节省 gas 成本，并且目前BLS 聚合的工作已经开始。

有了这些技术，未来看起来非常美好。以太坊区块会比今天更小，任何人都可以在他们的笔记本电脑甚至他们的手机或浏览器扩展程序中运行一个全验证节点，这一切都会发生，同时保留以太坊多客户端理念的优点。

从长远来看，一切皆有可能。也许 AI 会增强形式化验证程度，使其可以轻松证明 ZK-EVM 实现的等效并识别导致它们之间差异的所有错误，这甚至可能是现在就要开始着手开发的项目。如果这种基于形式化验证的协议能够成功，则需要建立不同的机制以确保该协议的政治去中心化持续进行；也许到那时，协议将被视为“完整的”，不可变型规范将更加强大。但即使这是更长远的未来，开放的多客户端 ZK-EVM 生态系统似乎是一个必经之路，无论如何都有可能发生。

从短期来看，这仍然是一段漫长的旅程。ZK-EVM就在这里，但 ZK-EVM 在L1真正可行将需要它们首先改进为第一类ZK-EVM，并使证明产生足够快以使其可以实时发生。有了足够的并行化（这是可行的，但要实现这一点仍然需要做很多工作），共识变化（如提高 KECCAK、SHA256 和其他哈希函数预编译的 gas 成本）也将是以太坊蓝图的重要组成部分。也就是说，过渡的第一步可能比我们预期的要早：一旦我们切换到Verkle 树和无状态客户端，客户端就可以开始逐渐使用 ZK-EVM，并且可以自行过渡到“开放的客户端 ZK-EVM 生态系统”。