Vitalik：以太坊多客户端将如何与ZK-EVM交互？

作者：Vitalik；翻译:据悉0x25

以太坊维护其安全性和分散化的一种非常重要的方式是它的多客户理念。以太坊有意不默认每个人都经营“参考客户端”：相反，有一个合作管理规范（由非常易读但非常慢的Python编写），许多团队实现了规范（也称为“客户端”），这些客户端客户端由用户实际运行。

每个以太坊节点运行共识客户端和执行客户端。截至目前，客户端占网络的2/3没有共识或执行 以上。如果在其类别中的份额低于 1/3 如果客户端出现错误，网络将照常运行。若占有其类别 1/3 到 2/3 客户端份额(例如 Prysm、Lighthouse 或 Geth）如果出现错误，链将继续添加块，但它将停止最终确定块，以便为开发人员提供干预时间。

ZK-EVM的兴起是以太坊验证方法的一个未完全讨论但非常重要的即将到来的重大变化。证明 EVM 执行的 SNARK已经开发多年，被称为ZK rollups2 积极使用层协议。其中一些 ZK Rollups已经在主网激活，很快就会有更多。但从长远来看，ZK-EVM Rollupp不仅用于Rollupp；我们也想用它们来验证1 层的执行情况。

这种情况一旦发生，ZK-EVM 事实上，第三类以太坊客户端对网络安全的重要性与当今执行客户端和共识客户端一样重要。这自然会问一个问题：ZK-EVM 如何与多客户端互动？困难的部分之一已经完成：我们有许多正在积极发展的部分 ZK-EVM 实现。但其他困难仍然存在：我们如何真正做到这一点？ ZK 创建一个“多客户端”生态系统来证明以太坊块的正确性？这个问题提出了一些有趣的技术挑战——当然，权衡是否值得迫在眉睫。

以太坊多客户端概念的最初动机是什么？

以太坊的多客户哲学是一种分散的，就像一般的分散一样，人们可以关注分散的技术收入或政治分散的社会收入。最后，双方都促进了多客户的概念，并为双方服务。

技术分散化

分散技术的主要好处很简单：它降低了软件中的错误导致整个网络崩溃的风险。例如，这种风险的历史情况是2010 年度比特币溢出漏洞。当时，比特币客户端代码没有检查交易输出的总和是否溢出（通过总和超过最大总数到零），所以有人做了一笔交易，给了自己数十亿比特币。漏洞在几个小时内被发现，并在整个网络中迅速修复和部署，但如果当时有一个成熟的生态系统，这些代币将被交易所、桥梁和其他结构所接受，攻击者可能已经拿走了很多钱。假如有五个不同的比特币客户，他们不太可能都有同样的错误，所以会立即出现分叉，而分叉中有错误的一方可能会输掉。

需要权衡使用多客户端方法来减少灾难性错误的风险：相反，你会遇到共识失败的错误。也就是说，如果你有两个客户端，客户端有微妙的不同解释某些协议规则的风险。虽然这两种解释都是合理的，不允许偷钱，但差异会导致链分成两个。这种类型的严重分叉发生在以太坊的历史上(还有其他较小的分叉，其中运行旧代码的网络的一小部分被分叉)。单一客户端方法的捍卫者将共识失败视为不实现的原因：如果只有一个客户端，客户端不会不同意自己。如何将客户数量转化为风险的模型可能如下所示：

当然，我不同意这种分析。我不同意的是 (i) 2010 年风的灾难性错误也很重要，而且 (ii)其实你永远不会只有一个客户端。后一点在2013 年度比特币分叉最为明显：链分叉发生在两个不同版本的比特币客户端之间，其中一个意外限制了可用对象的数量，但没有记录在案。修改单个区块。所以理论上一个客户端在实践中通常是两个客户端，理论上五个客户端在实践中可能是六个或七个客户端。因此，我们应该面对冒险，走在风险曲线的右侧，至少有几个不同的客户端。

政治去中心化

垄断客户端的开发人员处于拥有大量政治权力的地位。如果客户端开发人员提出更改，而用户不同意，他们理论上可以拒绝下载更新版本，或者在没有它的情况下创建分叉，但用户通常很难做到这一点。如果不愉快的协议变更与必要的安全更新联系在一起呢？如果主要团队威胁说，如果他们不按照自己的方式退出怎么办？或者，更温和地说，如果垄断客户团队最终成为唯一具有最强大协议专业知识的群体，使生态系统的其他部分处于不利地位，无法判断客户团队提出的技术论点，使客户团队面临很大的空间来促进其特定的目标和价值观，这可能与更广泛的社区不匹配？

特别是在2013-14年，对协议政治的担忧 比特币 OP_RETURN 在战争的背景下，一些参与者公开支持分叉链的具体用途是以太坊早期采用多客户哲学的重要因素，旨在让少数人更难做出这样的决定。对以太坊生态系统的独特担忧，即避免以太坊基金会内部的权力集中——为这一方向提供了进一步的支持。2018 年，基金会决定故意不实施以太坊 PoS 协议(即所谓的“共识客户端”)将任务完全留给外部团队。

ZK-EVM未来将如何进入一层？

如今，ZK-EVM 用于Rollup。这允许只在链下发生几次昂贵的事情 EVM 执行可以增加扩展性，而其他人只需要验证链上发布的SNARKS就可以证明 EVM 执行计算是否正确。它还允许链上不包含一些数据（特别是签名），以节省它 gas 成本。这给了我们很多可扩展计算和可扩展计算的好处 ZK-EVM 与可扩展数据和数据可用性采样相结合，可以使我们进一步扩展。

然而，今天的以太坊网络也有不同的问题，无论有多少 layer 2 无法自行解决扩容的问题:layer 1 很难验证，所以很少有用户运行自己的节点。相反，大多数用户只信任第三方提供商。Helios、Succinct等轻客户端正在采取措施解决问题，但轻客户端远非完全验证节点：轻客户端只验证同步委员会随机验证人子集的签名，而不验证链实际上遵循协议规则。为了让我们进入一个用户能够实际验证链条是否遵守规则的世界，我们必须做一些不同的事情。

选项 1：限制一层，几乎所有的活动都被迫移动到二层

随着时间的推移，我们可以把每个块放在一楼 gas 目标从 1500 万减少到 100 一万块就足以让一个块包含一个 SNARK 以及一些存款和取款操作，但其他的并不多，因此几乎所有的用户活动都被迫移动到两层协议。这种设计仍然可以支持在每个区块中提交许多Rollup：通过定制构建者运行的链下聚合协议，我们可以从多个两层协议中收集SNARK，并将其组合成SNARK。在这样的世界里，一层的唯一功能就是成为二层协议的交换所，验证它们的证据，偶尔促进它们之间的大量资金转移。

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

它实际上是向后不兼容的，因为许多现有的基础 L1 在经济上，应用程序变得不可行。用户资金高达数百美元或数千美元可能会陷入困境，因为成本变得如此之高，以至于超过了清空这些账户的成本。这可以通过让用户签署信息来大规模迁移到他们选择的协议中 L2 为了解决（见这里的一些早期实施想法），但这增加了过渡的复杂性，这需要一层SNARK真的足够便宜。当涉及到SELFDESTRUCT 在操作代码等方面，我通常喜欢打破向后兼容性，但在这种情况下，权衡似乎不是很有利。

它可能仍然不能使验证足够便宜。理想情况下，以太坊协议不仅要在笔记本电脑上，还要在手机、浏览器扩展程序甚至其他链中轻松验证。第一次同步链，或者长时间离线后，应该也很容易。笔记本电脑节点可以在大约 20 毫秒内验证 100 万gas，但即便如此，也意味着离线一天后需要 54 秒同步(假设单slot的最终确定性将slot时间增加到 32 秒)，对于手机或浏览器的扩展，每个块需要几百毫秒，可能仍然是不可忽视的电池消耗。这些数字是可控的，但并不理想。

即使在 L2 在优先生态系统中，L1 至少在某种程度上，负担得起也是好的。如果用户注意到新的状态数据不再可用，Validiums可以从更强大的安全模型中受益。如果经济上可行的跨度 L2 最小的直接转移规模较小，套利将变得更有效，特别是对于较小的代币。

因此，试着找到一种使用方法 ZK-SNARKs 验证一楼本身的方法似乎更合理。

选项 2：SNARK验证第一 1 层

类型1(完全等效于以太坊)ZK-EVM可用于验证(1 层)以太坊区块 EVM 执行。我们可以写更多 SNARK 代码验证区块的共识。这将是一个具有挑战性的工程问题：今天，ZK-EVM 验证以太坊区块需要几分钟到几个小时，实时生成证书需要一个或多个（i）改进以太坊本身 SNARK 不友好的组件，（ii） ) 要么通过特殊硬件提高效率，要么通过特殊硬件提高效率 (iii) 通过更多的并行化来改进架构。但是，没有根本的技术原因是做不到这一点的——所以我希望它能完成，即使需要很多年。

如果我们使用它，这就是我们看到与多客户端范式交集的地方： ZK-EVM 来验证 1 层，我们用哪个？ ZK-EVM？

我看到三个选项：

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

2、Closed multi ZK-EVM：只有一组特定的多个 ZK-EVM 达成协议并达成共识，并有一个共识层协议规则，即一个块需要来自集合中的一半以上 ZK-EVM 只有证明才能被认为是有效的.

3、Open multi ZK-EVM：不同的客户有不同的客户端 ZK-EVM 在实现之前，每个客户端都在等待与自己的实现兼容的证明，才能接受一个区块。

对我来说，(3)似乎是理想的，至少直到我们的技术得到改进，我们才能正式证明一切 ZK-EVM 在这个时候，我们可以选择最重要的效率来实现彼此的等效性。(1) 会牺牲多客户端范式的好处， (2) 将关闭开发新客户端的可能性，并导致更集中的生态系统。(3) 但这些挑战似乎比其他两个选项要小，至少现在是这样。

实施 (3) 不会太难:每种类型的证明可能都有 p2p 子网络，使用一种类型的客户端监控相应的子网络，直到他们收到证明验证人认为有效。

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

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

低数据效率：ZK-SNARKs 其中一个优点是，仅与验证相关的数据(有时称为“见证数据”)可以从块中删除。例如，一旦您验证了签名，您不需要将签名保存在一个块中，您只能存储一个表示签名有效的bit，并在块中确认所有签名有效的单个证书。但是，如果我们想为一个块生成各种类型的证书，我们需要实际发布原始签名。

在设计单个slot的最终确定性协议时，要小心解决延迟挑战。单个slot的最终确定性协议可能需要每个slot超过两轮的共识，因此可能需要第一轮包含块，并且只需要在第三轮（或最后一轮）签署前验证节点。这确保了在发布块的截止日期和预期证明可用性的时间之间总是有一个重要的时间窗口。

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

值得一提的是，SNARK 验证 1 层有一个重要的好处:链上 EVM 执行不再需要每个节点来验证这一事实，这可能会大大增加 EVM 执行量可以大幅增加1。 层gas限制或引入enshrineded rollups或两者兼而有之。

结论

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

我们已经实现了许多强大的ZK-EVM。这些实现不是类型 1(完全等同于以太坊)，但很多都在朝着这个方向积极发展。

轻客户端上的工作，如Helios和Succinct，最终可能成为以太坊链 PoS 共识端更全面 SNARK 验证。

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

●ERC-4337 和 PBS 生态系统可能很快就会开始使用 BLS 为了节约和证明聚合等聚合技术 gas 成本。在 BLS 工作已经开始聚在一起了。

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

当然，从长远来看，任何事情都有可能发生。也许 AI 加强形式验证，使其易于证明 ZK-EVM 所有导致它们差异的错误都是通过实现等效和识别来实现的。这样的项目甚至可能是现在开始的实用项目。如果这种基于形式验证的方法成功，则需要建立不同的机制，以确保议议的政治分散化；也许到那时，协议将被视为“完整”，不变性规范将更加强大。但即使这是一个更长远的未来，开放的多客户端 ZK-EVM 世界似乎是下一步，无论如何都有可能发生。

从短期来看，这仍然是一段漫长的旅程。ZK-EVM就在这里，但是 ZK-EVM 在1 它们真的可行，需要它们成为类型 1.并使证据足够快，使其能够实时发生。有足够的并行化是可行的，但要实现这一点，还需要做很多工作。共识变化，如提高 KECCAK、SHA256 以及其他哈希函数的预编译 gas 成本也将是未来图像的重要组成部分。换句话说，过渡的第一步可能比我们预期的要早：一旦我们切换到Verkle树和无状态客户端，客户端就可以逐渐使用ZK-EVM，而且到“多ZK开放”-EVM“世界的过渡可以自己发生。

特别感谢 Justin Drake 反馈和审查