Hyperledger Fabric
Table of Contents
1. Hyperledger Fabric
Hyperledger Fabric 是一个开源的“分布式账本”实现，主要由 IBM 开发主导。
下面是它的一些主要概念：
- Chaincode: Chaincode is software that encodes key value pairs or text-based data (JSON) and transaction instructions for modifying this information.
- Smart contract: 就是上面介绍的 chaincode。
- Channel: A Channel is formed as an offshoot of the system chain; and best thought of as a “topic” for peers to subscribe to, or rather, a subset of a broader blockchain network. A peer may subscribe on various channels and can only access the transactions on the subscribed channels. Each channel has a unique ledger, thus accommodating confidentiality and execution of multilateral contracts. 一个 blockchain 系统可以支持多个无关的子系统，如一个用于记录用户的房屋交易信息，一个用于记录用户的汽车交易信息，这就是两个 Channel，它们之间相互独立，每个 Channel 对应一个不同的总账簿（Ledger）。
- Peer: 存放区块链数据的结点，它同时有 endorse 和 commit 功能。
- Orderer: 用于对交易进行排序。如果一个 Channel 中，“同时”发起了两个交易，按照什么顺序把它们放入到 Blockchain 系统中呢？这就需要先排序了。如果系统中只一个 Orderer 结点，则实现可以很简单，比如先收到哪个交易就把该交易放前面（solo 模式）；如果系统中有多个 Orderer 结点，则相对麻烦一些，可以借助 kafka 等分布式队列工具来进行排序（kafka 模式），都往同一个队列（一个 Channel 对应一个队列）中写，读出来的顺序自然就是排序后的顺序。
1.1. Transaction lifecycle in v1.0 of Hyperledger Fabric
Fabric 1.0 中 Transaction 的流程如图 1 和图 2 所示。
Figure 1: Transaction lifecycle in v1.0 of Hyperledger Fabric
图 1 摘自：https://developer.ibm.com/articles/top-technical-advantages-of-hyperledger-fabric-for-blockchain-networks/
Figure 2: Illustration of one possible transaction flow (common-case path)
图 2 摘自：https://hyperledger-fabric.readthedocs.io/en/release-1.1/arch-deep-dive.html#the-ordering-service-delivers-a-transactions-to-the-peers
1.1.1. MVCC
只有“Endorsing peer”会真正执行 chaincode，执行后得到读写集（“Read-Write set”）：即这个 chaincode 读取了哪些 key-value 对，修改了哪些 key-value 对。对于得到的读集（“Read set”），我们需要同时记录下它们值的版本，真正提交交易前检测一下这些值的版本是否和之前记下的版本相同，如果不相同（可能被其它交易修改了），则交易失败，返回错误“MVCC_READ_CONFLICT”。
MVCC 处理并发的好处：读操作是不加锁的（会记下所读值当前的版本号），所以不会阻塞写操作。
2. Hyperledger Fabric Consensus
2.1. 区块链中的共识算法
在区块链实践中，Block 一个接一个地连在一起（当前 Block 引用着前一个 Block 的 Hash 值），为了确保链是唯一的，我们需要寻找一种机制来确定由谁创建 Block，这就是“共识算法”。在比特币中，谁先挖矿成功，谁就创建 Block，这种共识算法被称为 POW(Proof-of-Work)。 在 Hyperledger Fabric 中，通过 Orderer 节点来实现共识，它利用了 Kafka 分布式消息队列的功能，其基本原理是大家把 Transaction 发送到 Kafka 的同一个 Topic 中，从 Topic 中读出来后自然就是有序的了，再组装为一个个 Block 即可。
2.2. Orderer 源码分析
可以认为 Orderer 就 3 个线程（当然这是不准确的，这种简化不影响核心问题的描述）：一个线程实现 Broadcast 这个 gRPC service（接收 Peer 发来的 Transaction，并发送到 Kafka 中）；另一个线程从 Kafka 中取 Transaction，并封装为一个个 Block；第三个线程实现 Deliver 这个 gRPC service（发送 Block 给 Peer）。整个过程如图 3 所示（图片摘自https://github.com/yeasy/hyperledger_code_fabric/blob/master/process/orderer_workflow.md）。
Figure 3: Orderer 提供的服务
笔者基于 Hyperledger Fabric 1.1 源码，总结了 Orderer 节点的主要代码执行流程，如图 4 所示。
Figure 4: Hyperledger Fabric Order 源码流程（基于 git 分支 release-1.1）