参考资料（官方文档）:Ledger

Ledger

  在Hyperledger Fabric里面,账本由两个不同但相关的部分组成:世界状态(world state)和区块链(blockchain).
世界状态数据库保存了账本中最新的值，世界状态使程序可以直接访问当前状态数据库的值，无需遍历所有的交易日志。世界状态可以频繁更改（创建/更新/删除）
而区块链中记录当前世界状态的所有更改的交易日志，交易是附加到区块内部的，可追溯。区块链的数据结构与世界状态不同，一旦写入无法修改。

实际网络中，通过共识维护了一个账本的多个副本。

世界状态（World State）

  世界状态维护了对象的最新值，这是很有用的。无需遍历整个区块链来计算当前的值，从世界状态获取即可。

世界状态都会有个版本号，版本号初始为0，每次状态更改时都会递增，同时每次更新时都需要做版本校验。有一点需要注意，当首次创建账本时，世界状态为空，因为任何代表世界状态有效改变的交易都记录在区块链上，意味着随时可以从区块链生成世界状态。例如当节点创建/重启时自动生成世界状态。

区块链（Blockchain）

  区块链通过区块互联顺序记录日志，其中每个区块都会包含一系列交易（世界状态的查询或是更新）。每个区块的头均包含该区块交易的哈希值，以及前一个区块的头的哈希值。

  与使用数据库的世界状态相反，区块链通过文件实现。这是一个明智的设计选择，因为每次追加到区块链的末尾是主要操作，而查询是相对不频繁的操作。

如上图所示，区块链中的第一个块称为创世块（genesis block）。 尽管它不包含任何用户交易，但它是账本的开始。

区块（Block）

  如下图所示，每个区块主要包含三个部分：
区块头：包含三个字段，伴随区块创建写入。

1. 区块号（Block number）：从0（创世块）开始的整数，每次新生成区块时加1
2. 当前区块哈希（Current Block Hash）：当前区块所有交易的哈希
3. 上一区块哈希（Previous Block Header Hash）：上一个区块头的哈希
   

  区块数据（Block Data）：按顺序排列的交易（下节介绍）列表。

  区块元数据：包含块创建者的证书和签名，用于通过网络节点验证块。 随后，块提交者将每个事务的有效/无效指示符添加到也驻留在块元数据中的位图中，以及直到（包括）该块为止的累积状态更新的哈希，以检测状态派生。 与块数据和区块头字段不同，此部分不是块哈希计算的输入。

交易（Transaction）

  下图为交易的结构：

主要包括以下五部分：

1. Header：包含交易的一些元数据，例如链码的名称及版本
2. Signature：包含由客户端应用程序创建的加密签名。 此字段用于检查交易明细是否未被篡改，因为它需要应用程序的私钥来生成它。
3. Proposal：应用程序提供给智能合约进行模拟账本执行的输入参数的数据结构。
4. Response： 它是智能合约的输出，如果交易成功通过验证，将更新世界状态，包含了读写集等信息。
5. Endorsements：各个组织的背书签名，每个组织的签名的都是特定的，当背书签名数量不足，视为无效交易。

世界状态数据库选择

  LevelDB是默认的状态数据库，LevelDB是节点内嵌数据库，适合简单的key-value形式的数据。

  当数据为JSON格式时，CouchDB是一个特别合适的选择，因为CouchDB支持富查询。在实现方面，CouchDB在单独的操作系统进程中运行。
关于启用CouchDB参考:Fabric启用CouchDB

通道

  前文我们将账本呈现为一个单一的世界状态和单个区块链，但这还是有点过分简化了。 实际上，每个链码都有自己的世界状态，该世界状态与所有其他链码是分开的。 世界状态位于命名空间（namespace）中，因此只有相同链代码内的智能合约才能访问给定的命名空间。

  在Hyperledger Fabric中，每个通道都有一个完全独立的账本。 这意味着完全独立的区块链，以及完全独立的世界状态，包括名称空间。 应用程序和智能合约可以在通道之间进行通信，以便可以在它们之间访问账本信息。