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

原文标题：How will Ethereum's multi-client philosophy interact with ZK-EVM?

原文作者：Vitalik Buterin

编译：倩雯，ChainCatcher

以太坊以多客户端理念维持其安全性和去中心化，这一点十分重要，但未曾被深入讨论。以太坊并未设计人人都可以都默认运行的“参考客户端”，而是设定一个用户协作管理的规范（最近用可读性很强但速度很慢的Python中写成)，并有多个团队对该规范（即“客户端”）进行实现，这就是用户实际运行的东西。

每个以太坊节点都运行一个共识客户端和一个执行客户端。截至目前，没有一个共识或执行客户端占网络的2/3以上。如果一个在其类别中份额低于1/3的客户端出现错误，网络将继续正常运行。如果一个在其类别中占有1/3和2/3份额的客户端（比如，Prysm，Lighthouse或Geth）出现错误，链将继续增加区块，但它将停止最终确定区块，让开发人员有时间来干预。

在验证以太坊证的方式中，一个未被充分讨论、但即将到来的重大转变就是ZK-EVM的崛起。证明EVM执行的SNARK已经被开发多年，该技术正被称为ZK rollup的L2协议积极采用。其中一些ZK rollup活跃在主网上，更多即将到来。但从长远来看，ZK-EVM将不仅仅用于rollup，我们还想用它来验证第一层的执行情况。

这样一来，ZK-EVM就会成为事实上的第三种以太坊客户端，同目前的执行客户端和共识客户端一样，对网络的安全至关重要。这自然会引发一个问题：ZK-EVM将如何与多客户端理念互动？其中一个难点已被解决：我们已有多个ZK-EVM的实现，并且正在积极开发。但其他困难的部分仍然存在：我们将如何真正将“多客户端”生态系统用于ZK证明以太坊区块的正确性？这个问题带来了一些有趣的技术挑战——当然还有一个亟待解决的问题，即这些取舍是否值得。

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

以太坊的多客户理念是一种去中心化，就像一般的去中心化，人们既可以关注架构去中心化的技术好处，也可以关注政治去中心化的社会好处。最终，多客户端理念由这两者促成，并为这两者服务。

技术去中心化

技术去中心化的主要好处很简单：它减少了软件中的一个错误导致整个网络全然崩溃的风险。体现这种风险的历史情况是2010年比特币的溢出漏洞。当时，比特币客户端代码没有检查交易输出的总和是否溢出（通过加总超过264-1的最大整数而环绕到零），因此有人进行了溢出交易，给自己带来了数十亿的比特币。这个错误在几个小时内就被发现了，修复程序被匆匆部署到整个网络，如果当时有一个成熟的生态系统，这些代币就会被交易所、桥和其他机构所接受，攻击者就会卷款而逃。但如果当时有五个不同的比特币客户端，它们都出现相同漏洞的可能性很小，那么会立即发生分裂，而分裂中存在漏洞的一方可能会输。

使用多客户端来减少灾难性漏洞的风险是有代价的：你有可能会得到共识失败的漏洞：如果存在两个客户端，它们对某些协议规则的解释存在微妙不同，那么虽然两种解释都十分合理，防止资金盗用的发生，但这种分歧会导致链分裂成两半。这种类型的严重分裂在以太坊历史上发生过一次（也发生过其他更小的分裂）。

单客户端方法的捍卫者会援引共识失败，认为不需要进行多种实现：如果只有一个客户端，该客户端就不会与自己产生分歧。他们关于客户端数量会引发风险的模型可能如下所示：

当然，我不同意这种分析，因为（1）也要考虑2010年时端灾难性漏洞，当时的情况也很严重；（2）只有一个客户端的情况实际上从未存在。这一点在2013年的比特币分叉事件中表现得最为明显：由于两个不同版本的比特币客户端之间存在分歧，其中一个版本对单个区块中可修改的对象数量有意外的、无记录的限制，导致了链的分裂。因此，理论上的“一个客户端”在实践中往往是两个客户端，理论上的五个客户端在实践中可能是六个或七个客户端——所以我们不如选择风险曲线（上图）的右边，至少拥有几个不同的客户端。

政治去中心化

处于垄断地位的客户端开发者具有很大的政治权力。如果客户端开发者提出一个改变，而用户不同意，理论上他们可以拒绝下载更新的版本，或者创建一个没有这个版本的分叉，但实际上用户往往很难做到这一点。如果这种令人不快的协议变化与必要的安全更新捆绑在一起呢？如果主要团队威胁要退出呢？或者更普通的情况是，如果处于垄断地位的客户端团队是唯一在协议知识方面最专业的团体呢？这样一来，生态系统的其他成员难以判断客户团队提出的技术论点是否恰当，客户端团队拥有很大的空间来推行他们自己的目标和价值观，而这些目标和价值观可能与社区更广泛的追求不一致，那该怎么办？

对协议政治的关注，特别来自于 2013-14年的比特币OP_RETURN战争，当时一些参与者公开支持歧视链的某些特定用途，这是以太坊早期采用多客户端理念的一个重要因素，就是为了避免这种情况再次发生。对以太坊生态系统的关注——即避免权力集中在以太坊基金会本身——也为这一方向提供进一步的支持。2018年，团队就决定不让基金会实施以太坊PoS协议（即现在的“共识客户端”），而是把这个任务完全留给外部团队。

ZK-EVM 未来将如何在第一层出现？

目前，ZK-EVM被用在rollup上：让成本高昂的EVM执行在链外进行几次，而其他人只需验证链上证明EVM执行计算正确的SNARK，从而进行扩容。它还允许一些数据（特别是签名）不被包含在链上，以节省手续费。这给我们带来了很多扩容方面的好处，而将可扩容计算与ZK-EVM和数据可用性采样结合，可以带来极大程度的扩容。

然而，今天的以太坊网络也面临不同的问题，任何第2层扩容方案都无法解决：第1层很难验证，以至于没有多少用户运行自己的节点。相反，大多数用户只信任第三方供应商。轻型客户端，如 Helios和 Succinct正在采取措施解决该问题，但轻型客户端远不是完全的验证节点：轻型客户端只是验证一个随机的验证者（称为“同步委员会”）子集的签名，而不验证链是否真正遵循了协议规则。为了实现用户可以真正验证链是否遵循规则，我们必须做出改变。

方案1：收缩第1层，迫使几乎所有的活动转移到第2层

我们可以逐步将每区块的第一层gas目标从1500万减少到100万，足以让一个区块包含一个SNARK和一些存款和取款操作，但不能进行太多的其他操作，从而迫使几乎所有用户活动转移到第二层协议。这样的设计仍然可以支持在每个区块中提交许多rollup：我们可以使用由定制化构建者运行的链外聚合协议，把来自多个第二层协议的SNARK聚集并合并成一个SNARK。这样一来，第一层的唯一功能是成为第二层协议的交换中心，验证第二层的证明，偶尔促进它们之间的大额资金转移。

这种方法可以发挥作用，但它有几个重要的弱点：

1.它事实上无法向后兼容的。也就是说，许多现有基于L1的应用程序在经济上会变得不可行。由于费用变得高昂，甚至超过了清空这些账户的成本，用户的资金可能会被冻结，多达数百或数千美元。让用户签署信息加入协议内大规模到L2的迁移，可以解决这一问题，但这增加了过渡的复杂性。并且，如果想实现真正的低成本，必须在第一层实现某种SNARK。当涉及到像SELFDESTRU这样的东西时，我一般赞同打破向后兼容，但在这种情况下，我不建议舍弃向后兼容。

2.验证的成本并不会因此大幅度降低。理想情况下，以太坊协议应该很容易验证，不仅在笔记本电脑上，而且在手机、浏览器插件，甚至在其他链内。首次同步链、或者在长时间离线后同步链，也应该是很容易的。一个笔记本节点可以在大约20毫秒内验证100万gas，但即使是这样，也意味着离线一天后需要54秒来进行同步（假设单个槽位的终结性时间增加到32秒），而对于手机或浏览器插件来说，每个区块需要几百毫秒，可能仍会带来不可忽视的电池消耗。这些数字虽然可控，但并不符合我们的理想期望。

3.即使在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的两个主要挑战可能是以下几点：

1）延迟：恶意攻击者可能会延迟发布区块和对客户端有效的证明，这会需要很长的时间（即甚至是15秒）来生成对其他客户有效的证明，这一时间足以创造临时分叉，并在几个时间槽内对链干扰。

2）数据效率低下：ZK-SNARK的好处之一是，只与验证有关的数据（有时称为“见证数据”）可以从区块中删除。例如，一旦你验证了一个签名，你就不需要在区块中保留这个签名，你可以只存储一个比特，说这个签名是有效的，同时在区块中存储一个证明，确认所有有效签名的存在。但如果我们希望为一个区块生成多种类型的证明，那么原始签名就需要实际被公布出来。

延迟可以通过谨慎设计单槽确定性协议来解决。单槽确定性协议可能需要每槽两轮以上的共识，因此可以要求第一轮包括区块，只要求节点在第三轮（或最后一轮）签字前验证证明。这可以确保在发布区块的最后期限和预计证明可用的时间之间总是留有重要的时间窗口。

要解决数据效率问题，就必须有单独的协议来聚合验证相关的数据。对于签名，我们可以使用 BLS聚合，ERC-4337已支持该功能。另一大类与验证有关的数据是ZK-SNARK，用来保护隐私。这些数据通常会有自己的聚合协议。

还值得一提的是，SNARK-验证第1层有一个重要的好处：链上EVM的执行不再需要由每个节点来验证，这就有可能实现EVM的执行量的大幅上涨，可以通过大大增加第1层的gas限制来实现，或引入隐含的rollup，（enshrined rollup），或者两者都进行采用。

结论

实现多客户端ZK-EVM生态系统的良好运作并非易事。但好消息是，这些工作中的大部分正在发生或将发生：

• 我们已拥有多个强大的ZK-EVM实现，它们还不算是1型EVM（完全等同于以太坊），但其中许多正在积极向这个方向发展。

• 在轻型客户端（如Helios和 Succinct）上的工作最终可能会变成对以太坊链PoS共识进行更全面的SNARK验证。

• 客户端可能会开始尝试使用ZK-EVM来自行证明以太坊区块的执行，尤其是我们能实现无状态客户、在技术上不需要直接重新执行每个区块来维持状态时。我们可能会进行缓慢的过渡：从客户端通过重新执行区块来验证以太坊区块，到大多数客户端通过检查SNARK证明来验证以太坊区块。

• ERC-4337和PBS生态系统可能很快就开始使用BLS和证明聚合等聚合技术，以节省手续成本。关于BLS的聚集，相关工作也已开始。

随着这些技术的到位，未来一片向好。以太坊区块将比现在更小，任何人都可以在他们的笔记本电脑甚至手机或在浏览器插件中运行一个完全验证的节点，而这一切都将需要保留以太坊的多客户端理念。

在更久的未来，一切都可能发生。也许人工智能会大幅提升形式化验证的性能，使其能够轻松证明ZK-EVM实现的等价，并识别出导致它们之间差异的所有漏洞。甚至我们现在就应着手开始这个项目。如果这种基于形式验证的方法能够成功，就需要建立不同的机制，确保协议持续的政治权力去中心化；也许到那时，协议会被认为是“完整的”，不可更改性规范会更强健。但是，即使是在很久之后，开放的多客户端ZK-EVM也是一个终会到来的世界。

短期来看，这一切道阻且长。ZK-EVM已经出现，但要实现ZK-EVM在第1层真正可行，需要它成为1型ZK-EVM，并实现快速、实时的证明。拥有足够的并行，就可以做到这一点，但仍需大量工作。提高KECCAK、SHA256和其他哈希函数预编译的手续成本这样的共识变化也将是未来蓝图的重要部分。过渡的第一步可能会比我们预期的更快发生：一旦我们转换到沃克尔树和无状态客户端，客户端可能会开始逐渐使用ZK-EVM，向“开放、多ZK-EVM”世界的过渡可能会自动发生。