原文标题：HowwillEthereum'smulti-clientphilosophyinteractwithZK-EVMs？
原文作者：Vitalik
原文来源：vitalikblog
原文编译：Kate,Marsbit
特别感谢JustinDrake的反馈和审阅
一种未被充分讨论但非常重要的以太坊维护其安全性和去中心化的方式是其多客户端理念。以太坊有意没有默认情况下每个人都运行的“参考客户端”：相反，有一个协作管理的规范(现在是用可读性很强但非常缓慢的Python编写的)，并且有多个团队正在实现该规范(也称为“客户端”)，这是用户实际运行的。
每个以太坊节点运行一个共识客户端和一个执行客户端。截至目前，没有共识或执行客户端占网络的2/3以上。如果一个客户端在其类别中的份额小于1/3，那么网络将继续正常运行。如果在其类别中拥有1/3到2/3份额的客户端(例如Prysm、Lighthouse或Geth)存在bug，链会继续添加区块，但会停止完成区块，从而为开发人员提供时间进行干预。
一个未被充分讨论，但仍然非常重要的，即将到来的以太坊链验证方式的重大转变是ZK-EVM的崛起。证明EVM执行的SNARKs已经开发了多年，该技术正在被称为ZKrollup的L2协议积极使用。其中一些ZKrollup目前在主网上很活跃，很快就会有更多推出。但从长远来看，ZK-EVM将不仅仅是用于rollup，我们也想用它们来验证L1的执行情况(参考：theVerge)。
一旦发生这种情况，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用于Rollup。这通过允许昂贵的EVM执行仅在链下发生几次来增加扩展性，而其他人只需验证链上发布的SNARKs即可证明EVM执行计算的正确性。它还允许一些数据(特别是签名)不包含在链上，从而节省了gas成本。这为我们提供了很多可扩展性的好处，将可扩展计算与ZK-EVM和可扩展数据与数据可用性采样相结合，可以让我们扩展得更远。
然而，今天的以太坊网络也有一个不同的问题，一个再多的Layer2扩容都无法自行解决的问题：Layer1难以验证，以至于没有多少用户运行自己的节点。相反，大多数用户只是信任第三方提供商。像Helios和Succinct这样的轻客户端正在采取措施解决这个问题，但是轻客户端远远不是一个完全验证节点：轻客户端只是验证一个称为同步委员会的随机验证器子集的签名，而不验证该链实际上是否遵循协议规则。为了让用户能够真正验证链是否遵循规则，我们必须做一些不同的事情。
选项1：压缩Layer1，强制几乎所有活动移动到Layer2
随着时间的推移，我们可以将Layer1每个区块的gas目标从1500万降低到100万，足以让一个区块包含单个SNARK和一些存取款操作，但没有太多其他操作，从而强制几乎所有用户活动转移到Layer2协议。这样的设计仍然可以支持在每个块中提交许多rollup：我们可以使用由定制构建器运行的链下聚合协议来收集来自多个Layer2协议的SNARK，并将它们组合成单个SNARK。在这样的世界里，Layer1的唯一功能就是成为Layer2协议的交换所，验证它们的证明，偶尔促进它们之间的大规模资金转移。
这种方法是可行的，但它有几个重要的弱点：
?它实际上是向后不兼容的，因为许多现有的基于L1的应用程序在经济上变得不可行的。由于费用变得过高，超过了清空这些账户的成本，高达数百或数千美元的用户资金可能会陷入困境。这个问题可以通过让用户签署消息来选择在协议内大规模迁移到他们所选择的L2来解决(请参阅这里的一些早期实施想法)，但这增加了过渡的复杂性，而且要想让它真正足够便宜，无论如何都需要在Layer1进行某种SNARK。当涉及到SELFDESTRUCT操作码这样的事情时，我通常喜欢打破向后兼容性，但在这种情况下，这种权衡似乎不那么有利。
?它可能仍然无法使验证变得足够便宜。理想情况下，以太坊协议应该很容易验证，不仅在笔记本电脑上，而且在手机、浏览器扩展，甚至在其他链中。第一次同步链，或者在长时间离线后同步链，也应该很容易。笔记本电脑节点可以在大约20毫秒内验证100万个gas，但即使如此，也意味着离线一天后需要54秒进行同步(假设单个插槽的最终结果将插槽时间增加到32秒)，而对于手机或浏览器扩展来说，每个块需要几百毫秒，并且可能仍然是一个不可忽视的电池消耗。这些数字是可控的，但并不理想。
?即使在L2优先的生态系统中，L1至少在一定程度上是负担得起的。如果用户在注意到新的状态数据不再可用时可以提取他们的资金，那么Validiums可以从更强的安全模型中受益。如果经济上可行的跨L2直接转移的最小规模更小，套利就会变得更有效，特别是对于较小的代币。
因此，尝试找到一种使用ZK-SNARKs来验证Layer1本身的方法似乎更合理。
选项2：SNARK–验证Layer1
类型1(完全等效于以太坊)ZK-EVM可用于验证(Layer1)以太坊块的EVM执行。我们可以编写更多的SNARK代码来验证区块的共识侧。这将是一个具有挑战性的工程问题：今天，ZK-EVMs需要几分钟到几个小时来验证以太坊区块，并且实时生成证明将需要一个或多个(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)有挑战，但这些挑战似乎比其他两种选择的挑战要小，至少目前是这样。
声音 | Kevin Davitt：比特币期货波动率创历史新低:据marketwatch消息，Cboe Global Markets期权研究所高级分析师Kevin Davitt表示，截至10月26日的一周是近一年前推出比特币期货以来波动最小的一周，10月份XBT期货的平均每周波动率约为6.6％，远低于自成立以来的平均水平15.65％。[2018/11/6]
实现(3)不会太难：每个类型的证明都有一个p2p子网络，使用一种类型证明的客户端会在相应的子网络上监听并等待，直到他们收到验证者认为有效的证明。
(3)的两个主要挑战可能如下：
?延迟挑战：恶意攻击者可能会延迟发布区块，以及对一个客户端有效的证明。生成对其他客户端有效的证明实际上需要很长时间(即使例如15秒)。这个时间足够长，可能会创建一个临时分叉，并中断几个插槽的链。
?数据效率低：ZK-SNARKs的一个好处是，只与验证相关的数据(有时称为“见证数据”)可以从块中删除。例如，一旦验证了签名，就不需要将签名保存在一个块中，只需存储一个表示签名有效的位，并在块中存储一个证明，以确认所有有效签名都存在。然而，如果我们希望能够为一个区块生成多种类型的证明，原始签名就需要实际发布。
延迟问题可以通过在设计单槽终端协议时谨慎处理来解决。单槽最终协议可能需要每个槽超过两轮的共识，因此可以要求第一轮包括区块，并且只要求节点在第三轮(或最后一轮)签署之前验证证明。这确保了在发布区块的截止日期和预期证明可用的时间之间总是有一个重要的时间窗口。
数据效率问题必须通过采用单独的协议聚合与验证相关的数据来解决。对于签名，我们可以使用ERC-4337已经支持的BLS聚合。另一个主要类别与验证相关的数据是用于隐私的ZK-SNARKs。幸运的是，这些协议通常都有自己的聚合协议。
值得一提的是，SNARK验证Layer1还有一个重要的好处：链上EVM执行不再需要每个节点进行验证，这使EVM执行的数量可以大大增加。这可以通过大幅提高Layer1gas上限，或引入enshrinedrollups，或两者兼而有之来实现。
结论
要让一个开放的多客户端ZK-EVM生态系统运行良好，需要做大量的工作。但真正的好消息是，大部分工作正在进行或即将进行：
?我们已经有了多个强大的ZK-EVM实现。这些实现还不是类型1(完全等效于以太坊)，但其中许多正在积极地朝着这个方向发展。
?在轻客户端(如Helios和Succinct)上的工作最终可能会变成以太坊链PoS共识端的更完整的SNARK验证。
?客户端可能会开始尝试ZK-EVM来证明以太坊区块的执行，特别是当我们有了无状态的客户端时，在技术上不需要直接重新执行每个区块来维护状态。我们可能会从客户端通过重新执行来验证以太坊区块，过渡到大多数客户端通过检查SNARK证明来验证以太坊区块，这将是一个缓慢而渐进的过渡。
?ERC-4337和PBS生态系统可能很快就会开始使用BLS和证明聚合等聚合技术，以节省gas成本。在BLS聚合上，工作已经开始。
有了这些技术，未来看起来非常美好。以太坊区块将比今天更小，任何人都可以在他们的笔记本电脑，甚至他们的手机或在浏览器扩展中运行一个完全验证的节点，而这一切都将在保留以太坊多客户端理念的同时发生。
从长远来看，当然任何事情都有可能发生。也许人工智能会加强形式验证，使其可以轻松证明ZK-EVM实现是等效的，并识别出导致它们之间差异的所有错误。这样的项目甚至可能是现在就开始工作的东西。如果这种以核查为基础的形式方法取得成功，就需要建立不同的机制，以确保议定书在上继续去中心化的执行。也许到那时，协议将被认为是“完整的”，不可变性规范将更强。但即使这是更长远的未来，开放的多客户端ZK-EVM世界似乎是一个天然的垫脚石，无论如何都可能发生。
从近期来看，这仍是一段漫长的旅程。ZK-EVM已经在这里了，但是ZK-EVM要想在Layer1真正可行，就需要它们成为类型1，并且足够快地证明它可以实时发生。有了足够的并行化，这是可行的，但要达到这个目标仍然需要做很多工作。像提高KECCAK、SHA256和其他哈希函数预编译的gas成本这样的共识变化也将是图景的重要组成部分。也就是说，过渡的第一步可能会比我们预期的发生得更快：一旦我们切换到Verkle树和无状态客户端，客户端就可以开始逐渐使用ZK-EVM，向“开放的多ZK-EVM”世界的过渡可能会自行开始。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。