Page 405 - 《软件学报》2025年第8期

3828 软件学报 2025 年第 36 卷第 8 期

4.6 整体系统性能评价

4.6.1 实验数据及设计
本节将对比本研究提出的基于原生链的跨 Rollup 方案与现有的链下跨 Rollup 方案. 链下跨 Rollup 方案通常
基于中间运营商或流动性市场参与者, 这些方案在很大程度上都存在一定程度的信任假设. 本文将具体对比包括
Hop 方案和 Orbiter Bridge 方案在内的现有方案. 此外, 还将与直接使用简化支付验证 (SPV) 证明以及链上无存储
压缩方案的基于原生链的跨 Rollup 方案的最原始形态进行比较, 该方案称为原始原生链方案. 对于本文提出的方

案称为聚合批量上限为 batch max 的原生链方案. 实验的数据集采用第 4.4 节的数据.
最终评价指标主要包括吞吐量和时延两个方面, 以更全面地了解各种方案在性能和效率方面的差异. 其中需
要对吞吐量和交易时延进行一定的定义说明. 在本实验中, 所指的平均交易时延是从发送方 Rollup 内成功上链且
状态根生效的时刻开始计算, 直至接收方 Rollup 有效接收并可开始执行交易的时刻为止. 系统最大吞吐量指的是
在 Rollup 产生交易速度较大的前提下, 尽可能提高各方案的最大单位时间的系统吞吐量.
4.6.2 实验结果
系统的整体实验结果如表 9 所示, 结果包含几种方案的系统最大吞吐量和平均交易时延.

表 9 系统整体吞吐量性能对比

实验方案 系统最大吞吐量 (tx/s) 平均交易时延 (s)
原始原生链方案 15.2 22.6
NativeBridge-32 109.8 30.5
NativeBridge-256 302.4 72.8
NativeBridge-1024 785.7 150.9
Orbiter Bridge 1 278.6 24.6
Hop 1 446.3 14.1

4.6.3 实验结果分析
通过表中数据本文可以看出, 最原始的原生链方案相较于其他方案, 吞吐量低. 因此, 在本文之前不存在直接
使用原生链作为跨 Rollup 方案的基础. 而对于本文提出的批量化交易处理的原生链方案 NativeBridge, 系统的吞
吐量在随着聚合规模上限逐步增加, 并逐步达到了相对可用的水平. 本文的方案在不依赖任何链下假设, 在完全去
信任化的前提下交易吞吐量最高能达到了每秒 785.7 笔.
事实上而言, 相关文献 [1] 指出, 现存的 Rollup 系统吞吐量性能通常在 1000–3000 tx/s 之间, ZKsync [11] 的官网上
公开自身的交易吞吐量上限大约在 2 000 tx/s. 而且单个 Rollup 内并不会所有交易都是跨 Rollup 交易, 相对而言本
文提出的基于原生链的跨 Rollup 方案的系统吞吐量是可用的.

4.7 小 结
本节设计了实验, 综合评价了本文所设计的各个部分, 包括链上计算部分, 链上存储部分, 聚合规模均衡算法
的效果, 以及系统整体的性能评价. 在链上计算部分, 使用零知识证明的验证效率较大提升了链上平均单笔交易的
计算开销, 最大的计算效率提升比可以达到 98%. 在链上存储部分, 在实际数据集的测试下, 平均的链上存储压缩
效率比可以达到 66.6%. 在聚合规模均衡算法中, 它相较于传统单目标的选择方案都能获得更高的综合评价分数.
该算法有助于在实际环境下, 通过调整聚合规模以平衡链上开销和系统时延. 最后整体系统最高吞吐量可以达到
每秒 785.7 笔交易, 相较于正常 Rollup 的交易 1000–3000 tx/s 的吞吐量上限已经达到一个可用的系统状态.

5 总结与展望

5.1 本文工作总结
原生链是 Rollup 系统的安全性来源, 基于原生链的跨 Rollup 方案可以达到在无额外信任假设的前提下, 实
现 Rollup 间的互操作. 但是原生链本身的性能存在瓶颈, 其链上计算资源和存储资源受限, 直接使用链下验证的