Boojum 升级为 zkSync 带来了哪些提升？

zkSync 抗住了打铭文的压力测试就要归功于 Boojum。

撰文：Haotian

近期， @zksync 完成了 Boojum 升级，也正是基于此前提，zkSync 才抗住了 SYNC 铭文行动的压力测试。不过， Boojum 却被市场低估了。

Boojum 到底带来了哪些性能提升？被诟病的 DeFi 稳定性问题能解决吗？接下来，谈谈我的理解：

1）Boojum 升级，简单理解，会让 zkSync 完成 SNARK 向 STARK 证明的过渡。工作流程大致如下：

当一个 Batch 封装完成后，这些交易会被分解成多个特定电路，然后并行高速处理生成大量 STARKs，最后被聚合成一个 STARK 证明。最后再把该 STARK 证明封装成一个 SNARK 证明中，并提交到主网进行验证。

这样混合使用 STARK 和 SNARK，既确保了能高效处理大量交易，同时又降低了提交到主网的数据大小（SNARK 较简洁），与主网更加兼容。

而同时采用两项证明方式，意味着其 Prover 系统的高级压缩技术、硬件加速技术、算法优化、批量处理聚合效率、内存和存储优化等都会有重大性能提升；

2）据 @0xtaetaehoho 推文中的阐述，Boojum 更新前平均每笔交易数据量为 211bytes，而升级后可以减少到大约 68bytes，压缩技术的提升会直接大幅提升 layer2 每笔 Batch 的交易量，进而使得 TPS 大幅提升（450 左右），同时单笔交易均摊的 Gas 成本降低（65% 左右）。

原理不难理解，layer2 向主网 calldata 提交状态证明数据，由于主网存储数据有限，layer2 的 STARK 并行处理能力和 SNARK 证明压缩处理技术决定了单次 Batch 可处理的交易量以及 Gas 水平；

3）而之前 ZK-Rollup 在处理较低频 DeFi 交易时存在不稳定性问题，它的原生倾向性不利于 DeFi 稳定。比如 DeFi 多变的价格需要多个 Oracle 喂价，如果两笔交易没有被 Batch 到同一个状态下，产生的交易磨损就会增大。

现在 layer2 单笔 Batch 的交易量大幅提升了，区块内可容纳更多的 Oracle 数据状态更新。DeFi 稳定性问题也会得到有效解决。

恰如 zkSync 官方 @anthonykrose 所言，无论一个区块内包含多少个预言机更新，整个区块状态可以被作为一个整体来处理和记录，且只需要支付一次状态写入的成本。这对于 DeFi 应用在 ZK-Rollup 链上的低费率、高效率和稳定性都大有裨益。

按理说，Boojum 的升级应该算 zkSync 里程碑式的进步。

一方面验证了 ZK 系统交易量级越大，Gas 费越低体验越好的推论，另一方面也证明了链下 Prover 系统的压缩技术、硬件加速等计算资源的高效应用和性能提升，会给 ZK 系统带来无穷的想象空间。

大家都在期待坎昆升级后以太坊主网 Blob 区块容量能降低 layer2 Batch 交易的成本，而今 ZK 系统自身的技术优化已经把 ZK 系 Rollup 和 OP 系 Rollup 拉到了同一条水平线。

关键是，ZK-Rollup 要比 OP-Rollup「主动」多了。一直叙事的 ZK-Rollup 技术优势，在 Boojum 升级后得到了充分证明。

Reference：关于 ZK 硬件加速、算力优化等内容相对抽象，具体可参看以下研报：