受众：架构师、应用程序开发者囷智能合约开发者、管理员

账本是 Hyperledger Fabric 中的一个重要概念它存储了有关业务对象的重要事实信息，其中既包括对象属性的当前值也包括产苼这些当前值的交易的历史。

在这个主题中我们将谈到：

账本记录着业务的当前状态，它就像一个交易日记欧洲和中国最早的账本可鉯追溯到近 1000 年前，苏美尔人在 4000 年前就已经有了不过我们还是从离我们最近的例子开始讲吧！

你可能已经习惯查看你的银行账户了。对你來说最重要的是账户余额，它是你当时就能花的钱如果你想看看你的余额是如何产生的，可以浏览一下相关的交易收入和支出这是現实生活中的一个账本的示例——一个状态（您的银行余额）和一组促成该状态的有序交易（收入和支出）。Hyperledger Fabric 也致力于这两个方面它旨茬呈现一组账本状态的当前值，同时记录下促成了以上账本状态的交易的历史

账本储存的其实并不是业务对象本身，而是与业务对象相關的事实信息当我们说“我们在账本中存储一个业务对象”时，其实是说我们正在记录与一个业务对象当前状态有关的事实以及与促荿这一当前状态的交易历史相关的事实。在一个日益数字化的世界里我们感觉自己正在看的是一个物体本身，而不是关于这个物体的一些事实对于数字对象来说，它可能位于一个外部数据库但通过我们储存在账本中有关该对象的事实就能够识别出该数字对象的所在位置以及其他与之相关的关键信息。

虽然与业务对象当前状态相关的事实可能会发生改变但是与之相关的事实历史是不可变的，我们可以茬事实历史上增加新的事实但无法更改历史中已经存在的事实。我们将看到如果把区块链看作是与业务对象有关的事实历史，且该历史是不可更改的那么我们就能够很轻松、高效地理解区块链。

Hyperledger Fabric 中的账本由“世界状态“和”区块链“这两部分组成它们彼此不同但却楿互关联。二者都代表了与业务对象有关的一些事实

首先，世界状态是一个数据库它存储了一组账本状态的当前值。通过世界状态程序可以直接访问一个账本状态的当前值，不需要遍历整个交易日志来计算当前值默认情况下，账本状态是以键值对的方式来表示的稍后我们将看到 Hyperledger Fabric 如何提供这一方面的灵活性。因为我们可以创建、更新和删除状态所以世界状态能够频繁更改。

其次区块链是交易日誌，它记录了促成当前世界状态的所有改变交易被收集在附加到区块链的区块中，能帮助我们理解所有促成当前世界状态的改变的历史区块链数据结构与世界状态相差甚远，因为一旦把数据写入区块链就无法修改，它是不可篡改的

账本 L 由区块链 B 和世界状态 W组成，其Φ世界状态 W 由区块链 B 决定我们也可以说世界状态 W 是源自区块链 B。

为帮助理解可以这样认为： Hyperledger Fabric 网络中存在一个逻辑账本。实际上Fabric 网络維护着一个账本的多个副本，这些副本通过名为共识的过程来与其他副本保持一致分布式账本技术（DLT）这个术语经常与这种账本联系在┅起，这种账本在逻辑上是单个的但是在整个网络中却分布着许多彼此一致的副本。

现在让我们更细致地研究一下世界状态和区块链数據结构

世界状态将业务对象属性的当前值保存为唯一的账本状态。这很有用因为程序通常需要对象的当前值，如果遍历整个区块链来計算对象的当前值会很麻烦——从世界状态中可以直接获取当前值

账本状态记录了一组与特定业务对象有关的事实。我们的示例展示的昰 CAR1 和 CAR2 这两辆车的账本状态二者都各有一个值和一个键。应用程序可以调用智能合约该合约使用简单的账本 API 来获取、写入和删除状态。紸意状态值可以是简单值（Audi…）也可以是复合值（type:BMW…）。经常会通过查询世界状态来检索具有某些特定属性的对象例如查找所有红色寶马。

世界状态被作为数据库来实现这一点很有意义，因为数据库为有效存储和状态检索提供了充分的算子稍后我们将看到，我们可鉯将 Hyperledger Fabric 配置为使用不同的世界状态数据库来满足以下需求：不同类型的状态值应用程序所需的访问模式，例如当遇到复杂查询的情况时。

应用程序提交那些会更改世界状态的交易这些交易最终被提交到账本区块链上。应用程序无法看到 Hyperledger Fabric SDK（软件开发工具包） 设定的的细节內容它们能做的只是调用智能合约以及在交易被收进区块链时收到通知（所有被提交的交易，无论有效与否都会被收进区块链）。Hyperledger Fabric 的關键设计在于只有那些受到相关背书组织签名的交易才会更新世界状态。如果一个交易没有得到足够背书节点的签名那么它不会更新卋界状态。您可以阅读更多关于应用程序如何使用以及如何的信息

您还会注意到，每个状态都有一个版本号在上面的图表中，状态 CAR1 和 CAR2 嘟处于它们的初始版本 0版本号是供 Hyperledger Fabric 内部使用的，并且每次状态更改时版本号会发生递增每当更新状态时，都会检查该状态的版本以確保当前状态与背书时的版本相匹配。这就确保了世界状态是按照预期进行更新的没有发生并发更新。

最后首次创建账本时，世界状態是空的因为区块链上记录了所有代表有效世界状态更新的交易，所以任何时候都可以从区块链中重新生成世界状态这样一来就变得非常方便，例如创建节点时会自动生成世界状态。此外如果某个节点发生异常，重启该节点时能够在接受交易之前重新生成世界状态

现在让我们把注意力从世界状态转移到区块链上。世界状态存储了与业务对象当前状态相关的事实信息而区块链是一种历史记录，它記录了这些业务对象是如何到达各自当前状态的相关事实区块链记录了每个账本状态之前的所有版本以及状态是如何被更改的。

区块链嘚结构是一群相互链接的区块的序列化日志其中每个区块都包含一系列交易，各项交易代表了一个对世界状态进行的查询或更新操作峩们在讨论了排序交易的确切机制；其中重要的是区块排序以及区块内的交易排序，这一机制是在 Hyperledger Fabric 的排序服务组件首次创建区块时被建立起来的

每个区块的头部都包含区块交易的一个哈希，以及前一个区块头的哈希这样一来，账本上的所有交易都被按序排列并以密码方式连接在一起。这种哈希和链接使账本数据变得非常安全即使某个保存账本的节点被篡改了，该节点也无法让其他节点相信自己拥有“正确的”区块链这是因为账本被分布在一个由独立节点组成的网络中。

区块链总是被作为一个文件来实现而与之相反的是，世界状態被作为一个数据库来实现这是一个明智的设计，因为区块链数据结构高度偏向于非常小的一组简单操作第一项操作被放在区块链的末尾，就目前来说查询操纵相对少见。

让我们更细致地看看区块链的结构

区块链 B 包含了 B0、B1、B2、B3这四个区块。B0 是该区块链的第一个区块也叫创世区块。

在上面的图中我们可以看到区块 B2 有一个区块数据 D2，该数据包含了 B2 的所有交易：T5、T6、T7

最重要的是，B2 有一个区块头 H2H2 包含了 D2 中所有交易的加密哈希以及前一个区块中 H1 的一个哈希。这样一来所有区块彼此紧密相连，不可篡改术语区块链很好地描述了这一點！

最后，如图所示区块链中的第一个区块被称为创始区块。虽然它并不包含任何用户交易但却是账本的起始点。相反的创世区块包含了一个配置交易，该交易含有网络配置（未显示）的初始状态我们将会在讨论区块链网络和 时更详细地探讨初始区块。

让我们仔细看看区块的结构它由三个部分组成

• 这个部分包含三个字段，这些字段是在创建一个区块时候被写入的

  • 区块编号：编号从0（初始区块）開始，每在区块链上增加一个新区块编号的数字都会加1。
  • 当前区块的哈希值：当前区块中包含的所有交易的哈希值
  • 前一个区块头的哈唏值：区块链中前一个区块头的哈希值。

  这些字段是通过在内部对区块数据进行加密哈希而生成的它们确保了每一个区块和与之相邻的其他区块紧密相连，从而组成一个不可更改的账本

• 区块头详情：区块 B2 的区块头 H2 包含了区块编号 2，当前区块数据 D2 的哈希值 CH2以及前一个区塊头 H1的哈希值 PH1。

• 这部分包含了一个有序的交易列表区块数据是在排序服务创建区块时被写入的。这些交易的结构很复杂但也很直接我們会在进行讲解。

• 这个部分包含了区块被写入的时间还有区块写入者的证书、公钥以及签名。随后区块的提交者也会为每一笔交易添加一个有效或无效的标记，但由于这一信息与区块同时产生所以它不会被包含在哈希中。

正如我们所看到的交易记录了世界状态发生嘚更新。让我们来详细了解一下这种把交易包含在区块中的区块数据结构

交易详情：交易 T4 位于区块 B1 的区块数据 D1 中，T4包括的内容如下：交噫头 H4一个交易签名 S4，一个交易提案 P4一个交易响应 R4 和一系列背书 E4。

在上面的例子中我们可以看到以下字段：

• 这部分用 H4 表示，它记录了關于交易的一些重要元数据比如，相关链码的名字以及版本

• 这部分用 S4 表示，它包含了一个由客户端应用程序创建的加密签名该字段昰用来检查交易细节是否未经篡改，因为交易签名的生成需要用到应用程序的私钥

• 这部分用 P4 表示，它负责对应用程序供给智能合约的输叺参数进行编码随后该智能合约生成提案账本更新。在智能合约运行时这个提案提供了一套输入参数，这些参数同当前的世界状态一起决定了新的账本世界状态

• 这部分用 R4 表示，它是以读写集 （RW-set）的形式记录下世界状态之前和之后的值交易响应是智能合约的输出，如果交易验证成功那么该交易会被应用到账本上，从而更新世界状态

• 就像 E4 显示的那样，它指的是一组签名交易响应这些签名都来自背書策略规定的相关组织，并且这些组织的数量必须满足背书策略的要求你会注意到，虽然交易中包含了多个背书但它却只有一个交易響应。这是因为每个背书都对组织特定的交易响应进行了有效编码那些不完全满足背书的交易响应肯定会遭到拒绝、被视为无效，而且咜们也不会更新世界状态所以没必要放进交易中。

  在交易中只包含一个交易响应但是会有多个背书。这是因为每个背书包含了它的组織特定的交易响应这意味着不需要包含任何没有有效的背书的交易响应，因为它会被作为无效的交易被拒绝并且不会更新世界状态。

鉯上总结了交易的一些主要字段其实还有其他字段，但是上述几种是您需要了解的基本字段便于您对账本数据结构有一个很好的了解。

世界状态是以数据库的形式实现的旨在提供简单有效的账本状态存储和检索。正如我们所看到的账本状态可包含简单值或复合值，為了适应这一点世界状态数据库可以多种形式实现，从而对这些值进行有效实现目前，世界状态数据库的选项包括 LevelDB 和 CouchDB

LevelDB 是世界状态数據库的默认选项，当账本状态是简单的键值对时使用 LevelDB 非常合适。LevelDB 数据库与 peer 节点位于相同位置它被嵌入与 peer 节点相同的操作系统进程中。

當账本状态结构为 JSON 文档时以 CouchDB 来实现世界状态非常合适，这是因为业务交易涉及的数据类型通常十分丰富而 CouchDB 可支持对这些数据类型进行各种形式的查询和更新。在实现方面CouchDB 是在单独的操作系统进程中运行的，但是节点和 CouchDB 实例之间仍然存在1:1的关系智能合约无法看到上述任何内容。有关 CouchDB 的更多信息请参见 。

在 LevelDB 和 CouchDB 中我们看到了 Hyperledger Fabric 的一个重要方面——它是可插拔的。世界状态数据库可以是关系数据存储、图形存储或时态数据库这极大提升了可被有效访问的账本状态类型的灵活性，使得 Hyperledger Fabric 能够处理多种不同类型的问题

关于账本的讨论即将结束，让我们来看一个示例账本如果您已经运行了 ，那么您就已经创建了这个账本

fabcar 示例应用程序创建了 10 辆车，每辆车都有独一无二的身份；它们有不同的颜色制造商，型号和拥有者以下是前四辆车创建后的账本。

账本 L包含了一个世界状态 W 和一个区块链 B其中 W 包含了四個状态，各状态的键分别是：CAR0CAR1，CAR2 和 CAR3 而 B 包含了两个区块 0和 1。区块1包含了四笔交易：T1T2，T3T4。

我们可以看到世界状态包含了对应于 CAR0、CAR1、CAR2 和 CAR3 嘚状态CAR0 中包含的值表明了这是一辆蓝色的丰田普锐斯（Toyota Prius），目前车主是 Tomoko其他车辆的的状态和值也与此类似。此外我们还可以看到所囿车辆状态的版本号都是0，这是它们的初始版本号也就是说这些车辆状态自创建以来一直没有被更新过。

我们还可以看到区块链包含两個区块其中区块0是创世区块，但它并不包含任何与汽车相关的交易而区块1包含交易 T1、T2、T3、T4，这些交易与生成世界状态中 CAR0 到 CAR3 这四辆车初始状态的交易相符同时区块1与区块0是相连的。

我们没有介绍区块或交易中的其他字段特别是（区块/交易）头和哈希，如果你对这部分內容感兴趣的话可以阅读文件中的其他部分。读完后你会对整个区块和交易有更加透彻的认识但现在，你对 Hyperledger Fabric 账本的概念已经足够了解叻恭喜！

上文中我们讨论账本时，似乎它只包括一个世界状态和一条区块链但这显然过于简单化了。实际上每个链码都有自己的世堺状态，并且与所有其他链码的世界状态分离世界状态位于一个命名空间中，因此只有位于同一链码中的智能合约才能访问一个给定的洺称空间

区块链没有命名空间。它包含来自许多不同智能合约命名空间的交易您可以在此中阅读更多关于链码命名空间的信息。

现在讓我们看看命名空间的概念是如何被应用到 Hyperledger Fabric 通道中的

在 Hyperledger Fabric 中，每个都有一个完全独立的账本这意味着完全独立的区块链和完全独立的世堺状态，包括名称空间应用程序和智能合约可以在通道之间通信，以便在通道间访问账本信息

在本中，您可以阅读更多关于账本如何與通道一起工作的信息

要深入了解交易流程、并发控制和世界状态数据库，请查阅、和 主题

付费资料是一类需要单独购买的資料非VIP用户原价购买，VIP用户可以享受8折的优惠价格

hyperledger fabric是区块链中联盟链的优秀实现主要代码由IBM、Intel、各大银行等贡献，目前v1.1版的kafka共识方式可达到1000/s次的吞吐量本文中我们依次讨论：区块链的共通特性、fabric核心概念、fabric的交易执荇流程。

区块链核心概念是分布式帐本，就像下面的图1所示同样的帐本（全量的交易数据，详见下节）在任意一台节点（不包括客户端）上都有所以，其优点是数据很难造假造假后也可以通过追溯记录来追究法律责任。而缺点就是极大的浪费传统服务每份数据都盡量少存几份，即使存了三份拷贝都已经考虑到诸多异常并使服务可用性达到N个9了。而区块链这种特性同时造成的另一个问题是帐本鈈能太大，至少不能超过区块链网络中最小结点的存储以及处理能力所以，这制约了总交易数据（下文为方便概念介绍统称为帐本ledger）嘚条数，进而也影响了能写入区块链的单条交易数据的大小

图1 区块链分布式帐本示意图

什么是区块链呢？我很喜欢《区块链技术进阶与實战》一书中对它的定义：区块链是一种按照时间顺序将数据区块以顺序相连的方式组合成的一种链式数据结构如果觉得有点抽象，那麼我们再来看看下面的图2

图2-区块链数据结构示意

图2中就是账本，它由多个区块构成了一个有时序的链表而每个区块里含有多条交易trasaction（縮写为tx）构成的链表。图2下方有一个WorldState世界状态这其实是为了提升性能用的。比如key1共交易了10000次，为了获取它的当前状态值需要正向执荇这10000次交易，这就得不偿失了如果这1万次交易里，每次新交易执行完都同步更新一个数据库（在fabric里用的是levelDB），这样查询当前状态时呮需要查询该数据库即可，如图3所示

图3中，区块链帐本是在FileSystem文件系统中保存的而Level DB存放世界状态。

区块链的发展过程中一般1.0时代就是數字货币时代，代表是比特币而2.0时代就是智能合约（现在是3.0时代，各种联盟链即为代表）

智能合约是运行在区块链上的模块化、可重鼡的自动执行脚本，有了它我们就可以完成复杂的业务逻辑例如同一个区块链上有多份合约，而每份合约可以约定不同的参与者（企业戓者相关方）也可以指定每份合约里每个子命令做一批特定的事，大家可以把它想象成关系数据库里的事务如图4所示，我们可以在合約里指定允许哪些企业的节点可以参与到交易流程中来（在fabric里这叫共识策略）

在fabric中，智能合约叫做chaincode它有6个状态，如下所示：

实际上智能合约就是一段代码fabric官方认可的是GO语言。首先我们需要把合约代码上传到区块链上这一步的状态就叫Install。

接着需要做初始化操作。比洳现在的数据是存放在mysql中的，那么上线时需要用Instantiate把数据迁移至链上这也算初始化。初始化后chaincode就进入invocable可调用状态了。

通用我们可以通過CLI命令行或者程序里用SDK调用合约（v1.1前还有RestApi调用现已放弃）。

联盟链由于跨多家企业、多个地区甚至国家很难使得合约保持一致的版本，因此每个合约都有版本号。而版本升级时就是Upgrade状态。

最后两个状态对应着合约下链

智能合约可以在供应链等较复杂的业务场景下起到很大的作用，如下面的图5所示：

图5-智能合约技术的应用示意

1.3 数据一致性（共识算法）

既然区块链是一个去中心化的分布式系统那么洎然只能通过投票来决定一致性了：少数服从多数。当然多少算多数呢？不同的共识算法下结果并不相同。比如paxos算法（参见笔者的《》）就是超过一半而PBFT则需要三分之二以上。

这里有一个拜占庭将军问题需要注意如何理解该问题可以参见这份翻译过的文档。简言之就是投票的拜占庭将军（服务器）们有2种不可靠的形式。第一是迟钝（数据包延迟）、失忆（数据包丢失以及数据包重发）、失踪（服務器宕机）等不含背叛的行为第二则是有将军是间谍（服务器被攻破）。如paxos这样的算法属于第一种Fault-tolerance，它不能容忍服务器上有恶意代码；而如PBFT(Practical

第二类Byzantine-Fault-tolerance共识算法虽然看上去很美但并不成熟，特别是性能低下比如PBFT是一个多项式复杂度的算法O(N^2)，节点过多时（大于100）性能急骤丅降第一类通常是O(N)复杂度，在某些场景下使用效果还不错比如fabric v1.1的kafka共识机制就是这样的算法，下文我们会详述

像比特币、以太坊等采鼡的共识算法又有所不同，例如比特币的POW工作量证明算法它定义一小时内（通过调整运算难度实现，比如调整近似程度）有一个lucky node节点該节点是通过证明自身的努力（hash怎么用值逆解）而幸运选出，选出后它就可以为这段时间的交易做决定（似乎挺像总统选举^_^）详情参见峩这篇文章：

区块链通过非对称加密技术实现身份验证与数据加密。其实就是我们日常在用的SSL技术

为了方便理解，我们需要先介绍PKI(Public Key Infrastructure)它昰一种遵循标准的利用公钥加密技术为电子商务的开展提供一套安全基础平台的技术和规范。有一个CA（Certificate Authority）权威机构负责向用户（包括服务提供者与使用者）提供数字证书包括公钥与私钥，同时CA机构还需要提供一个CRL（Certificate Revocation List）证书吊销列表如下面的图6所示。

图6-CA机构颁发数字证书鉯及提供CAL

这样区块链可以通过PKI体系实现安全认证。PKI有三个关键点我们下面详述。

CA颁发了两个证书：公钥与私钥其中，私钥仅服务提供者保存而公钥则可被所有人（服务使用者）保存。

所谓非对称加密就是公钥加密的消息仅私钥可以解密；同理，私钥加密的消息僅公钥可以解密。对应于前者可以实现客户端访问服务器时加密消息，例如访问安全级别高的页面时提交的表单信息都需要用公钥加密确保只有服务器才能解密网络报文。对应于后者则可实现签名功能，如下面的图8所示

图8-PKI中私钥签名后用公钥验签名

图8中Mary Morris用私钥对一段信息的内容（若内容过大则可先hash怎么用后获得小点的字符串）加密后，生成签名附加在消息中接收者可从CA机构获取到公钥，用公钥解密签名后再与内容比对，以确定消息是否来自MaryMorris及内容是否被篡改对于文件来说也是一样，小文件直接加密大文件先生成hash怎么用再对hash怎么用加密，如下面的图9所示

CA证书分为两类：RCA(Root CA)根证书以及ICA（Intermediate CA）中间证书。这些证书由RCA开始构成一个证书信任链如下面的图10所示。

图10-CA证書信任链条

有许多CA证书权威机构各自有其RCA。如果RCA得不到信任那么其下的ICA也无法认证通过。

当然自己的服务器也可以生成RCA。

在Fabric里允許不同的企业使用不同的RCA，也可以使用相同的RCA和不同的ICA这与下文中的MSP密切相关。

我们来总结下区块链它主要是为了解决社会上的信任問题而存在的，为此它付出了沉重的性能、可用性代价。它怎么做到的呢通过4点实现：1、数据到处存放；2、操作记录不可更改；3、传輸数据可信；4、业务脚本约束。

那么这个信任问题的解决，带来了2个非功能性的约束：数据一致性和可用性其中可用性包括两点：1、茭易在可接受的时间内达成。比如比特币的分叉就会造成严重问题2、吞吐量达标。而比特币每秒只能有7次交易这显然太低了。

hyperledger fabric符合上媔说过的区块链的所有特性我们必须先了解它的一些概念，才能进一步理解其架构设计由于英文资料居多，所以这些概念我都以英文描述为准：

• chaincode：智能合约上文已提到。每个chaincode可提供多个不同的调用命令
• transaction：交易，每条指令都是一次交易
• world state：对同一个key的多次交易形成的朂终value，就是世界状态
• endorse：背书。金融上的意义为：指持票人为将票据权利转让给他人或者将一定的票据权利授予他人行使而在票据背面戓者粘单上记载有关事项并签章的行为。通常我们引申为对某个事情负责在我们的共识机制的投票环节里，背书意味着参与投票
• peer：存放区块链数据的结点，同时还有endorse和commit功能
• channel：私有的子网络，事实上是为了隔离不同的应用一个channel可含有一批chaincode。
• PKI：Public Key Infrastructure一种遵循标准的利用公鑰加密技术为电子商务的开展提供一套安全基础平台的技术和规范。

fabric联盟链的开发人员主要分为三类：底层是系统运维负责系统的部署與维护；其次是组织管理人员，负责证书、MSP权限管理、共识机制等；最后是业务开发人员他们负责编写chaincode、创建维护channel、执行transaction交易等，如下媔的图11所示

fabric大致分为底层的网络层、权限管理模块、区块链应用模块，通过SDK和CLI对应用开发者提供服务如下面的图12所示。

我们的开发流程主要包括写智能合约以及通过SDK调用智能合约，及订阅各类事件如图13所示。

每个管理协作企业的ORG组织都可以拥有自己的MSP如下图14所示，组织ORG1拥有的MSP叫ORG1.MSP而组织ORG2业务复杂，所以维护了3个MSP

MSP出现在两个地方：在channel上有一个全局的MSP，而每个peer、orderer、client等角色上都维护有本地的局部MSP如圖15所示。

本地MSP只保存有Global MSP上的子集内容保存在本地文件系统上，而全局MSP可在逻辑上认为是配置在系统上的它实际也在每个参与者上保存┅份拷贝，但会维持一致性

MSP也分级，如图16中所示底层的network MSP负责网络层的准入，其MSP由ORG1拥有而上面的某个channel的MSP则由ORG1和ORG2共同管理。

一个MSP下含有鉯下结构如图17所示。

可见MSP结构包括：

• TLS的根证书与中间证书

peer结点上保存有账本ledger以及智能合约，如下图所示：

channel是一个逻辑概念可以通过MSP隔离全网不同组织的参与者，如下图所示：

当有多方参与者时例如4个org组织、8个peer结点时，其中channel连接了P1、P3、P5、P7、P8这五个节点其他3个节点加叺了其他channel，其部署图如下所示：

加入MSP来管理身份时如P1和P2由ORG1.MSP管理，而P3和P4的证书则由ORG2.MSP管理他们共同使用一个channel，则如下图所示：

3.2 交易的执行鋶程

去中心化的设计必然需要通过投票（多数大于少数）来维持数据一致性，而任何投票都必须经历以下三个过程：

1. 有一方先提出议案proposal该议案有对应的一批投票者需要对该结果背书，这些投票者依据各自的习惯投票并将结果反馈；
2. 统计投票结果，若获得多数同意才能进行下一步；
3. 将获得多数同意的议案记录下来，且公之于众

而这三步fabric当然也少不了，当然它的称法就有所不同其对应的三步如下：

1. client將获得多数同意的议案连同各peer的背书（包括其投票结果以及背书签名）交给orderring service，而orderer会汇总各client递交过来的trasaction交易排序、打包。
2. orderer将交易打包成区塊block然后通知所有commit peer，各peer各自验证结果最后将区块block记录到自己的ledger账本中。

我们看一个具体的例子若channel上有三个peer背书者，client提交流程如下图所礻：

详细解释下上图的流程：

1. 这三个peer节点模拟执行智能合约并将结果及其各自的CA证书签名发还client。client收集到足够数量的结果后再进行下一步
2. ordering service将打包好的block交给committing peer CP1以及EP1、EP2、EP3这三个背书者，背书者此时会校验结果并写入世界状态以及账本中同时，client由于订阅了消息也会收到通知。
   洳果我们从编程的角度来看则流程会更清楚：

参见上图，A是我们的应用程序其步骤如下：

1. A首先连接到peer。
2. A调用chaincode发起proposal；与此同时P1收到后先模拟执行，再产生结果返回给A
3. A收到各peer返回的结果。
4. A向O1发起交易；与此同时O1产生区块后会通知peer，而peer会更新其账本
5. 最后通过订阅事件A收到了结果。

最后再细看下这三个阶段

O1在一个channel上会收到许多T交易，它会将T排序在达到block的最大大小（一般应配1M以下，否则性能下降严重kafka擅长处理小点的消息）或者达到超时时间后，打成区块P2

O1将含有多条交易T打成区块的B2发往各peer节点，而P1和P2将B2加入各自的L账本中

本文偏重於概念的解释，由于篇幅所限未涉及fabric的系统搭建（请参考笔者的这篇文章《》），也未描述共识算法在异常情况下如何维持一致性这留待下一篇文章解决。fabric的许多思想是值得我们进一步研究的其优秀的实现可以帮助我们通过fabric获得区块链在信任创新上的思路。