《Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains》是EuroSys 2018一篇关于Fabric网络框架的论文，这也是我看过Hyperledger Fabric最好的入门资料之一，下面我就整理下这篇论文的要点以及加上我自己的一些理解。

1 引言

区块链可以定义为用于记录交易的不可变账本，维护在相互不信任的节点的分布式网络中。

Fabric 属于联盟链中的一种，是一个模块化和可扩展的开源系统，用于部署和操作许可的区块链，也是 Linux 基金会 (www.hyperledger.org) 托管的 Hyperledger 项目之一。

1.1 传统区块链框架

1.1.1 order-execute框架

许多现有的智能合约区块链都遵循顺序执行架构

对交易进行排序后并将其传播给所有peer节点；其次，每个peer节点按顺序执行事务。我们称之为顺序执行架构；它要求所有节点执行每笔交易，并且所有交易都是确定性的。
顺序执行架构几乎可以在所有现有的区块链系统中找到，

以太坊为例，太坊组合了共识和执行

Step1：一个节点参与了共识，执行了区块中的合法交易；
Step2：这个节点通过挖矿，获得了记账权，并通过gossip协议向整个网络广播该区块；
Step3：其他节点收到区块后会校验该节点是否获得记账权，以及区块中所有的交易。每个节点因此从第一步开始，重复执行获得记账权的节点所做的事情。

1.1.2 order-execute执行框架弊端

1. 所有节点按顺序执行所有交易会限制性能，一方面，对等点上按顺序执行交易限制了区块链可以实现的有效吞吐量。除此之外，顺序-执行框架还可能会由于受到拒绝服务攻击（DOS）而极大降低区链性能。还是以太坊为例，所有人都可以部署智能合约，当时这个时候如果引入了恶意的合约，执行起来需要花费很多时间，就会极大的降低区块链的性能，这种恶意行为也就是DOS（denial of service）攻击。

2. 在共识完之后，账本的复制，所有节点状态需要保持一致性，这通常通过领域特定语言来解决（以太坊），不如通用的编程语言方便，但是如果使用通用编程语言就无法确保操作的确定性。

3. 许多联盟链的系统将智能合约运行在所有节点上。但是，许多联盟链中智能合约逻辑、交易数据、账本等需要保密。而在frabic中，链码仅由背书节点调用，且不同通道的账本是不共享的。

1.2、Frabic改进

1.2.1采用的execute-order-validate框架

Fabric 引入了一种新的区块链架构执行-排序-检验（execute-order-validate），**在这个框架下，
execute-order-validate执行框架结合了主动复制和被动复制两种复制方法。

Step1： 每客户端发送交易到背书策略指定的peer节点（背书节点），背书节点先调用链码执行交易，同时结果被记录，这个过程也被称为背书。背书策略会指定背书节点的执行策略.

Step2： Fabric包括了主动复制，在背书节点执行完交易提案后，交易进入排序阶段，排序好的交易被打包进区块。在校验阶段，order节点将排序后的打包好的区块借助Gossip协议广播发送给记账节点，其对区块信息进行验证，记账节点在校验背书交易的状态变化以及执行的一致性。

3 Fabric网络中Node的组成

一个Fabric区块链系统由一系列的node组成一个网络。所有参与网络的节点都带有身份，该身份由模块化的成员服务提供者（MSP）提供。

Fabric网络中node主要有以下三种：

1、客户端（Client）：
客户端主要有两个功能，一个是向peer节点中的背书节点提交交易提案，另一个是是将背书节点执行后的交易广播给排序节点。

2、排序服务节点（Oederer or Ordering Service Nodes (OSN)）
排序服务节点接收包含背书签名的交易，对未打包的交易进行排序生成区块，广播给Peer节点。

3、Peers 节点
Fabric中的Peer节点有四种，分给是Endorser Peer（背书节点）、Leader Peer（主节点）、Committer Peer（记账节点）、Anchor Peer（锚节点）。背书节点主要负责调用链码执行交易提案，然后记账节点负责验证排序服务节点打包好的交易区块，并写入账本，所有的节点都持有完整的账本，锚节点可实现不同组织间的通信， 主节点负责和排序服务节点通信，获取最新的区块并在组织内部同步。

4 Fabric网络交易流程

Fabric网络已经支持多链机制，支持多条链连接到排序服务。每个区块链叫做通道（Channel），并且拥有不同的节点作为成员，每个channel是相对于其他channel独立的。所有的部署都认为所有的orderer是可信的，一个通道的交易流程如图所示

4.1执行阶段（Execution Phase）

执行阶段也可以细分为三步：
Step1： 客户端构造交易提案
客户端应用程序利用SDK构造交易提案，并将交易提案发送给一个或多个背书节点，交易提案中包含本次交易要调用的合约标识、合约方法和参数信息以及客户端签名等
Step2：背书节点模拟执行交易

背书节点收到交易提案后，验证签名并确定提交者是否有权执行操作。首先校验交易的签名是否合法，然后根据签名者的身份，确认其是否具有权限进行相关交易。此外，背书节点还需要检查交易提案的格式是否正确以及是否已经提交过（防止重放攻击）。

在所有合法性校验通过后，背书节点按照交易提案调用链码模拟执行交易。

链码执行时，读取的数据（键值对）是背书节点中本地的状态数据库，链码读取过的数据回被归总到读集（Read Set）；链码对状态数据库的写操作并不会对账本做改变，所有的写操作将归总到一个写入集（Write Set）中记录下来。读集和写集将在确认节点中用于确定交易是否最终写入账本。

Step3：背书节点将背书结果返回给客户端

在链码执行完成后，背书节点把链码模拟执行后得到的反馈值、读写集（Read-Write Set）、背书节点签名、是否背书声明作为交易提案反馈回传给客户端。

此时，交易信息只在客户端和单个背书节点之间达成共识，并没有完成全网共识，各个客户端的交易顺序没有确定，可能存在双花问题，所以不是一个有效交易。同时，客户端需要收到大多数背书节点的验证回复后，才算验证成功，具体的背书策略由智能合约代码控制，可以由开发者自由配置

4.2 排序阶段（Ordering Phase）

当客户端在提案上收集了足够多的背书节点返回的交易提案时，客户端会将交易的有效负载（例如链码的相关参数等）、交易元数据、一些列背书提交给排序服务。

排序服务节点对每个通道上的交易进行排序，并打包进区块

排序服务节点利用Fabric内置的Gossip服务将所交付的块从排序服务广播到所有记账节点上。【Gossip的实现是可扩展的，并且与排序服务的特定实现无关，因此它适用于CFT和BFT订购服务，确保了Fabric的模块化】

值得注意的是，这个地方的peer节点不仅是背书节点也是记账节点

4.3 验证阶段（Validation Phase）

Step1： 记账节点收到排序服务节点发来的区块后，逐笔检查区块中的交易。先检查交易的合法性以及该交易是否曾经出现过。然后调用校验系统链码（VSCC，Validation System Chaincode）检验交易的签名背书是否合法，以及背书的数量是否满足背书策略的要求。。
【如果校验不满意，则交易被标记为无效，其影响将被忽略。】

Step2： 按顺序对块中的所有交易进行读写冲突检查。对于每个交易，记账节点对交易进行多版本并发控制（MVCC）检查，即校验交易的读集（Read Set）是否和当前账本中的版本一致（即没有变化）。如果没有改变，说明交易写集（Write Set）中对数据的修改有效。

Step3： 最后更新账本，其中块附加到本地存储的分类帐，并更新区块链状态。

特别是，当将块添加到帐本时，前两个步骤中的有效性检查结果也会以位掩码的形式保留，表示块内有效的交易。区块中的交易数据在标注成有效或无效后封装成区块写入账本的区块链中，并修改K-V状态数据库

5 Fabric组件

5.1 成员服务（Membership Service）

成员服务提供者（MSP）维护系统中所有节点的标识（客户端，Peer节点和排序服务节点），并负责颁发用于身份验证和授权的节点凭据。由于加入Fabric网络是需要进过许可的，因此节点之间的所有交互都通过经过身份验证的消息进行，通常使用数字签名。会员服务包括每个节点的组件，可以在其中验证交易，验证交易的完整性，签署认可，验证认可以及验证其他区块链操作。用于密钥管理和节点注册的工具也是MSP的一部分。

MSP 是一种抽象，可以对其进行不同的实例化。Fabric 中的默认 MSP 实现处理基于数字签名的标准 PKI 身份验证方法，并且可以适应商业证书颁发机构 (CA)。Fabric 还提供了一个独立的 CA，称为 Fabric-CA。此外，设想了替代的 MSP 实现，例如依赖匿名凭证来授权客户端调用事务而不将其链接到身份 。

Fabric 允许两种模式来建立区块链网络。在离线模式下，证书由 CA 生成并带外分发到所有节点。Peers 和 orderer 只能在离线模式下注册。对于注册客户端，Fabric-CA 提供了一种在线模式，向他们颁发加密凭证。MSP 配置必须确保所有节点，尤其是所有对等节点，都将相同的身份和身份验证识别为有效。

**MSP允许身份联合，**例如，当多个组织运行区块链网络时。每个组织都向自己的成员发放身份，每个peer节点都认可所有组织的成员。这可以通过多个MSP实例来实现，例如，通过在每个组织和MSP之间创建映射。

5.2 排序服务（Ordering Service）

排序服务管理多个通道。在每个通道，它提供一下服务：

1. 原子广播， 用于建立交易顺序、实现广播和传递调用
2. 通道的重新配置， 当其成员通过广播配置更新事务来修改通道时
3. 可选地，在排序服务充当可信实体的那些配置中，可以限制向特定的客户端和Peer节点广播交易。

排序服务节点，直接将新接收的交易注入原子广播（例如，向Kafka broker）。 并对从原子广播接收到的事务进行批处理并形成块。只要满足以下三个条件之一，就会组装成一个块：

1. 该块包含指定的最大交易数量;
2. 块已达到最大大小（以字节为单位）;
3. 自收到新区块的第一次交易以来已经过的时间量，如下所述。

5.3 Peer Gossip

排序和验证分离执行的一个优点是他们可以独立扩展。但是，由于大多数一致性算法（在CFT和BFT模型中）都是带宽限制的，因此排序服务的吞吐量受其节点的网络容量限制。通过添加更多节点无法扩大共识[14,36]，相反，吞吐量会降低。

Gossip组件利用多播，将order节点排序后的结果有效地广播到所有记账节点以进行验证。

用于Gossip的通信层基于gRPC并且利用具有相互认证的TLS，这使得每一方能够将TLS凭证绑定到远程Peer的身份。Gossip组件维护系统中在线Peer的最新成员视图。所有Peer独立地从定期传播的成员资格数据构建本地视图。此外，在崩溃或网络中断后，节点可以重新连接到视图。

Fabric gossip 使用两个阶段进行信息传播：

1. 在 push 期间，每个 peer 从成员视图中随机选择一组活跃的peer节点，并将消息转发给他们；
2. 在pull期间，每个对等点定期探测一组随机选择的peer节点并请求丢失的消息。

5.4 账本（Ledger）

ledger由两部分组成：世界状态（world state）和区块链（blockchain）

区块链是一组不可更改的有序的数据块，记录着全部交易的日志。每个区块中包含若干个交易的数据，不同区块所包含的交易数量可以不同。区块之间用哈希链关联，每个区块头包含本区块所有交易的哈希值，以及上一个区块头的哈希值。

【链式结构可以确保每个区块的数据不可更改，以及每个区块之间的顺序关系不可更改。因此，区块链的区块只可以添加在链的尾部。】

世界状态库记录了账本中最近交易的状态，相当于对当前账本的交易日志做了索引。链码执行交易的时候需要读取账本的当前状态，从状态数据库可以迅速获取键值的最新状态，其存储引擎为KV数据库，默认LevelDB。

【如果没有状态数据库，要获得某个键值时，需要遍历整个区块链中和该键值相关的交易，效率非常低，因此，读取状态数据库可以认为是快速定位和访问某个键值的方法。另外，当状态数据库出现故障的时候，可以通过遍历账本重新生成。】

【当一个区块附加到区块链尾部的时候，如果区块中的有效交易修改了键值对，则会在状态数据库中作相应的更新，确保区块链和状态数据库始终保持一致。
区块链的数据块以文件形式保存在各个节点中。状态数据库可以是各种键值数据库，Fabric缺省使用LevelDB ，同时支持CouchDB选项。CouchDB除了支持键值数据外，也支持JSON格式的文档模型，能够做复杂的查询。】

5.5 链码执行（Chaincode Execution）

Fabric的智能合约（Smart Contract）称为链码（ChainCode），背书节点通过执行链码来模拟执行交易，实现基于区块链的智能合约业务逻辑。

只有智能合约才能更新账本数据，其它模块不能直接修改状态数据。链码被编译成一个独立的应用程序，Fabric用Docker容器来运行链码，该环境将链代码彼此隔离，并与节点代码隔离。

5.6 配置与系统链码

Fabric的基本行为是通过通道配置和特殊链码（称为系统链码）组成的。

渠道配置。回想一下，一个通道形成一个逻辑区块链。通道的配置保存在特殊配置块中的元数据中。每个配置块包含完整的通道配置，不包含任何其他交易。每个区块链都以一个称为创世块的配置块开始，该块用于引导通道。渠道配置包括：

1. 参与节点的MSP定义。
2. OSN的网络地址。
3. 共识实现和排序服务的共享配置，例如批量大小和超时。
4. 管理排序服务操作（广播和交付）访问的规则。
5. 可以修改管理通道配置的每个部分的规则。

可以使用通道配置更新事务来更新信道的配置。此事务包含对配置所做更改的表示，以及一组签名。订购服务节点通过使用当前配置来验证更新是否有效，以验证使用签名授权修改。然后，排序者生成一个新的配置块，它嵌入了新的配置和配置更新交易。接收此块的节点根据当前配置验证配置更新是否被授权;如果有效，他们会更新当前的配置。

系统链代码。部署应用程序链代码时引用了认可系统链代码（ESCC）和验证系统链代码（VSCC）。以对称方式选择这两个链代码，使得ESCC的输出（认可）可以被验证为VSCC的输入的一部分。

ESCC将提案和提案模拟结果作为输入。如果结果令人满意，那么ESCC会产生一个包含结果和认可的回复。对于默认的ESCC，此认可只是对等方本地签名身份的签名。

VSCC将事务作为输入，并输出该事务是否有效。对于默认的VSCC，将根据为链代码指定的认可政策收集和评估认可。

其他系统链代码实现其他支持功能，例如配置和链代码生命周期。

6 实验评估

为了测试，Fabric仿照比特币UTXO模型设计了一种代币，简称Fabcoin。通过一个chaincode不断产生SPEND和MINT transactions，分别模拟Fabcoin的产生和销毁。

实验 1（选择块大小）：

第一个实验是，研究区块大小与Peer节点测的峰值吞吐量以及相应的平均端到端 (e2e) 时延，随着区块从 0.5MB（兆字节） 增加到 4MB ，吞吐量和平均时延如下

在这个实验中，铸币的平均交易大小要大于花费交易。因为铸币带有 CB 证书。CB包含实体的标识符与硬币状态。
【特别是，2MB 块包含 473 笔铸币或 670 笔花费交易，即平均交易大小为 3.06kB SPEND和 4.33kB MINT】

超过 2MB 的块大小后吞吐量并没有显着提高，但时延变大。

实验2（节点的CPU 的影响）

以 2MB 作为实验的块大小，估计节点的CPU 性能对吞吐量的影响，4 个对等点在 4、8、16 和 32 个 vCPU 虚拟机上运行

左边的图是铸币的吞吐量和时延的情况，右边的图是花费的情况。

1. 铸币和花费的吞吐量都随着CPU线程数量增加而增大，

2. Fabcoin VSCC 的验证性能与 CPU 线性扩展，因为 Fabric 的 VSCC 的背书策略验证是的并行。

3. 但是，读写检查和帐本访问阶段是串行的，所以时延不会随着CUP内核增加，而降低。

实验3（按阶段进行延迟分析）

【配置：32CPU、2MB区块】

在我们之前的实验中，我们在报告的峰值吞吐量处进一步对延迟进行分析。
第一列是平均延时，第二列是标准差，第三列是 尾部延时，99%的意思是99%的交易完成的时间，第四列是99.9%的交易完成的时间，我们观察到排序主导了整体延迟。 我们还看到平均延迟低于 550 毫秒。

实验 4（SSD 与 RAM 磁盘）

【实验条件：16-vCPU VMs running Ubuntu with 8GB】

第四个实验是RAM 磁盘 (tmpfs) 和SSD分别作为稳定存储单元时，性能的对比。在 32-vCPU 上测量得到花费的持续峰值吞吐量为 3870tps ，比 SSD 提高了大约 9%。

实验 5（LAN 上的可扩展性）

【实验条件：16 vCPUs】

增加了对等点的peer节点的数量来评估 Fabric 的可扩展性。

在这个实验里面， 所有peer节点都直接从排序服务接收块，而无需Gossip协议。 我们从 20 个peer节点（其中 10 个是 Fabcoin 背书者）开始，逐渐增加到 100 个。这个图描绘了峰值吞吐量与对peer节点数量的函数关系。

在局域网里面，网络带宽大概为 5-6.5Gbps，所以这种情况下，网络带宽不是吞吐量的瓶颈，所以在这种情况下，随着peer节点的增加，Kafka 排序服务可以很好地处理增加的peer节点，所以随着peer节点的拓展，吞吐量基本不变。

但是当排序节点部署在香港的时候，需要通过广域网连接，网络带宽下降，如果不采用gossip广播协议，随着节点的增加会不断加剧排序服务节点的负担，所以在广域网中，随着Peer节点的增加，吞吐量会下降。

实验 6（多个数据中心 (WAN) 上的性能）

最后一个实验是将数据中心拓展到五个不同的地方，分别是东京（TK）、香港（HK）、墨尔本（ML）、悉尼（SD）和奥斯陆（OS）。每个数据中心有 20 个peer节点，总计 100 个 peer节点。

将排序服务节点部署在东京，【ordering service，10个endorsers，所有clients都在TK中。】

对比有无gossip的吞吐量

表格的第一行显示了给定数据中心中的虚拟机与 TK 之间的 netperf 吞吐量。

在广域网上，由于网络带宽相对于局域网较低，如果不采用goosip广播协议，peer节点需要直接连接部署在东京的排序服务节点，相对于使用gossip协议，吞吐量会降低