以太坊维持其安全性和去中心化的一种方式，虽然未被充分讨论，但仍然非常重要，那就是它的多客户端理念。以太坊并没有设置每个人都默认运行的”参考客户端”。相反，它有一个由协作团队管理的客户端规格，这个规格目前是用易于人类阅读但速度相对较慢的Python 编写的。同时，还有多个团队在实现这个规格（也称为“客户端”)，这是用户实际运行的。

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

一个被讨论较少，但仍然非常重要的，即将在以太坊链验证方式上发生的主要转变是 ZK-EVMs 的崛起。SNARKs 证明 EVM 执行已经开发了多年，这项技术正在被称为 ZK rollups 的二层协议积极使用。一些 ZK rollups 如今正在主网上活跃，还有更多 即将 上线。但从长期来看，ZK-EVMs 不仅仅会被用于 rollups；我们希望使用它们来验证一层的执行（参见：the Verge）。

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

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

Ethereum的多客户端理念是一种去中心化，就像@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274">一般去中心化，人们可以关注建筑去中心化的技术优势或者政治去中心化的社会优势。最终，多客户端理念由两者激发并服务于两者。

技术去中心化的论据

技术去中心化的主要好处很简单：它降低了一个软件中的一个错误导致整个网络灾难性崩溃的风险。一个历史情况典型地表现了这个风险，那就是2010年比特币溢出bug。当时，比特币客户端代码没有检查交易的输出总和不会溢出（通过求和至 2⁶⁴−1的最大整数以上，将其归零），于是有人做了一个完全这样的交易，给自己分配了数十亿比特币。这个bug在几小时内被发现，一个修复方案被迅速推出并在网络上快速部署，但是如果当时已经有一个成熟的生态系统，那些硬币就会被交易所、桥接和其他结构接受，攻击者可能会赚走大量的钱。如果当时有五个不同的比特币客户端，那它们都有同样的bug的可能性就非常小，所以会立即出现分裂，buggy的一方可能会输掉。

使用多客户端方法来最小化灾难性bug的风险是有一个权衡的：相反，你会得到共识失败的bug。也就是说，如果你有两个客户端，那么客户端对某个协议规则有微妙的不同解释就有风险，而这两种解释都是合理的，不会导致盗窃资金，但不同意会导致链分裂。曾经在Ethereum的历史上发生过一次严重的分裂（还有其他更小的分裂，其中很小一部分运行旧版本代码的网络分叉）。坚持单一客户端方法的人将共识失败视为不应该有多个实现的理由：如果只有一个客户端，那么这个客户端不会与自己产生分歧。他们对客户数量如何转化为风险的模型可能看起来像这样：

我当然不同意这种分析。我不同意的关键在于 (i) 2010 年式的灾难性错误也很重要，并且 (ii)你实际上永远不会只有一个客户端。后一点在 2013 年的比特币分叉事件中表现得淋漓尽致：由于两个不同版本的比特币客户端之间存在分歧，导致链条分裂，其中一个版本意外地对单个区块中可修改对象的数量设置了限制，而这一限制并没有记录在案。因此，理论上的一个客户端在实践中往往是两个客户端，而理论上的五个客户端在实践中可能是六个或七个客户端—所以我们应该冒着风险曲线右侧的风险，至少拥有几个不同的客户端。

政治权力下放的论点

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

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

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

如今，ZK-EVM 被用于汇总（rollup）中。这通过允许昂贵的EVM执行仅在链下进行几次，而所有其他人只需验证在链上发布的证明EVM执行已正确计算的SNARKs，从而增加了扩展性。它还允许一些数据（特别是签名）不被包含在链上，节省了燃气成本。这为我们提供了大量的可扩展性好处，而可扩展计算的ZK-EVMs和可扩展数据的DAS（@vbuterin/sharding_proposal#ELI5-data-availability-sampling">data availability sampling）的结合可能让我们能够进行非常远的扩展。

然而，今天的以太坊网络也有一个不同的问题，这是任何数量的第二层扩展都无法自行解决的：第一层很难验证，以至于并不是很多用户运行自己的节点。相反，大多数用户只是信任第三方提供商。轻客户端如Helios和Succinct正在采取步骤解决这个问题，但轻客户端远非完全验证节点：轻客户端只验证被称为sync committee的验证器的随机子集的签名，并且不验证链实际上遵循协议规则。为了让我们进入一个用户实际上可以验证链遵循规则的世界，我们将不得不做一些不同的事情。

选项 1：限制第 1 层，迫使几乎所有活动移至第 2 层

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

这种方法可行，但它有几个重要的缺点：

• 它实际上是向后不兼容的，从某种意义上说，许多现有的基于 L1 的应用程序在经济上变得不可行。由于费用如此之高以至于超过了清空这些账户的成本，高达数百或数千美元的用户资金可能会陷入困境。这可以通过让用户签署消息以选择协议内大规模迁移到他们选择的 L2 来解决（请参阅一些早期的实施想法），但这增加了过渡的复杂性，而且真正使其足够便宜需要在第一层使用一种 SNARK。我通常支持在处理@vbuterin/selfdestruct">像 SELFDESTRUCT 操作码这样的事情时打破向后兼容性，但在这种情况下，权衡似乎不那么有利。
• 它可能仍然不足以使验证变得足够便宜。理想情况下，以太坊协议不仅应该在笔记本电脑上易于验证，而且还应该在手机、浏览器扩展甚至其他链内部易于验证。第一次同步链或长时间离线后同步链也应该很容易。笔记本电脑节点可以在约 20 毫秒内验证 100 万个 Gas，但即便如此，也意味着在一天离线后需要 54 秒进行同步（假设@vbuterin/single_slot_finality">单槽最终确定性 将时隙时间增加到 32 秒），对于手机或浏览器扩展，每个块将花费几百毫秒，并且可能仍然是不可忽略的电池消耗。这些数字是可以管理的，但并不理想。
• 即使在一个以L2为主的生态系统中，L1至少有一定的经济承受能力也是有好处的。如果用户发现新的状态数据不再被提供，那么他们可以提取他们的资金，Validiums可以从更强的安全模型中受益。如果经济上可行的直接跨L2转账的最小规模较小，那么套利会变得更高效，尤其是对于较小的代币。

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

选项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. 封闭式多 ZK-EVM：商定一组特定的多 ZK-EVM 并将其纳入共识，并制定共识层协议规则，规定区块需要该组 ZK-EVM 中半数以上的证明才能被视为有效。
3. 开放式多 ZK-EVM：不同的客户端有不同的 ZK-EVM 实现，每个客户端在接受一个有效的块之前都会等待与其自己的实现兼容的证明。

对我来说，（3）似乎是理想的，至少直到并且除非我们的技术进步到我们可以正式证明 所有 ZK-EVM 实现都是彼此等效的，此时我们可以选择最有效的一个。 (1) 将牺牲多客户端范式的好处，(2) 将消除开发新客户端的可能性并导致更加集中的生态系统。 (3) 有挑战，但这些挑战似乎比其他两个选项的挑战要小，至少目前是这样。

实现（3）不会太难：我们可以为每种类型的证明建立一个 p2p 子网络，使用一种类型证明的客户端可以监听相应的子网络，直到收到验证者认为有效的证明为止。

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

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

在设计单槽终局性协议时，可以通过小心谨慎来解决延迟问题。单槽终结协议可能需要每个槽两轮以上的共识，因此可以要求第一轮包括区块，只要求节点在第三轮（或最后一轮）签名前验证证明。这样就能确保在发布区块的截止日期与预期可获得证明的时间之间始终有一个相当长的时间窗口。

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

同样值得一提的是，验证第 1 层的SNARK有一个重要的好处：链上 EVM 执行不再需要由每个节点验证，这使得可以大大增加 EVM 执行量。这可能是通过大大增加第1层的燃气限制，或者通过引入被尊崇的rollups，或者两者都有。

结论

要使开放的多客户端 ZK-EVM 生态系统运转良好，需要做大量的工作。但好消息是，这些工作中的大部分都正在进行或即将进行：

• 我们有多个强大的ZK-EVM 已经实现。这些实现还不是 类型 1（完全等同于Ethereum），但其中许多正在积极朝这个方向前进。
• 轻客户端上的工作，像Helios和Succinct，最终可能会变成对以太坊链 PoS 共识侧更全面的 SNARK 验证。
• 客户可能会开始尝试使用 ZK-EVM 来证明自己的以太坊区块执行能力，尤其是当我们有了无状态客户端 ，就没有技术需要直接重新执行每个区块来维护状态。我们可能会得到一个从客户端通过重新执行它们来验证Ethereum区块，到大多数客户端通过检查SNARK证明来验证Ethereum区块的缓慢而渐进的过渡。
• ERC-4337和PBS生态系统可能很快就会开始使用BLS和证明聚合等聚合技术，以节省gas费用。关于BLS聚合，这些工作已经开始。

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

从长远来看，当然，任何事情都有可能发生。或许，人工智能将为形式验证提供超级动力，使其能够轻松证明 ZK-EVM 实现等价，并找出导致它们之间差异的所有错误。这样一个项目甚至可能是现在就可以开始着手的实际项目。如果这种基于正式验证的方法取得成功，就需要建立不同的机制，以确保协议继续保持政治去中心化；也许到那时，协议将被视为 “完整的”，不可更改性规范也会变得更强。但即使这是一个更长远的未来，开放的多客户端 ZK-EVM 世界似乎也是一个自然的踏脚石，无论如何都有可能实现。

从近期来看，这仍然是一个漫长的旅程。ZK-EVM已经出现，但要使ZK-EVM在第1层真正可行，还需要它们成为类型 1，并使其证明速度足够快，以便可以实时发生。如果有足够的并行化，这是可行的，但仍然需要做很多工作才能实现。共识的变化，例如提高 KECCAK、SHA256 和其他哈希函数预编译的 Gas 成本，也将是该图景的重要组成部分。尽管如此，过渡的第一步可能会比我们预期的更快：一旦我们切换到 Verkle 树和无状态客户端，客户端就会开始逐步使用 ZK-EVM，而向 “开放式多 ZK-EVM” 世界的过渡可能会自行开始。

声明：

1. 本文转载自[vitalik]，著作权归属原作者[vitalik]，如对转载有异议，请联系Gate Learn团队，团队会根据相关流程尽速处理。
2. 免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
3. 文章其他语言版本由Gate Learn团队翻译， 在未提及Gate.io的情况下不得复制、传播或抄袭经翻译文章。