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

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

2.1.1 系统模型
本文提出的跨 Rollup 方案 BR(Rollup sender → Rollup receiver ) 是针对以下的场景的假设. 针对一条原生链 Blockchain,
它具有各自独立的链下扩容方案发送方 Rollup sender 和接收方 Rollup receiver , 并且智能合约 Contract sender 和 Contract receiver
分别部署在两个 Rollup 上. 一笔完整的交易会有两阶段的生命形态, 包括发送方交易 TX sender 和接收方交易
TX receiver . 一个通常的流程是用户将交易发送至发送方 Rollup sender , 在 Rollup sender 中执行发送方交易 TX sender 后产生
二阶段的接收方交易 TX receiver 并发送到 Rollup receiver 中执行. 同时, 接收方交易 TX receiver 需要作为发送方交易 TX sender
执行后所抛出的事件存储在交易收据树 ReceiptTree 中, 如图 2 所示, 交易收据树 ReceiptTree 是默克尔树根的一
部分.

2.1.2 系统假设
本文的系统对 Rollup 做出了一些假设, 这些假设本身也是常见的 Rollup 假设. 本文的互操作方案仅限于
Rollup 方案, Rollup 是区块链 Blockchain 的一个扩容策略, 它需要满足的条件如下.
(1) 交易可读性: Rollup 内执行的原始交易 TX sender 被存储在链上节点, 其他节点可以随时读取该笔交易, 且该
交易必然已经被执行了, 成功与否会被记录在交易收据树中.
(2) 状态根有效性: Rollup 内执行成功后的默克尔树状态根 MerkleRoot 被上传到链上, 并由 Rollup 的自身的
验证机制确保其有效性以及正确性. 该状态根存储在原生链上, 其他节点可以确认该根的结果有效性.
(3) 交易实时性: Rollup 内的节点对于所有可执行的合法交易, 会及时将交易放入待打包交易池中, 而不会因
为交易费等其他因素拒绝执行交易.
(4) 交易通用性: Rollup 内能够执行的交易是具备一定的通用性, 能在智能合约中执行.

2.1.3 交易类型
需要说明的是本文实现的 Rollup 方案是最基础的单向的互操作交易类型, 后续复杂的交易类型都可以在本
文之上扩展.
对于完整的交易事务性而言, 系统可以通过增加事务管理器的方式增加交易事务性. 本文的跨 Rollup 方案
仅能保证在 Rollup sender 内执行成功的交易, Rollup receiver 可获得交易并执行; 在 Rollup sender 内执行失败的交易,
Rollup receiver 内不会执行. 而不保证在 Rollup sender 执行成功, 但 Rollup receiver 执行失败的情况下, Rollup sender 内的交易
将会回滚. 这种强事务性保障需求, 需要在本文的机制基础上进一步加强. 这可以选择一种完善的事务保障机制,
在 Rollup receiver 内执行失败后, 再发起一笔 Rollup sender 内的对应回滚交易来保障其事务性. 通过两笔单向跨 Rollup
交易以及对应的事务管理器来解决交易事务性的问题.
对于多 Rollup 的互操作的需求, 系统可以通过增加多交易管理器的方式增加多 Rollup 的互操作方案. 本文讨
论的交易范畴仅在两个 Rollup 上展开, 但事实的业务需求会需要多个 Rollup 间的互操作. 多个 Rollup 间的交易,
可以拆分成多笔两两之间的 Rollup 交易. 通过多交易管理器管理多笔单向的 Rollup 交易来共同完成多 Rollup 间
的互操作方案. 本文可以成为未来多 Rollup 间的互操作方案的基础.

2.2 整体设计思路
本文提出了一种基于原生链的跨 Rollup 方案, 称为 NativeBridge, 它所涉及的跨 Rollup 方案的主要工作分为
两个部分, 第 1 部分为发送方交易 TX sender 提供有效性验证, 第 2 部分为接收方 Rollup 同步接收方交易 TX receiver . 而
交易验证和交易同步在链下基于服务商的方案中已经有相关方案.
由于原生链每个区块的计算资源与存储资源有限, 详见第 1.3 节的分析, 将每笔跨 Rollup 的链下验证方案和
存储方案直接迁移至原生链, 会消耗大量的原生链计算与存储资源. 因此, 本文提出的整体解决思路是采用批量化
的处理方法, 以均摊单笔交易所需的链上资源消耗, 从而使单个区块能够承载更多交易, 提升系统吞吐量.
对于链上计算资源受限的问题, 本文采用的策略是利用 zk-SNARKs 类零知识证明所具有的简洁性证明特性,
将多笔交易的验证通过一个简单高效的零知识证明验证策略批量证明, 对于原生链只需要投入较少的计算资源就
可以验证一批交易是否成功, 减少单笔交易的平均开销. 具体的方案介绍详见第 2.3 节.