解读zk rollup 和 optimistic ZkRollup 的可扩展性不受证明限制

我发现人们对 zkRollup 的工作方式有一些误解。

让我在这篇文章中解释为什么证明者不是限制因素，以及 zk rollup（和optimistic rollup）真正的限制是什么。

ZK L2 不会成为可扩展性解决方案。实时负载有很长的顺序状态依赖性。对于 ZKP 来说，要想跟上链尖的脚步，证明者时间 + 验证时间必须低于实时执行的时间。这只能是对于那些间歇性的负载来说。真正的负载不是间歇性的。Solana 正在处理的是一个永无止境的依赖状态转换链。证明者不可能跟得上。

第一步是保持网络的同步性。这不是专门针对 zkRollup 的，这对任何链（L1、L2、…L43、zk、optimistic、side-chain，等等）都是一样的。

一旦你有一个（或许多）节点已经同步了，你需要为所有这些批次建立证明（我们把一个批次称为 L2 区块，以区别于 L1 区块）。

为了建立证明，你需要重新执行批处理并建立 zkProof. 在 polygon zkEVM 的情况下，在一台简单的机器上，10M 的 gas 批次处理需要 2 秒（我们内部称这个参考为“火箭”，它有 128 核心和 512Gb 的内存）。

但是，这个过程可以并行运行！这意味着，你可以让一台服务器计算批次一的验证器，第二台服务器计算批次二，第三台服务器计算批次三，以此类推。

如果网络有很高的需求，产生了许多批次，你将需要许多证明者来追赶，但如果网络的负载减少，你可以关闭其中一些服务器。

一旦你有了一个连续序列（一个链段）的所有批次证明，你就可以把它们聚合起来。这意味着，例如你可以计算一个证明，证明批次一的证明和批次二的证明。 你可以对第三批证明和第四批证明做同样的事情。

所以你可以建立一个证明树，其中根部证明了一个完整的链段。你可以用你想要的形状和并行的方式建立这棵树。你可以让一个服务器聚合证明 1 和 2，而另一个服务器聚合证明 3 和 4. 这个证明在“火箭”中需要 10 秒。

最后一步是在链上发送这个汇总的证明。这个证明在链上存储 rollup 状态，并允许用户提取资金。这一点有间隔地定时发生（就 @0xPolygon zkEVM 而言，是 30 分钟）。

在这最后一步，证明被从 STARK 转换为 SNARK（FFLONK），这减少了验证链上证明的 gas 成本。这个过程在“火箭”中大约需要 2 分钟，无论证明环节有多长，整个交易的 gas 成本大约是 350K。

这里最重要的参数是证明成本，因为它影响到交易费用。但与其他成本相比，如数据可用性成本、L1 交易的成本、维护成本或甚至 optimistic rollup 的资本成本，这一成本变得微不足道。

所以说，zkRollup 的可扩展性完全不受证明者的限制！

那么 zkRolloup 可扩展性的限制是什么？

这一点上，它们和任何其他的rollup 都是一样的。下一个瓶颈是数据的可用性。这就是为什么推动 Ethereum2 danksharding 和 EIP4844 那么重要。

一旦解决了数据的可用性，下一个瓶颈将是保持链的同步（与 zkProof 无关）。在这一点上，在一个并行运行的多 rollup 生态中思考将有很大的意义（多处理器的解决方法）。

你可以在这里测试Polygon zkEVM：https://polygon.technology/blog/your-three-step-guide-to-using-polygon-zkevm-yes-its-that-easyand

我们将于 3 月 27 日在主网推出测试版!