HyperLedger的共识之区块链数据结构

unitimes.media

全球视角，独到见解

“本文将详细阐述区块链数据结构，希望对大家有所帮助。”

区块链包含3种数据结构：a) 原始总账（raw ledger），b) 区块链状态（blockchain state），c) 已验证总账（validated ledger）。区块链状态和已验证总账是为了效率维护的，它们都可以从原始总账导出来。

· 原始总账（Raw ledger (RL)）。原始总账包含了Peer节点的共识服务输出的所有数据。它是deliver(seqno, prevhash, blob)事件的序列，计算prevhash后组成了一个哈希链，前面已经介绍过。原始总账包含了有效的和无效的交易，能够提供系统操作过程中出现过的所有成功和不成功的状态更新、改变状态的尝试等可验证的历史记录。

原始总账允许重放Peer节点所有交易的历史并重建区块链状态（见下文）。它还给请求节点提供了的无效的（未提交的）交易的信息，基于这个信息请求节点的操作已经在第2.5部分描述过了。

· 区块链状态（(Blockchain) state）。状态是Peer节点维护的（KVS的形式），它是可以从原始总账中通过过滤掉无效交易导出来，然后更新有效交易到状态上（对stateUpdate里的每个(k,v)，都执行一下put(k,v)，或者执行相对上一个状态的增量）。

就是说，有了共识保证，所有的正常Peer节点都能收到相同顺序的deliver(seqno, prevhash, blob)事件。因为对背书策略和状态更新版本依赖的计算方法都是确定的，所有的正常Peer节点都能确定blob里面的交易是否是有效的。因而，所有Peer节点都是以相同的方式提交、采用同样的交易序列并更新它们的状态。

· 已验证总账（Validated ledger (VL)）。为了维护只包含有效的和提交的交易（比如，比特币里面有），除了状态和原始总账，Peer节点还维护了已验证总账。这是从原始总账中过滤掉无效交易后形成的哈希链。

批量处理和块信息

共识服务应该批量输出blobs，而不是输出单个的交易（blobs）。这种情况下，共识服务必须要利用并告知每个批块里确定性的交易顺序。每个批块（batch）里交易的数量是共识实现动态选择的。

共识的批量处理不会影响原始总账的构建，原始总账仍然是交易的哈希链。和输出单个交易不同的是，原始总账变成了批块的哈希链而不是单个交易的哈希链。

批量处理时，已验证总账（可选的）区块的构建过程是这样的：因为原始总账里可能包含无效的交易（即，无效背书的交易或者无效版本依赖的交易），Peer节点会先过滤掉这些交易再交付给区块。每个Peer节点都是自己独自完成这个过程的。一个区块就是过滤掉无效交易后的共识批块。这些块的大小是可以动态调整的，也可能是空的。图2是区块构建的图解。