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

日期：2023-04-03 20:19:10发布：张合

欧意app

欧意是知名虚拟币交易所，提供上百种虚拟币交易平台。

导读：Vitalik：以太坊的多客户端理念将如何与 ZK-EVM 互动？？下文是小编给大家带来的介绍。

编译：倩雯，最新

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

每个以太坊节点都运行一个共识客户端和一个执行客户端。截至目前，没有一个共识或执行客户端占网络的2/3以上。如果一个在其类别中份额低于1/3的客户端出现错误，网络将继续正常运行。如果一个在其类别中占有1/3和2/3份额的客户端（比如，Prysm，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：收缩第1层，迫使几乎所有的活动转移到第2层

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

3.即使在L2优先的生态系统中，L1也能以成本不高的方式获益。Validiums可以从更强大的安全模型中受益，如果用户发现新的状态数据不再可用，他们就可以撤回资金。如果经济可行的跨L2直接转移所需的最小规模较小，套利就会更加有效，特别是对于较小的代币而言。

方案2：SNARK-验证第1层

这里就需要考虑多客户端范式：如果我们要使用ZK-EVM来验证第1层，我们应使用哪个ZK-EVM？有三种选择：

2）封闭式多ZK-EVM：就一组特定的多ZK-EVM达成共识，并在共识层协议中规定，一个区块需要来自该组中一半以上的ZK-EVM的证明才能被视为有效。

对我来说，方案3比较理想，这种情况不会改变，直到我们的技术改进到可以正式证明所有的ZK-EVM实现都是等价，可以随意选择最有效方案的时候。

实现方案3并不难：我们可以为每种类型的证明建立一个p2p子网络，使用一种类型的证明的客户将在相应的子网络上进行监听，并等待收到被验证器识别为有效的证明。

方案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的聚集，相关工作也已开始。

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

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