Page 235 - 《软件学报》2025年第7期

3156 软件学报 2025 年第 36 卷第 7 期

后一个元素代表了一个数值. 叶子节点是一个 Key-Value 键值对, 存储了账户状态数据. 以太坊将 MPT 转化为一
系列的 K-V 对存储在 LevelDB 中. Hyperledger Fabric 中所有账户及其状态存储在 Merkle Bucket 树中. Merkle
Bucket 由底层的 Hash 表和上层的 Merkle 树组成. 哈希表由一系列哈希桶 (Bucket) 组成, 状态数据被散列到每一
个桶中, 并按序排列, 通过计算每一个桶的所有数据, 获得一个哈希值, 该哈希值作为上层 Merkle 树节点的叶子节
点, 通过不断地迭代, 最终获得整棵树的根节点, 存储在区块头部. Hyperledger Fabric 将状态数据持久化存储到
LevelDB 或 CouchDB [54] 中.

2.1.2 区块链事务处理过程
如前所述, 区块链系统中, 事务是以区块为单位批量处理. 为了保证各节点状态一致, 在事务处理过程中还需
要通过共识来进行协调. 因此, 共识是事务处理过程的一部分. 如图 2 所示, 区块链的事务处理过程可以分为以下
几个步骤.
● 交易发起: 客户端发起一笔交易, 该交易发送至区块链网络中的多个节点.
● 交易验证: 收到交易请求的网络节点需要对交易进行验证. 验证过程包括检查交易的格式、签名、权限和
合法性等, 确保其符合预定义的规则和约束. 验证通过的交易被添加到节点的交易池中, 验证不通过的交易将被丢弃.
● 区块打包: 根据共识协议, 选取出块节点, 该节点从本地交易池中选择一部分交易, 打包成一个新的区块.
● 共识: 出块节点将生成的区块广播到网络中的其他节点. 网络中所有节点遵循某个共识协议对接收到的新
区块进行一系列验证, 包括检查区块的哈希值、事务顺序、合法性等.
● 执行提交: 区块通过验证后将被添加到区块链中, 所有的节点都会执行区块中的内容并更新自己的本地状
态数据库.

节点1 节点2 节点2

用户 请求

1 1
排序并打包区块
2

共识协议

3 3 3

图 2 区块链工作机制

2.1.3 区块链共识协议
共识协议保障了区块链系统多个节点的一致性, 也是整个系统可信性和安全性的基石. 区块链的数据结构, 比
如保存前一个区块的 Hash 以及本区块交易的 Merkle 根, 只能起到快速验证区块内容的作用. 区块链的防篡改能
力根源在于共识协议.
一般将共识协议分为 PoX 系列和 BFT 系列, 前者常用于公链系统, 后者则广泛被许可链系统采用. 比特币系
统采用了工作量证明 (proof of work, PoW) 机制, 由此衍生出系列 PoX 算法. PoX 系列算法核心在于通过某种机制
来获得记账权, 一旦确定由某个节点发布账本 (即新的区块), 其他所有节点只需要验证区块内容的合法性, 不用进
行投票. 由于区块发布之后没有投票确认环节, PoX 协议存在链分叉的问题, 即同一个高度可能存在多个区块.
1993 年, 美国科学家 Dwork 等人 [55] 首次提出了工作量证明这一思想, 主要用于应对垃圾邮件问题. PoW 的核心思
想是通过分布式节点基于各自的计算机算力来解决一个复杂的数学问题, 从而获得下一个区块的记账权. 由于所
选取的数学问题在理论上只能通过穷举来解决, 得到问题的解意味着付出了相应的工作量. PoW 安全性很高, 但