Vitalik：以太坊的多客户端理念将如何与 ZK-EVM 互动？
编译：倩雯，**
以太坊以多客户端理念维持其安全性和去**化，这一点**重要，但未曾被深入讨论。以太坊并未设计人人都可以都默认运行的“参考客户端”，而是设定一个用户协作管理的规范（最近用可读性很强但速度很慢的Python中写成)，并有多个团队对该规范（即“客户端”）进行实现，这就是用户实际运行的东西。
每个以太坊节点都运行一个共识客户端和一个执行客户端。截至目前，没有一个共识或执行客户端占网络的2/3以上。如果一个在其类别中份额低于1/3的客户端出现错误，网络将继续正常运行。如果一个在其类别中占有1/3和2/3份额的客户端（比如，Pry**，Lighthouse或Geth）出现错误，链将继续增加区块，但它将停止**确定区块，让开发人员有时间来干预。
这样一来，ZK-EVM就会成为事实上的第三种以太坊客户端，同目前的执行客户端和共识客户端一样，对网络的安全至关重要。这自然会引发一个问题：ZK-EVM将如何与多客户端理念互动？其中一个难点已被解决：我们已有多个ZK-EVM的实现，并且正在积极开发。但其他困难的部分仍然存在：我们将如何真正将“多客户端”生态系统用于ZK证明以太坊区块的正确性？这个问题带来了一些有趣的技术挑战——当然还有一个亟待解决的问题，即这些取舍是否值得。
技术去**化
使用多客户端来减少灾难性漏洞的风险是有代价的：你有可能会得到共识失败的漏洞：如果存在两个客户端，它们对某些协议规则的解释存在微妙不同，那么虽然两种解释都**合理，防止资金盗用的发生，但这种分歧会导致链**成两半。这种类型的严重**在以太坊历史上发生过一次（也发生过其他更小的**）。
当然，我不同意这种分析，因为（1）也要考虑2010年时端灾难性漏洞，当时的情况也很严重；（2）只有一个客户端的情况实际上从未存在。这一点在2013年的比特币分叉事件中表现得最为明显：由于两个不同版本的比特币客户端之间存在分歧，其中一个版本对单个区块中可修改的对象数量有意外的、无记录的限制，导致了链的**。因此，理论上的“一个客户端”在实践中往往是两个客户端，理论上的五个客户端在实践中可能是六个或七个客户端——所以我们不如选择风险曲线（上图）的右边，至少拥有几个不同的客户端。
政治去**化
对协议政治的关注，特别来自于2013-14年的比特币OP_RETURN战争，当时一些参与者公开支持歧视链的某些特定用途，这是以太坊早期采用多客户端理念的一个重要因素，就是为了避免这种情况再次发生。对以太坊生态系统的关注——即避免权力集中在以太坊基金会本身——也为这一方向提供进一步的支持。2018年，团队就决定不让基金会实施以太坊PoS协议（即现在的“共识客户端”），而是把这个任务**留给外部团队。
目前，ZK-EVM被用在rollup上：让成本高昂的EVM执行在链外进行几次，而其他人只需验证链上证明EVM执行计算正确的SNARK，从而进行扩容。它还允许一些数据（特别是签名）不被包含在链上，以节省手续费。这给我们带来了很多扩容方面的好处，而将可扩容计算与ZK-EVM和数据可用性采样结合，可以带来极大程度的扩容。
方案1：收缩**层，迫使几乎所有的活动转移到第2层
1.它事实上无法向后兼容的。也就是说，许多现有基于L1的应用程序在经济上会变得不可行。由于费用变得高昂，甚至超过了清空这些账户的成本，用户的资金可能会被冻结，多达数百或数千美元。让用户签署信息加入协议内大规模到L2的迁移，可以解决这一问题，但这增加了过渡的复杂性。并且，如果想实现真正的低成本，必须在**层实现某种SNARK。当涉及到像SELFDESTRU这样的东西时，我一般赞同打破向后兼容，但在这种情况下，我不建议舍弃向后兼容。
3.即使在L2优先的生态系统中，L1也能以成本不高的方式获益。Validiums可以从更强大的安全模型中受益，如果用户发现新的状态数据不再可用，他们就可以撤回资金。如果经济可行的跨L2直接转移所需的**规模较小，套利就会更加有效，特别是对于较小的**而言。
方案2：SNARK-验证**层
这里就需要考虑多客户端范式：如果我们要使用ZK-EVM来验证**层，我们应使用哪个ZK-EVM？有三种选择：
2）封闭式多ZK-EVM：就一组特定的多ZK-EVM达成共识，并在共识层协议中规定，一个区块需要来自该组中一半以上的ZK-EVM的证明才能被视为有效。
对我来说，方案3比较理想，这种情况不会改变，直到我们的技术改进到可以正式证明所有的ZK-EVM实现都是等价，可以随意选择最有效方案的时候。
实现方案3并不难：我们可以为每种类型的证明建立一个**子网络，使用一种类型的证明的客户将在相应的子网络上进行监听，并等待收到被验证器识别为有效的证明。
方案3的两个主要挑战可能是以下几点：
2）数据效率低下：ZK-SNARK的好处之一是，只与验证有关的数据（有时称为“见证数据”）可以从区块中删除。例如，一旦你验证了一个签名，你就不需要在区块中保留这个签名，你可以只存储一个比特，说这个签名是有效的，同时在区块中存储一个证明，确认所有有效签名的存在。但如果我们希望为一个区块生成多种类型的证明，那么原始签名就需要实际被公布出来。
要解决数据效率问题，就必须有单独的协议来聚合验证相关的数据。对于签名，我们可以使用 BLS聚合，ERC-4337已支持该功能。另一大类与验证有关的数据是ZK-SNARK，用来保护隐私。这些数据通常会有自己的聚合协议。
我们已拥有多个强大的ZK-EVM实现，它们还不算是1型EVM（**等同于以太坊），但其中许多正在积极向这个方向发展。
在轻型客户端（如Helios和 Succinct）上的工作**可能会变成对以太坊链PoS共识进行更**的SNARK验证。
客户端可能会开始尝试使用ZK-EVM来自行证明以太坊区块的执行，尤其是我们能实现无状态客户、在技术上不需要直接重新执行每个区块来维持状态时。我们可能会进行**的过渡：从客户端通过重新执行区块来验证以太坊区块，到大多数客户端通过检查SNARK证明来验证以太坊区块。
ERC-4337和PBS生态系统可能很快就开始使用BLS和证明聚合等聚合技术，以节省手续成本。关于BLS的聚集，相关工作也已开始。