Fabric2.2中的Raft共识模块源码分析

Python微信订餐小程序课程视频

https://blog.csdn.net/m0_56069948/article/details/122285951

Python实战量化交易理财系统

https://blog.csdn.net/m0_56069948/article/details/122285941

引言

Hyperledger Fabric是当前比较流行的一种联盟链系统，它隶属于Linux基金会在2015年创建的超级账本项目且是这个项目最重要的一个子项目。目前，与Hyperledger的另外几个子项目Hyperledger Iroha，Hyperledger Indy和Hyperledger Sawtooth一样，Hyperledger Fabric正处于生命周期中的活跃（active）阶段，它的架构设计正在不断地完善并持续为开发者和用户提供更强大，更便捷的区块链服务。

与主流的区块链系统一样，Hyperledger Fabric实际上也是个去中心化的分布式账本，其总账上的数据和交易记录由网络中的多方节点共同维护，而且账本上的记录一旦被写入将永远无法被篡改，同时支持基于时间戳的交易追溯。然而，与当前成熟的比特币，以太坊等公有链系统不同的是，Hyperledger Fabric是一种联盟链系统，它的去中心化程度是受限的，即它只允许被授权的节点加入到区块链网络中。更多地，Fabric还提供了创建通道的功能来进一步满足不同联盟方的实际需求，这进一步提高了区块链系统的安全性和私密性。

区块链系统中的交易处理和共识模块是一个核心功能，它们为实现区块链的主体功能发挥了核心作用。在接下来的内容中，为了让读者更好地了解Fabric中的共识模块，我们首先简要介绍了Hyperledger Fabric的架构设计，接着详细分析了Fabric中的交易流程，最后结合Hyperledger Fabric的源码来深入了解Raft共识算法及其在区块链系统中的具体实现。

Hyperledger Fabric架构简介

在Hyperledger Fabric系统的架构中，它引以为豪的一项设计就是采用了模块化的设计思想，并且支持可插拔的组件开发。

具体地，Fabric的架构主要包括三个重要的组成模块，即成员服务，区块链服务以及合约代码服务。以下将详细介绍每个模块包含的功能以及设计原理。

a) 成员服务模块：成员服务之所以会单独划分为一个模块主要是考虑到联盟链的特殊性，即每个节点在进入区块链系统之前都需要经过身份验证，只有通过验证的节点才能参与到系统中。成员服务提供成员的注册，身份管理以及认证功能，保证了系统的安全性，便利了节点的权限管理。

b) 区块链服务模块：无论是在公有链系统还是在联盟链系统，区块链服务始终作为区块链系统的核心组成部分，为区块链主体功能提供底层的服务支撑。具体地，该模块主要承担了节点间的共识管理，账本的分布式存储，去中心化网络协议的具体实现等任务。

c) 合约代码服务模块：该模块也不是Fabric系统独有的，很多系统如以太坊等都具备部署智能合约的功能。在Hyperledger Fabric系统中，智能合约在Docker容器中运行，所以该模块提供了一个智能合约的执行引擎为合约代码程序提供了一个强大，便捷的部署运行环境。

根据以上的模块划分，Fabric的详细架构如下图1.1所示。

图1.1 Hyperledger Fabric架构图

Hyperledger Fabric中的交易流程介绍

在Hyperledger Fabric系统中，所谓的交易就是一次合约代码的调用过程，包含两种类型的交易，即部署交易和调用交易。

部署交易主要用来在Hyperledger Fabric区块链中安装合约代码。具体地，它使用一个程序作为参数创建新的合约代码，然后执行部署以完成合约的安装。而调用交易简单来说就是执行合约代码，当成功地执行调用交易后，可以相应地修改账本的状态，并且为客户端返回输出结果。不管是部署交易还是调用交易，只要在区块链系统中执行后都会被打包成区块，区块链接在一起就组成了分布式账本的区块链。

Hyperledger Fabric区块链系统中，交易主要可以分为三个阶段，分别是提议阶段，排序打包阶段以及验证提交阶段。这里每个阶段参与的节点的类型略有不同，设计到的技术原理也不同。具体地，下图2.1详细地描述了Hyperledger Fabric中的交易流程。

图2.1 Hyperledger Fabric中的交易流程

2.1 提议阶段

在Fabric的第一阶段中，主要的工作流程是客户端节点提交交易提案、背书节点模拟执行链码、背书节点为交易提案进行背书、背书节点返回背书结果给客户端。

具体地，提议阶段主要可以细分为以下几个步骤：

1. 客户端首先构建交易的提案，提案的作用是调用通道中的链码来读取或者将数据写入分布式账本。客户端打包交易提案，并使用用户的私钥对提案进行签名。
2. 应用端打包完交易提案后，便开始把提案提交给通道中的背书节点。通道的背书策略定义了哪些节点背书后交易才能有效，应用端根据背书策略选择相应的背书节点，并向它们提交交易提案。
3. 背书节点收到交易提案后，首先校验交易的签名是否合法，然后根据签名者的身份，确认其是否具有权限进行相关交易。此外，背书节点还需要检查交易提案的格式是否正确以及是否之前提交过，这样做的目的是防止重放攻击。
4. 在所有合法性校验通过后，背书节点按照交易提案，模拟调用链码。链码模拟执行时，读取的键值对数据是节点中本地的状态数据库。需要注意的是，链码在背书节点中是模拟执行，即对数据库的写操作并不会对账本作改变。
5. 在链码模拟执行完成之后，将返回模拟执行的返回值、链码读取过的数据集和链码写入的数据集。读操作集合和写操作集合将在确认节点中用于确定交易是否最终写入账本。
6. 背书节点把链码模拟执行后得到的读写集等信息使用其私钥进行签名（背书签名）后发回给提案提交方即客户端。

图2.2 交易流程之提议阶段

2.2 排序和打包交易阶段

一般地，等客户端收集到足够多的背书节点返回的响应提案的背书响应后，客户端便会将交易提案、读写集和背书签名等发送给排序节点。排序节点将会对自己接收到的交易信息按照通道分类进行排序，且打包成区块。

排序和打包交易阶段可以细分为以下几个子阶段：

1. 客户端收到背书响应之后，检查背书节点的签名和比较不同节点背书的结果是否一致。如果提案是查询账本的请求，则客户端无需提交交易给排序节点。如果是更新账本的请求，客户端在收集到满足背书策略的背书响应数量之后，把背书提案中得到的读写集、所有背书节点的签名和通道号发给排序节点。
2. 排序节点在收到各个节点发来的交易后，并不检查交易的全部内容，而是按照交易中的通道号对交易分类排序，然后把相同通道的一批交易打包成区块。
3. 排序节点把打包好的区块广播给通道中的所有成员。区块的广播有两种触发条件，一种是当通道的交易数量达到某个预设的阈值，另一种是在交易数量没有超过阈值但距离上次广播的时间超过某个特定阈值，也可触发广播数据块。两种方式相结合，使得排序过的交易可以及时广播出去。

图2.3 交易流程之排序和打包区块阶段

2.3 验证和提交阶段

最后，对于验证和提交阶段来说，担负的职责就是验证其收到的区块，即验证区块中的背书签名以及验证交易的有效性。验证成功后，Peer节点将更新账本和世界状态。

验证和提交阶段的详细工作流如下：

1. 节点收到排序节点发来的交易数据块后，逐笔检查区块中的交易。先检查交易的合法性以及该交易是否曾经出现过。然后调用 VSCC（Validation System Chaincode）的系统链码检验交易的背书签名是否合法，以及背书的数量是否满足背书策略的要求。
2. 接下来进行多版本并发控制 MVCC 的检查，即校验交易的读集是否和当前账本中的版本一致。如果没有改变，说明交易写集中对数据的修改有效，把该交易标注为有效，交易的写集更新到状态数据库中。
3. 如果当前账本的数据和读集版本不一致，则该交易被标注为无效，不更新状态数据库。数据块中的交易数据在标注成"有效"或"无效"后封装成区块写入账本的区块链中。
4. 最后，节点会通过事件机制通知客户端交易是否已经被加入区块链以及交易是否有效。

图2.4 交易流程之验证和提交阶段

Hyperledger Fabric中的共识算法及其源码分析

对于Hyperledger Fabric系统来说，前一节分析的整个交易流程就是共识，通过这个交易处理流程，所有的Peer节点在由排序节点提供的流程中对交易的排序和根据交易打包成的区块达成了一致。因此，我们可以知道排序服务是共识机制中最重要的一环，所有的交易都需要通过排序服务后才能达成全网节点的共识。

Hyperledger Fabric 的网络节点本质上是互相复制的状态机，节点之间需要保持相同的账本状态。为了实现这个目的，各个节点需要通过共识过程，对账本状态的变化达成一致性的认同。

如何实现所有节点的共识可以说是去中心化的区块链系统所面临的最重要的问题之一，而共识机制又被称为"区块链的灵魂"。所以，针对不同的区块链系统选择合适的共识算法对于分布式系统保持一致性是至关重要的。

在区块链领域，使用的比较多的共识算法有大名鼎鼎的PoW共识算法，PoS和DPoS等权益证明算法，以及PBFT，RAFT等共识算法。对于Hyperledger Fabric这类联盟链系统，PoW和PoS等算法并不适用，因为这类算法实现共识的本质都是挖矿。虽然这类算法具备完全去中心化和节点自由进出的优点，但是由于挖矿需要耗费大量的电力和CPU资源以及达成共识的周期很长，并不适用于商业的区块链应用。因此，与现在大部分的联盟链系统一样，Hyperledger Fabric也将目光聚集在PBFT和RAFT等共识算法上。

Fabric的共识服务设计成了可插拔的模块，以此满足了根据不同应用场景切换不同共识选项的需求。在Hyperledger Fabric最新版本中，Fabric系统的共识模块中实现了三种共识算法，其中包括Solo，Kafka以及Raft算法。官方推荐的是使用Raft共识算法，但是为了更好地理解Fabric中的共识模块，我们也简单介绍一下Solo和Kafka这两种共识算法。

1. solo共识：假设网络环境中只有一个排序节点，从Peer节点发送来的消息由一个排序节点进行排序和产生区块。由于排序服务只有一个排序节点为所有的peer节点服务，虽然可以肯定保证顺序一致性，但是没有高可用性和可扩展性，所以不适合用于生产环境，只能用于开发和测试环境。
2. Kafka共识：Kafka是一个分布式的流式信息处理平台，目标是为实时数据提供统一的、高吞吐、低延迟的性能。Hyperledger Fabric之前版本的核心共识算法通过Kafka集群实现，简单来说，就是通过Kafka对所有交易信息进行排序（如果系统存在多个通道，则对每个通道分别排序）。
3. Raft共识：Raft是Hyperledger Fabric在1.4.1版本中引入的，它是一种基于 etcd 的崩溃容错（CFT）排序服务。Raft 遵循 “领导者和追随者” 模型，其中领导者在通道中的排序节点之间动态选出（这个节点集合称为"consenter set"），该领导者将消息复制到跟随者节点。Raft保证即使在小部分（≤ (N-1)/2）节点故障的情况下，系统仍然能正常对外提供服务，所以Raft被称为"崩溃容错"。

其实，Hyperledger Fabric在1.4.1版本以前，它的核心共识算法通过Kafka集群实现，但是在1.4.1版本之后，Fabric推荐使用Raft算法实现节点的共识。其实从提供服务的视角来看，基于Raft和Kafka的排序服务是类似的，他们都是基于CFT（crash fault tolerant）模型的排序服务，并且都使用了主从节点的设置。但是为什么Hyperledger Fabric选择Raft算法呢？我们列举了Raft相较于Kafka所展现出的优势来回答这个问题。

a. 第一点，Raft 更容易设置。虽然 Kafka 有很多崇拜者，但即使是那些崇拜者也（通常）会承认部署 Kafka 集群及其所必须的 ZooKeeper 集群会很棘手，需要在 Kafka 基础设施和设置方面拥有高水平的专业知识。此外，使用 Kafka 管理的组件比使用 Raft 管理的组件多，Kafka 有自己的版本，必须与排序节点协调。而使用 Raft，所有内容都会嵌入到排序节点中。

b. 第二点，Kafka和zookeeper的设计不适用于大型网络。它们的设计是CFT模型，但局限于运行的比较紧密的主机上。也就是说，需要有一个组织专门运行Kafka集群。鉴于此，当有多个组织使用基于Kafka排序服务的时候，其实没有实现去中心化，因为所有的节点连接的都是由一个组织单独控制的Kafka集群。如果使用Raft算法，每个组织可以贡献排序节点，共同组成排序服务，可以更好的去中心化。

c. 第三点，Raft是原生支持的，而Kafka需要经过复杂的步骤部署，并且需要单独学习成本。而且Kafka和Zookeeper的支持相关的issue要通过apache来处理，而不是Hyperledger Fabric。Raft的实现是包含在Fabric社区的，开发支持更加便利。

d. 第四点，Raft 是向开发拜占庭容错（BFT）排序服务迈出的第一步。正如我们将看到的，Fabric