一种未被充分讨论但非常重要的以太坊维护其安全性和去中心化的方式是其多客户端理念。以太坊有意没有默认每个人都运行“参考客户端”：相反，有一个协作管理的规范（是用非常易读但非常慢的Python编写的）并且有多个团队实现规范（也称为“客户端”），这些客户端客户端由用户实际运行。
每个以太坊节点运行一个共识客户端和一个执行客户端。截至今天，没有共识或执行客户端占网络的2/3 以上。如果在其类别中份额低于 1/3 的客户端出现错误，则网络将照常运行。如果在其类别中占有 1/3 到 2/3 份额的客户端（例如 Pry、Lighthouse 或 Geth）出现错误，链将继续添加区块，但它会停止最终确定区块，从而为开发人员提供时间进行干预。
以太坊验证方式的一个未被充分讨论但非常重要的即将到来的重大转变是ZK-EVM的兴起。证明 EVM 执行的 SNARK已经开发多年，该技术正被称为ZK rollups的2 层协议积极使用。其中一些 ZK Rollups已经在主网激活，很快就会有更多。但从长远来看，ZK-EVM 不仅仅用于Rollup；我们也想使用它们来验证1 层的执行情况。
一旦发生这种情况，ZK-EVM 实际上成为第三种类型的以太坊客户端，对网络安全的重要性与当今的执行客户端和共识客户端一样重要。这自然会提出一个问题：ZK-EVM 将如何与多客户端交互？困难的部分之一已经完成：我们已经有多个正在积极开发的 ZK-EVM 实现。但其他困难的部分仍然存在：我们如何真正为 ZK 证明以太坊区块的正确性创建一个“多客户端”生态系统？这个问题提出了一些有趣的技术挑战——当然还有权衡是否值得的迫在眉睫的问题。
以太坊多客户端理念的最初动机是什么？以太坊的多客户端哲学是一种去中心化，就像一般的去中心化一样，人们可以关注架构去中心化的技术收益或政治去中心化的社会收益。最终，多客户理念受到双方的推动并为双方服务。
技术去中心化技术去中心化的主要好处很简单：它降低了一个软件中的一个错误导致整个网络灾难性崩溃的风险。例证这种风险的历史情况是2010 年的比特币溢出漏洞。当时，比特币客户端代码没有检查交易输出的总和是否溢出（通过总和超过最大整数回绕到零)，所以有人做了一笔交易，给了自己数十亿枚比特币。该漏洞在数小时内被发现，并迅速修复并在整个网络中快速部署，但如果当时有一个成熟的生态系统，这些代币就会被交易所、桥和其他构造所接受，攻击者可能已经带走了很多钱。如果有五个不同的比特币客户，他们不太可能都有相同的错误，因此会立即出现分叉，而分叉中有错误的一方可能会输掉。
使用多客户端方法来最小化灾难性错误的风险需要权衡：相反，你会遇到共识失败错误。也就是说，如果你有两个客户端，则存在客户端对某些协议规则有细微不同解释的风险，虽然两种解释都是合理的并且不允许偷钱，但分歧会导致链分叉成两个。这种类型的严重分叉在以太坊的历史上发生过一次（还有其他更小的分叉，其中运行旧版本代码的网络的很小一部分被分叉了）。单一客户端方法的捍卫者将共识失败作为不具有多个实现的原因：如果只有一个客户端，则该客户端不会不同意自己。他们关于客户数量如何转化为风险的模型可能如下所示：
我当然不同意这种分析。我不同意的地方在于 (i) 2010 年风格的灾难性错误也很重要，并且 (ii)你实际上永远不会只有一个客户端。后一点在2013 年的比特币分叉中表现得最为明显：由于两个不同版本的比特币客户端之间存在分歧而发生了链分叉，其中一个版本意外地限制了可以使用的对象数量，但未记录在案。在单个区块中进行修改。因此，理论上一个客户端在实践中通常是两个客户端，理论上五个客户端在实践中可能是六个或七个客户端。所以我们应该面对冒险并走在风险曲线的右侧，并且至少有几个不同的客户端。
政治去中心化垄断的客户端的开发人员处于拥有大量政治权力的位置。如果客户端开发人员提出更改，而用户不同意，理论上他们可以拒绝下载更新版本，或者在没有它的情况下创建一个分叉，但实际上用户通常很难做到这一点。如果不愉快的协议更改与必要的安全更新捆绑在一起怎么办？如果主要团队威胁说如果他们不按他们的方式行事就退出怎么办？或者，更温和地说，如果垄断的客户端团队最终成为唯一拥有最强大协议专业知识的群体，而使生态系统的其他部分处于不利地位，无法判断客户端团队提出的技术论点，从而使客户端团队面临有很大的空间来推动他们自己的特定目标和价值观，这可能与更广泛的社区不匹配？
对协议政治的担忧，特别是在2013-14 比特币 OP_RETURN 战争的背景下，一些参与者公开支持分叉链的特定用途，是以太坊早期采用多客户端哲学的重要促成因素，这旨在让一小部分人更难做出此类决定。以太坊生态系统特有的担忧——即避免权力集中在以太坊基金会内部——为这一方向提供了进一步的支持。2018 年，基金会决定有意不实施以太坊 PoS 协议（即现在所谓的“共识客户端”），将该任务完全留给外部团队。
未来ZK-EVM将如何进入1层？如今，ZK-EVM 用于Rollup。这通过允许仅在链下发生几次昂贵的 EVM 执行来增加扩展性，而其他人只需验证链上发布的SNARKs即可证明 EVM 执行计算是否正确。它还允许一些数据（特别是签名）不包含在链上，从而节省 gas 成本。这给了我们很多可扩展性的好处，可扩展计算与 ZK-EVM 和可扩展数据与数据可用性采样的结合可以让我们扩展得更远。
然而，今天的以太坊网络也有一个不同的问题，一个再多的 layer 2 扩容也无法自行解决的问题：layer 1 难以验证，以至于没有多少用户运行自己的节点。相反，大多数用户只是信任第三方提供商。Helios和Succinct等轻客户端正在采取措施解决该问题，但轻客户端远非完全验证节点：轻客户端仅验证称为同步委员会的随机验证者子集的签名，而不会验证该链实际上遵循协议规则。为了让我们进入一个用户可以实际验证链是否遵守规则的世界，我们必须做一些不同的事情。
选项 1：限制1层，强制几乎所有活动移动到2层随着时间的推移，我们可以将1层每个区块的 gas 目标从 1500 万减少到 100 万，足以让一个区块包含一个 SNARK 和一些存款和取款操作，但其他的不多，从而强制几乎所有用户活动移动到2层协议。这样的设计仍然可以支持在每个区块中提交许多Rollup：我们可以使用由定制构建者运行的链下聚合协议来从多个2层协议收集SNARK，并将它们组合成一个SNARK。在这样的世界中，1层的唯一功能是成为2层协议的交换所，验证它们的证据并偶尔促进它们之间的大额资金转移。
这种方法可能有效，但它有几个重要的弱点：
它实际上是向后不兼容的，因为许多现有的基于 L1 的应用程序在经济上变得不可行。高达数百或数千美元的用户资金可能会陷入困境，因为费用变得如此之高，以至于超过了清空这些账户的成本。这可以通过让用户签署消息以选择协议内大规模迁移到他们选择的 L2 来解决（参见此处的一些早期实施想法），但这增加了过渡的复杂性，这需要1层的某种SNARK真正足够便宜。当涉及到SELFDESTRUCT 操作码之类的东西时，我通常喜欢打破向后兼容性，但在这种情况下，权衡似乎不太有利。
它可能仍然无法使验证变得足够便宜。理想情况下，以太坊协议应该不仅在笔记本电脑上而且在手机、浏览器扩展程序甚至其他链中都应该易于验证。第一次同步链的时候，或者长时间离线后，应该也很容易。笔记本电脑节点可以在大约 20 毫秒内验证 100 万gas，但即使这样也意味着在离线一天后需要 54 秒进行同步（假设单slot最终确定性将slot时间增加到 32 秒），而对于手机或浏览器扩展，则需要每个区块几百毫秒，并且可能仍然是不可忽略的电池消耗。这些数字是可控的，但并不理想。
即使在 L2 优先的生态系统中，L1 至少在某种程度上可以负担得起也是有好处的。如果用户在注意到新的状态数据不再可用时可以提取资金，Validiums可以从更强大的安全模型中受益。如果经济上可行的跨 L2 直接转移的最小规模较小，套利将变得更加有效，尤其是对于较小的代币。
因此，尝试找到一种使用 ZK-SNARKs 来验证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、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限制或引入enshrined 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”世界的过渡可以自行发生。
