Page 252 - 《软件学报》2026年第1期

彭泽顺 等: 面向跨地理区域联盟链的事务处理技术综述 249

而言, 这些系统通常由发起分片保存原始交易 (如 Monoxide), 而其他分片保存涉及该分片的子交易 (如 relay
transaction). 由于子链保存的内容不相交, 存储开销较低. 但是, 这也会导致跨分片交易验证开销较高. 例如, 在分
片 B 验证区块时, 若存在分片 A 发起的跨分片 A, B 的交易 (原始交易保存在分片 A), 由于分片 B 仅保存了子交
易, 其需要向分片 A 请求原始交易验证, 查询开销较高. 在跨域场景下, 若跨分片交易数量较多或存储空间较少
(如 IoT 领域), 可以使用多子链的方式存储.
为了解决查询跨分片交易造成的高开销, CAPER [28] 、SharPer [42] 等系统将账本存储为有向无环图 (DAG) 的形
式, 每个分片保存了所有涉及该分片的交易 (DAG 的子图), 跨分片交易能在所涉及的任意分片内均可查询, 查询
开销较低. 但是, 这样做也会导致跨分片交易在多个分片内保存有完整的副本, 增加了存储开销. 因此, 若跨域带宽
较为宝贵且跨分片查询请求较多, 可以考虑使用 DAG 的方式存储账本.
CAPER [28] 针对多应用协作设计, 每个应用负责保存该应用的本地交易和所有跨应用交易. 由于 CAPER 的多
应用协作与跨分片提交协议相同, 本节接下来使用分片替代应用做说明. 在图 13(a) 中, CAPER 将每个交易作为一
个区块, 4 个分片组成的 CAPER 区块链账本, t i, 表示跨分片事务, i 代表所属分片发起的事务顺序, j 代表跨分片的
j
f 23, 2 就是第 2、3 个分片发起的, 系统中第 2 t 15 为分
事务顺序, 例如 个跨分片事务, 需要由所有分片保存. 而交易
片 1 内第 5 个分片内交易, 仅由分片 1 保存. 交易间使用哈希指针连接, 用以确定交易间的执行顺序.

t 15 t 25 t 35 t 42 t 15 t 25 t 35 t 42
t 34,3 t 34,3 t 34,3
t 34,3 t 34,3
t 14 t 24
t 14 t 24 t 33
t 33
t 23,2
t 23,2 t 23,2
t 13 t 23,2
t 23,2
t 13 t 32
t 22
t 22 t 32
t 12,1
t 12,1
t 12,1 t 12,1
t 12,1
t 31 t 41
t 11 t 21
t 11 t 21 t 31 t 41
λ λ λ λ λ
(a) (b) (c) (d) (e)
图 13 CAPER 的 DAG 账本结构

SharPer [42] 的账本结构和 CAPER 相似. 在 4 个数据分片组成的系统中, 每个集群也仅维护自己的账本视图, 每
个账本分片同样由片内事务和跨分片事务组成. 但是, 不像在 CAPER 中跨分片交易需要在所有分片内存储,
SharPer 中的跨分片交易只需要在对应分片内保存, 涉及不同分片的交易可以并发执行. 例如, 在上述例子中,
SharPer 只需要分片 2、3 保存 t 23,2 , 其他分片无需存储 t 23,2 .
3.3 分片的放置
大多分片区块链 (如 Elastico、OmniLedger、RapidChain 等) 并未考虑分片数据的放置策略. 由于节点使用无
偏随机函数被划分到不同的分片, 当节点部署在多个数据中心时且每个数据中心内节点足够多时, 一个分片会在
所有数据中心内保存有副本. 此时, 分片内通信需要跨多个数据中心, 严重影响系统性能. 为了最小化分片内通信
的开销, 最理想的情况为让一个分片内的副本存储在相同数据中心. 因为数据中心内网络远高于数据中心间的网
络, 这样可以避免网络成为分片内通信的瓶颈.
基于上述思想, Saguaro [96] 提出了一种树形结构用于边缘计算领域. 该结构分为 4 层, 最下层为边缘设备 (edge
device), 如传感器、车辆等. 在同一城市的边缘设备使用部署在相同城市的一组边缘服务器 (edge server) 管理, 这
组边缘服务器负责存储所管理的边缘设备数据. 类似地, 在每个省部署一组雾服务器 (fog server), 用于管理该省的
所有边缘服务器. 最后, 云服务器 (cloud server) 管理所有雾服务器. 这样, 区块链数据得以按照城市分片, 并且每个
分片放置在对应城市中, 用来最小化用户的访问时间和分片内共识时间. 同时, 为了在数据中心火灾等情况下分片
数据不丢失, 树中的非叶子节点延迟同步其叶节点的账本分片. 最后, Saguaro 还支持动态迁移分片的记录 (即按照