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

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

2.4.3.1 索引表组织形式
如图 8 所示, 链上索引表的组织形式具有独立的结构. 在这种结构中, 每个 Rollup 节点都拥有自己的一片独
立区域空间. 在这个空间下, 包含了地址表、协议表、数据表等多张索引表. 每张索引表都由多个项组成, 每个项
都包括一个 key 和一个 Value. 其中, key 是一个短索引, 而 Value 则是一个待压缩的字段.

链上存储
key 1 Value 1
地址表
key n Value n
Rollup A 协议表
数据表

地址表
Rollup B 协议表
数据表

图 8 索引表链上存储示意图

地址表主要用于压缩发送方和接收方的地址信息. 通过将较长的地址长度映射为较短的短地址索引, 实现了
地址信息的有效压缩. 数据表则主要应用于合约交易过程中, 将 calldata 字段中的一些较长字符串转换为短索引.
值得注意的是, 在一个 Rollup 中, 可能会部署多个合约. 由于不同合约之间的调用方式各不相同, 因此需要多张数
据表来进行区分. 通常情况下, calldata 可被视为合约函数接口的调用, 而传入的数据则为函数接口调用所需的参
数. 然而, 并非所有参数都需要基于索引表进行压缩. 例如, 如果参数是一个布尔值, 则无需进行压缩. 因此, 需要一
个数据压缩协议来明确指示在交易调用过程中哪些参数采用了基于索引表的数据压缩, 哪些参数未使用, 以及使
用了哪张索引数据表等相关信息. 协议表则负责记录这些数据压缩协议的说明. 在协议表中, Value 值用于存储协
议说明, 而 key 值则是一个简单的序号. 通过这样的设计, 可以有效地组织和管理不同类型的索引表, 从而实现了
地址、数据和协议等信息的高效压缩.
针对跨 Rollup 交易的场景, 索引表的更新策略需要更加精细化, 以提高整体系统的效率, 避免因为引入索引
表而实际上增加了链上存储开销. 本文对索引表的更新提出一些要求, 减少索引表更新的无效开销, 避免引入索引
表后链上实际开销增加的情况, 来实现更高效的索引表管理.
首先, 针对未直接涉及跨 Rollup 交易相关的内容, 无需在链上索引表中更新. 例如在地址表内, Rollup 内的地
址数量会远大于发生交易所涉及的地址数量. 索引表中仅保存跨 Rollup 交易所涉及的地址信息, 而不必关心仅在
Rollup 内执行的地址. 这种做法可以有效地减少索引表的更新次数, 从而提高交易处理效率和系统性能.
其次, 本文的索引表更新时间在上传一批交易前. 在使用索引表压缩的交易在上传前, 检查是否存在未在链上
存储的索引, 并及时增加该批交易所涉及的未更新索引. 这样可以避免因为未及时更新索引表而导致接收方解析
交易失败或者出现异常情况, 同时, 这种方式也可以减少索引表变更的次数, 避免更新索引表的开销过大.
最后, 索引表中的索引数据应该避免冲突. 本文所使用的索引通常采用序号形式, 将增加高频字段的序号作为
短索引标注. 如果不使用序号标识, 也需要选择一些不易产生碰撞的短索引生成方式. 通过在索引产生阶段不发生
碰撞的方式避免索引更新异常的情况, 即使更新不成功索引缺少也能够要求重传缺失的索引. 因为若生成的短索
引发生碰撞, 交易解析失败, 接收方交易将无法准确获得接收方交易, 同时对于正确的零知识证明的明文数据验证
不通过, 带来系统错误.