以太坊的多客户端理念将如何与ZK-EVM互动？

以太坊的多客户端哲学将如何与 ZK-EVM 互动？

以太坊的多客户端哲学将如何与 ZK-EVM 互动？

特别感谢 Justin Drake 的反馈和审阅

以太坊保持其安全性和去中心化的一个虽未充分讨论但非常重要的方式是其多客户端哲学。以太坊有意没有默认每个人运行的“参考客户端”：相反，有一个协作管理的规范（如今以非常易读但非常慢的 Python 编写），并且有多个团队制作该规范的实现（也称为“客户端”），这是用户实际运行的内容。

以太坊链验证方式中一个虽未充分讨论但非常重要的即将到来的重大转变是ZK-EVM的兴起。证明 EVM 执行的 SNARK 已经开发了多年，该技术正被称为 ZK rollups 的Layer2协议积极使用。其中一些 ZK rollups 已经在 主网 上 活跃，更多 即将 到来。但从长远来看，ZK-EVM 不仅适用于 rollups；我们还想用它们来验证Layer1的执行（另见：the Verge）。

一旦发生这种情况，ZK-EVM 实际上将成为以太坊的第三种客户端类型，对网络安全的重要性与今天的执行客户端和共识客户端一样。这自然引发了一个问题：ZK-EVM 将如何与多客户端哲学互动？其中一个难点已经完成：我们已经有了多个正在积极开发的 ZK-EVM 实现。但其他难点仍然存在：我们如何实际为 ZK 证明以太坊区块正确性创建一个“多客户端”生态系统？这个问题带来了一些有趣的技术挑战——当然还有权衡是否值得的隐忧。

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

以太坊的多客户端哲学是一种去中心化，就像 一般的去中心化 一样，人们可以关注架构去中心化的技术优势或政治去中心化的社会优势。最终，多客户端哲学是由两者共同推动的，并服务于两者。

技术去中心化的论点

技术去中心化的主要好处很简单：它降低了单一软件中的一个错误导致整个网络灾难性崩溃的风险。一个历史情况可以说明这种风险：2010 年比特币溢出漏洞。当时，比特币客户端代码没有检查交易输出的总和是否溢出（通过求和到最大整数 264−1 以上而回绕到零），因此有人制作了一笔交易，正是这样做的，给自己提供了数十亿比特币。该漏洞在几小时内被发现，修复程序迅速通过并在整个网络中部署，但如果有成熟的生态系统，这些硬币将被交易所、桥接器和其他结构接受，攻击者可能会逃脱大量资金。如果有五个不同的比特币客户端，那么它们都有相同错误的可能性非常小，因此会立即分裂，而分裂的错误一方可能会失败。

使用多客户端方法最小化灾难性错误的风险有一个权衡：相反，你会得到共识失败错误。也就是说，如果你有两个客户端，存在客户端对某些协议规则的解释存在微妙差异的风险，虽然两种解释都是合理的并且不允许窃取资金，但分歧会导致链分裂成两半。这种类型的严重分裂在以太坊历史上 发生过一次（还有其他非常小的分裂，其中运行旧版本代码的网络非常小部分分叉了）。单一客户端方法的支持者指出共识失败是不应该有多重实现的原因：如果只有一个客户端，该客户端不会与自己产生分歧。他们的客户端数量如何转化为风险的模型可能看起来像这样：

我当然不同意这种分析。我不同意的关键是（i）2010 年式的灾难性错误也很重要，以及（ii）你实际上从未只有一个客户端。后一点在 2013 年比特币分叉 中最为明显：由于比特币客户端的两个不同版本之间的分歧导致了链分裂，其中一个版本意外地且未记录地限制了单个区块中可以修改的对象数量。因此，理论上一个客户端在实践中通常是两个客户端，理论上五个客户端在实践中可能是六七个客户端——所以我们应该直接接受挑战，走上风险曲线的正确一侧，至少拥有几个不同的客户端。

政治去中心化的论点

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

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

ZK-EVM 未来将如何进入Layer1？

今天，ZK-EVM 在 rollups 中使用。这通过允许昂贵的 EVM 执行在链下仅发生几次来增加扩展性，其他人只需验证发布在链上的 SNARK，证明 EVM 执行被正确计算。它还允许一些数据（特别是签名）不包含在链上，节省 gas 成本。这为我们带来了很多扩展性好处，ZK-EVM 的可扩展计算与 数据可用性采样 的可扩展数据相结合，可以让我们扩展得非常远。

然而，今天的以太坊网络也有一个不同的问题，这是任何Layer2扩展都无法单独解决的：Layer1难以验证，以至于没有多少用户运行自己的节点。相反，大多数用户只是信任第三方提供者。诸如 Helios 和 Succinct 的轻客户端正在采取措施解决这个问题，但轻客户端远非完全验证节点：轻客户端仅验证称为 同步委员会 的随机验证者子集的签名，并且不验证链是否实际遵循协议规则。为了让我们进入一个用户可以实际验证链遵循规则的世界，我们必须做一些不同的事情。

选项 1：限制Layer1，迫使几乎所有活动转移到Layer2

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

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

• 它实际上是向后不兼容的，因为许多现有的基于Layer1的应用程序在经济上变得不可行。用户资金可能高达数百或数千美元，因为费用变得如此之高，以至于超过了清空这些账户的成本。这可以通过让用户签署消息选择加入协议内的大规模迁移到他们选择的Layer2来解决（参见一些 早期实现想法），但这增加了过渡的复杂性，并且使其真正足够便宜仍然需要在Layer1有某种 SNARK。我通常喜欢在诸如 SELFDESTRUCT 操作码 之类的事情上打破向后兼容性，但在这种情况下，权衡似乎不太有利。
• 它可能仍然无法使验证足够便宜。理想情况下，以太坊协议应该不仅在笔记本电脑上易于验证，而且在手机、浏览器扩展甚至其他链内部也易于验证。首次同步链或在长时间离线后同步也应该很容易。笔记本电脑节点可以在约 20 毫秒内验证 100 万 gas，但这仍然意味着在离线一天后同步需要 54 秒（假设 单槽最终性 将槽时间增加到 32 秒），对于手机或浏览器扩展，每块需要几百毫秒，并且可能仍然是非微不足道的电池消耗。这些数字是可控的，但它们并不理想。
• 即使在Layer2优先的生态系统中，Layer1至少在一定程度上负担得起也有好处。Validiums 可以从更强的安全模型中受益，如果用户注意到新状态数据不再可用时可以提取他们的资金。套利变得更加高效，特别是对于较小的代币，如果经济上可行的跨Layer2直接转移的最小规模更小。

因此，似乎更合理的是尝试找到一种使用 ZK-SNARK 来验证Layer1本身的方法。

选项 2：SNARK 验证Layer1

类型 1（完全以太坊等效）ZK-EVM 可用于验证（Layer1）以太坊区块的 EVM 执行。我们可以编写更多的 SNARK 代码来验证区块的共识侧。这将是一个具有挑战性的工程问题：今天，ZK-EVM 需要几分钟到几小时来验证以太坊区块，实时生成证明将需要以下一个或多个：（i）改进以太坊本身以移除对 SNARK 不友好的组件，（ii）通过专用硬件实现大型效率提升，（iii）通过更多并行化进行架构改进。然而，没有根本的技术原因无法做到这一点——所以我预计，即使需要很多年，它也会完成。

在这里，我们看到了与多客户端范式的交集：如果我们使用 ZK-EVM 来验证Layer1，我们使用哪个 ZK-EVM？

我看到三个选项：

1. 单一 ZK-EVM：放弃多客户端范式，选择一个 ZK-EVM 来验证区块。
2. 封闭多 ZK-EVM：在共识中达成并铭刻一组特定的多个 ZK-EVM，并有一个共识层协议规则，即一个区块需要来自该集合中超过一半 ZK-EVM 的证明才能被视为有效。
3. 开放多 ZK-EVM：不同的客户端有不同的 ZK-EVM 实现，每个客户端在接收到与其实现兼容的证明之前不会接受一个区块为有效。

对我来说，（3）似乎是理想的，至少在技术改进到我们可以 正式证明 所有 ZK-EVM 实现彼此等效之前，届时我们可以选择最高效的那个。（1）将牺牲多客户端范式的好处，（2）将关闭开发新客户端的可能性，并导致更中心化的生态系统。（3）有挑战，但这些挑战似乎比其他两个选项的挑战更小，至少目前如此。

实现（3）并不太难：可以为每种类型的证明设置一个 p2p 子网络，使用一种类型证明的客户端将监听相应的子网络，并等待直到接收到其验证器识别为有效的证明。

（3）的两个主要挑战可能是：

• 延迟挑战：恶意攻击者可能会在发布区块的同时发布一个对某个客户端有效的证明。实际生成对其他客户端有效的证明可能需要很长时间（即使例如 15 秒）。这段时间足够长，可能会创建一个临时分叉并中断链几个槽。
• 数据效率低下：ZK-SNARK 的一个好处是，仅与验证相关的数据（有时称为“见证数据”）可以从区块中移除。例如，一旦你验证了一个签名，你不需要在区块中保留签名，你可以只存储一个位说明签名是有效的，以及区块中的一个证明确认所有有效签名都存在。然而，如果我们希望为区块生成多种类型的证明，原始签名实际上需要发布。

延迟挑战可以通过在设计单槽最终性协议时小心处理来解决。单槽最终性协议可能需要每槽超过两轮共识，因此可以要求第一轮包括区块，并且仅在第三（或最终）轮中要求节点在签署之前验证证明。这确保了在发布区块的截止时间和预计证明可用的时间之间始终有显著的时间窗口。

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

值得一提的是，SNARK 验证Layer1有一个重要的好处：链上 EVM 执行不再需要由每个节点验证，这使得大大增加 EVM 执行量成为可能。这可以通过大大增加Layer1 gas 限制，或引入 铭刻 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 在Layer1真正可行需要它们成为类型 1，并使证明足够快以实时发生。通过足够的并行化，这是可行的，但要实现这一点仍然需要大量工作。共识变化如提高 KECCAK、SHA256 和其他哈希函数预编译的 gas 成本也将是重要的一部分。话虽如此，过渡的第一步可能比我们预期的更早发生：一旦我们切换到 Verkle 树 和无状态客户端，客户端可能会开始逐步使用 ZK-EVM，向“开放多 ZK-EVM”世界的过渡可能会自行开始。

• 原文链接： vitalik.eth.limo/general...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～