本文选自新书《区块链核心技术与应用》，略有删节。上一期介绍了超级账本的主要组成部分，这次介绍了共识机制和交易流程。

Fabric的网络节点本质上是相互复制的状态机，节点需要保持相同的账本状态。为了实现这一目标，各节点需蓑衣网小编2022要通过协商一致的流程对账簿状态的变更达成一致。

Fabric的共识过程包括背书、整理、验证三个阶段。

1。背书

在背书阶段，背书节点检查客户端发送的交易计划的合法性，然后模拟执行链代码得到交易结果，最后根据设定的背书逻辑判断是否支持交易计划。如果背书逻辑决定支持交易计划，它将签署该计划并将其发送回客户端。

客户端通常需要根据链码的背书策略向一个或多个成员的背书节点发送背书请求。背书策略将定义需要哪些节点对交易进行背书才能生效，例如至少需要5个成员的3个背书节点同意；或者特殊身份成员的支持等等。只有在客户端收集到满足背书策略的支持后，广播交易才能被视为有效。

2。排序

排序阶段是通过排序服务对交易进行排序，确定交易之间的时序关系。排序服务将一段时间内收到的事务进行排序，然后将排序后的事务打包成数据块(block)，再将块广播给通道中的成员。这样，每个成员以相同的顺序接收一组事务，从而保证了所有节点的数据一致性。

Fabric 1.0中的排序服务支持可插拔架构。除了提供的SOLO和Kafka模式，用户还可以添加第三方排序服务。SOLO是单机确认模式，只适合开发和测试。Kafka mode是基于Kafka开源的分布式数据流平台，具有很高的可扩展性和容错性，适合在生产系统中使用。需要注意的是，卡夫卡只提供CFT式容错，即只能容忍节点的一般故障，而缺乏容忍节点故意邪恶行为的能力。

排序服务是共识机制的重要组成部分。所有的事务只有通过排序服务才能达成全网的共识，所以排序服务要避免成为网络上的性能瓶颈。

3。验证

验证阶段是确认节点对排序后的事务进行一系列测试，包括事务数据的完整性检查、事务是否重复、背书签名是否符合背书策略的要求、事务的读写集合是否满足MVCC(multi version Concurrency Control)的验证。当交易通过所有检查后，将被标记为合法并写入账簿。因为所有的确认节点都是按照相同的顺序核对交易，将合法的交易依次写入账簿，所以它们的状态总能保持一致。

基于上面的共识机制，Fabric的事务流程如下图所示：1)应用端先构造一个事务计划，其作用是调用通道中的链码来读取或写入账簿中的数据。应用程序使用Fabric的SDK封装交易计划，并使用用户的私钥对计划进行签名。

应用程序打包交易计划后，将计划提交给通道中的背书节点。通道的背书策略定义了在交易生效之前哪些节点被背书。应用侧根据背书策略选择相应的背书节点，并向其提交交易计划。

2)背书节点收到交易方案后，首先验证交易的签名是否合法，然后根据签名人的身份确认其是否有权限进行相关交易。此外，背书节点还需要检查交易计划的格式是否正确，以及之前是否提交过(防止重放攻击)。

所有合法性检查通过后，背书节点根据交易计划调用链码。当代码被执行时，r 需要指出的是，背书节点中模拟了链码，即对数据库的写操作不会改变账簿，所有的写操作都会汇总记录在一个写集合中。

链码执行完成后，将返回链码读取的数据集(读集)和链码写入的数据集(写集)。“确认”节点将使用读写集来确定交易是否最终写入分类帐。

3)背书节点对链码模拟后得到的读写集等信息进行签名，并发送给计划提交者(申请端)。

4)应用侧收到背书响应后，检查背书节点的签名是否一致，并比较不同节点的背书结果是否一致。如果计划是查询账簿的请求，应用端不需要向排序节点提交交易。如果是更新账簿的请求，应用端在收集到符合背书策略的背书响应数量后，将背书计划中所有背书节点的读写集、签名、通道号发送给排序节点。

5)排序节点收到各个节点的事务后，并不检查事务的所有内容，而是根据事务中的通道号对事务进行排序，然后将同一通道的事务打包成数据块(blob)。

6)排序节点向信道中的所有成员广播打包的数据块。数据块的广播有两个触发条件，一个是当信道中的事务数达到预设的阈值时，另一个是当事务数没有超过阈值但距离上次广播的时间超过某个阈值时，也可以触发数据块的广播。这两种方法的结合使得排序后的事务能够被及时广播。

7)确认节点收到排序节点发送的交易数据块后，逐个检查块中的交易。检查交易的合法性以及交易是否发生过。然后调用VSCC的系统链码(Validation System Chaincode)检查交易的背书签名是否合法，背书数量是否符合背书策略的要求。

接下来检查多版本并发控制的MVCC，即检查事务的读取集是否与当前账簿中蓑衣网小编2022的版本一致(即没有变化)。如果没有变化，则表示事务写集合中的数据修改有效，将事务标记为有效，并将事务写集合更新到状态数据库。

如果当前账簿数据与读取版本不一致，交易将被标记为无效，状态数据库不会更新。块中的交易数据被标记为“有效”或“无效”，然后打包成块并写入分类账的区块链。

在上述事务处理过程中，采用了MVCC的乐观锁模型，提高了系统的并发性。应该指出，MVCC也带来一些限制。例如，如果同一个块中的两个事务相继更新一个数据项，则后续事务将失败，因为其读取版本与当前数据项版本不一致(因为前一个事务更新了数据)。

(未完待续)

(来源：亨利笔记)