Hyperledger Fabric 账本以及交易流程介绍

Ledger

账本是状态转换的有序的，防篡改的记录。状态转换是参与方提交的链码调用（“交易”）的结果。每笔交易都会产生一组资产键值对，这些键值对在创建，更新或删除时将提交到账本。

账本由 一个链（“ chain”）和一个状态数据库（State Datebase） 组成，该链将不可变的顺序记录存储在块中，并维护一个状态数据库。每个 channel 有一个账本。每个 peer 都为其所加入的每个通道维护一个账本。

Chain

链是一个交易日志，是用 hash 进行链接的块，其中每个块包含N个有序的交易。区块头包括该区块交易的哈希值，以及前一个区块头的哈希值。以这种方式，账本上的所有交易都被排序并通过密码学链接在一起。换句话说，在不破坏哈希链接的情况下，不可能篡改分类账数据。

State Database

状态数据库是另一种表示方法。它表示由链所代表的交易日志产生的当前的 Key-Vaule。因此有时将其称为“世界状态”。这会更加的有效，因为我们不用去顺着链去查一个键值对的整个变更过程了。就像我知道你的工资是多少，而不用去看怎么得出你工资的细则，但你的工资又是由那些细则所决定的。

状态数据库是链中交易日志的所导致的结果，因此可以随时从链中重新生成。状态数据库将在 peer 启动时自动恢复（或根据需要生成）。

状态数据库选项包括 LevelDB 和 CouchDB。默认状态数据库是LevelDB。CouchDB 是可选的，当您的链码数据建模为JSON时，提供富查询功能。有关 CouchDB的更多信息，请参见 CouchDB。

Transaction Flow

1. 生成交易提案

首先由 application client 发送交易提案（ transaction proposal ）到指定的背书节点（endorse peers ）。

2. 背书节点验证提案

验证包括：（1）交易提案的格式是不是正确，（2）这个提案是不是被提交过了，（3）application client 的签名是不是有效的，（4）application client 是不是有权限发起这种类型的交易。满足以上四点后执行第三步。

3. 背书节点模拟交易并背书

根据提案中的参数，背书节点调用链码来模拟交易输出。输出包括一个返回值、读集、写集。背书节点将模拟输出和自己的签名作为 proposal response 返回给 application client。（注意这里只是模拟输出，并没有写入账本）

4. application client 收到提案返回的结果以及后续排序

application client 验证提案返回的结果有没有问题。如果是 query， 到这里就已经拿到结果，整个流程也就结束了。如果是 update， application Client 检查是否满足了背书策略，如果满足就可以把背书结果、交易提案、 Channel ID 整合成一个 transaction message，发送给排序服务。假如没有满足背书策略，即使发送给排序服务了，最后交易也不会被执行，也会被发现的。

5. 排序服务排序

排序服务接受整个网络（ all channel）中的 transaction message。排序服务不会检查 transaction message 的整个文本信息，它只根据 Channel ID 进行分组，打包成块，分发给订阅了排序服务的 peers （leading peers）

6. 节点验证并执行交易

所有节点收到区块后，验证区块中交易的背书是否满足（这也就是为什么第 4 步的不友好行为会被发现），验证自从读集被创建就没有被修改过(因为排序是并行的，验证背书时模拟的交易是有效的，防止双花)。区块中的交易会被 Tag 为有效或无效。

7 . 更新账本

每个节点把区块链接到链上（channel），对于有效的交易会更新世界状态。并且会发送一个消息通知 Client 交易的情况，已上链，有效或无效。

Reference

[1]. Transaction Flow 、 Read-Write Set Semantics 、CouchDB as the State Database
[2]. How does Hyperledger Fabric work?
[3]. 区块链开源实现hyperledger fabric架构详解
[4]. Performance Modeling of Hyperledger Fabric