在过去的一年中，以太坊路线图上出现了一些重大里程碑，使网络水平得到了提升。EIP-4844（又名 Dencun）引入了 blob 和 proto-danksharding，使第 2 层的数据存储成本降低了一个数量级，从而大大降低了交易费用。

与此同时，第 2 层（大部分是乐观的版本）已经变得更加集成并在应用程序中得到广泛使用，使得以不到一分钱的价格进行交易成为可能，并改善了以太坊的基本基础设施。

然而，任何关注过 Gas 费用的人都会知道，以太坊上仍然过于拥堵，并且随着区块链的实际使用增长，越来越多的 dApp 将争夺区块空间和计算能力。

无需工程师或密码学家就能知道这是不可持续的。我们已经看到当以太坊变得过于拥挤时会发生什么。在某些特别高峰的时刻，用户支付了超过 2 ETH 才能完成一笔交易，而其中一些交易仍然失败，因为用户争先恐后地让它们优先处理。

在完美的世界中，我们会将尽可能多的计算转移到链下，并且仍然能够发布简洁、可验证的证明，以确保数据正确且位于正确的位置。

零知识证明使这成为可能，但对于区块链来说，在 EVM 中验证具有如此多潜在可能性的交易仍然具有挑战性，而且采用这种方式很快就会变得昂贵。Zk-rollups 必须支付专门的硬件费用，通过证明器创建 ZK 证明，然后通常需要将其转换为以太坊可以理解的证明类型。

简而言之，Optimistic Rollups 验证起来相对容易且成本低廉，而 zk Rollups 则具有挑战性且成本高昂。对于希望在链上开展部分业务并保密的小型甚至中型企业来说，zk Rollups 是**选择，但证明验证的费用可能过高。

到目前为止，品牌 L2 对 zkVerify 这样的模块化证明验证解决方案不感兴趣——它可以将验证成本降低 90% 或更多。他们可以在以后采用它，但目前这不是他们的重点。通常，大型 L2 生态系统相信在同一条链上验证所有这些 ZK 证明，并在用户之间分摊这些成本。

然而，我们确实在汇总即服务 (RaaS) 提供商那里找到了机会，因为他们相信区块链的模块化方法，并且倾向于为无法负担这些验证成本的中小型项目提供服务。对他们来说，将证明发送到独立链，然后将证明验证发送回以太坊的想法非常有意义。就像模块化数据可用性一样，我们现在看到 RaaS 提供商张开双臂采用模块化证明验证。

大型 L2 反对此方法的主要理由有两个：首先，他们认为将证明验证移至不同层会降低 L2 的安全性。实际上，其中一些 L2 已经在链下验证了其证明。他们只是没有公开这一点。

他们的另一个论点是，他们更愿意通过将大量证明组合在一起并实质上创建“证明的证明”来聚合证明。通过这样做，大型 L2 能够将成本分摊到大量交易上。然而，他们似乎并不担心，采用这种方法可能需要几个小时才能聚合数百个证明，而且成本可能会更高。

对于许多用例来说，聚合都是有意义的，但对于想要快速执行某项操作并在相同时间内进行验证的应用程序来说，聚合并不一定有意义。

到**，你仍然必须信任你所使用的 L2。

随着我们的团队不断深入研究 ZK 领域以及以太坊与它的关系，我们发现以太坊实际上确实使用预编译与零知识椭圆曲线具有一定的兼容性，这实际上使其能够更高效地处理验证证明所涉及的计算。但该网络目前仅支持在一条曲线上进行三种数学运算。

这对用户意味着什么？由于某些 zk-SNARK 无法验证，因此需要将证明包装成更友好的形式（使用 bn128 证明），这会导致效率降低、错误空间增加，并且成本可能会更高。理想情况下，开发人员应该能够选择最适合其应用程序的 zk-SNARK，而无法这样做意味着他们必须在质量上做出妥协。

从技术上讲，以太坊有可能随着时间的推移采用更先进的预编译，但实现这些预编译可能需要数年时间。上一次预编译是在 2017 年实现的，此后再没有实现过。

为什么会这样？缺乏需求？在以太坊上实现这些实际上不可行吗？即使社区能够做到这一点，使用这些新的预编译在 EVM 上进行计算是否仍然效率低下？

目前还不清楚。但可以确定的是，EVM 需要彻底改造，而且对于一般用例来说，在链上验证 ZK 证明的成本仍然太高。除了硬件之外，这是使用 zk-rollup 时**的开销。

在 Horizen Labs，我们通过两种方式解决这个问题：以 zkVerify 的形式提供模块化证明验证，并构建完全与 EVM 兼容的链并支持**的零知识预编译。

例如，Horizen 2.0 是基于 Substrate 构建的，它允许无分叉升级，并在社区投票后自动应用。无需在节点端进行任何工作，也不需要硬分叉。

有些团队会倾向于留在 Horizen 2.0 这样的专用生态系统中，因为它有自己紧密联系的社区和网络效应。其他人会选择采用 RaaS 路线来构建自己的自定义汇总，并且他们还可以在那里享受链下证明验证的成本节省。

有多种方法可以通过 ZK 来改进 EVM，但我们认为这需要在下一波采用之前完成。