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

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”世界的过渡可能会自动发生。