Hyperledger Fabric 详细介绍区块链中的联盟链架构

区块链开源实现HYPERLEDGER FABRIC架构详解

区块链开源实现HYPERLEDGER FABRIC架构详解

Hyperledger fabric 是联盟链在区块链中的一个优秀实现。 主要代码由IBM、英特尔和各大银行贡献。 目前v1.1版本的Kafka共识方式可以达到1000/s的吞吐量。 在本文中，我们依次讨论：区块链的共同特征、Fabric的核心概念、Fabric的交易执行流程。 .

一、区块链解决方案的特点 1.1 分布式账本

区块链的核心概念是分布式账本，如下图1所示，任何节点（不包括客户端）都存在同一个账本（全量交易数据，详见下一节）。 因此，优点是数据难以造假，造假后还可以通过追溯记录追究法律责任。 缺点是是一种巨大的浪费。 传统服务尽可能少地存储每个数据的副本。 即使保存三份，也考虑了很多异常，服务可用性达到了N个9。 区块链的特性带来的另一个问题是账本不能太大，至少不能超过区块链网络中最小节点的存储和处理能力。 因此，这就限制了交易数据总量（以下为便于概念介绍，简称账本）的数量，进而影响到区块链中可写入的单笔交易数据的大小。

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

什么是区块链？ 很喜欢《区块链技术进阶实战》一书中的定义：区块链是一种链式数据结构以太坊是联盟链吗，按照时间顺序将数据块按顺序组合起来。 如果你觉得它有点抽象，那么我们来看看下面的图2。

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

图2是账本，由多个区块组成一个时序链表，每个区块包含多个交易（简称tx）的链表。 图2底部有一个WorldState世界状态，其实是用来提升性能的。 例如，key1 总共被交易了 10,000 次。 为了得到它的当前状态值，需要向前执行这10000笔交易，这是得不偿失的。 如果在这10000个事务中，每执行一个新事务，同步更新一个数据库（fabric中使用levelDB），这样查询当前状态时，只需要查询数据库即可，如图3所示。

图3-fabric levelDB状态数据库

在图 3 中，区块链账本保存在 FileSystem 文件系统中，Level DB 存储世界状态。

1.2 智能合约smart contract

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

智能合约是运行在区块链上的模块化、可重复使用、自动执行的脚本。 有了它，我们就可以完成复杂的业务逻辑。 例如，同一个区块链上有多个合约，每个合约可以约定不同的参与者（企业或利益相关方）。 您还可以在每个合约中指定每个子命令来执行一批特定的事情。 您可以将其视为关系数据库中的事务。 如图4所示，我们可以在合约中指定允许哪些企业节点参与交易过程（这在fabric中称为共识策略）。

图 4 - 智能合约图

在fabric中，智能合约称为chaincode，它有6种状态，如下：

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

接下来，需要初始化。 比如当前数据存储在mysql中，那么上线的时候需要使用Instantiate将数据迁移到链上，也算是初始化。 初始化完成后，链码进入可调用状态。

一般情况下，我们可以使用SDK通过CLI命令行或者在程序中调用合约（v1.1之前也有RestApi调用，已经废弃）。

由于联盟链跨越多个公司、多个地区甚至国家，因此很难维护一个一致的合约版本。 因此，每个合约都有一个版本号。 版本升级时，处于Upgrade状态。

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

智能合约可以在供应链等复杂业务场景中发挥很大作用，如下图5所示：

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

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

由于区块链是一个去中心化的分布式系统，一致性只能通过投票决定：少数服从多数。 当然，多少算多数？ 在不同的共识算法下，结果是不一样的。 比如paxos算法（参见作者的《Paxos算法是如何实现容错的——讲述五虎小将的实践》）一半以上，而PBFT则需要三分之二以上。

这里有一个需要注意的拜占庭将军问题。 这个问题怎么理解可以看这篇翻译的The_Part-Time_Parliament（Paxos算法的中文翻译）文档。 简而言之，投票拜占庭将军（服务器）有两种形式的不可靠性。 一是慢速（数据包延迟）、失忆（数据包丢失重传）、消失（服务器宕机）等不包含背叛的行为，二是部分将军是间谍（服务器被攻破）。 paxos等算法属于第一种，Fault-tolerance，不能容忍服务器上的恶意代码； 而像PBFT（Practical Byzantine Fault Tolerance）这样的算法属于第二种，Byzantine-Fault-tolerance，可以容忍一定数量的拜占庭一般节点存在，比如PBFT，SBFT，RBFT算法等。

第二种拜占庭容错共识算法虽然看起来很漂亮，但并不成熟，尤其是性能低下。 例如，PBFT 是一种多项式复杂度为 O(N^2) 的算法，当节点过多（大于 100）时性能会直线下降。 第一种通常是 O(N) 复杂度，在某些场景下效果很好。 比如fabric v1.1的Kafka共识机制就是这样一种算法，下面我们会详细介绍。

比特币和以太坊采用的共识算法不同，比如比特币的POW工作量证明算法，它定义了在一小时内（通过调整计算难度，比如调整近似度）有一个幸运节点节点，该节点有幸通过证明自己的努力被选中（哈希值逆向解），被选中后可以对这段时间的交易进行决策（好像是总统选举^_^）。 详见我的文章：《区块链技术学习笔记》

1.4 非对称加密

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

为了便于理解，我们需要介绍一下PKI（Public Key Infrastructure），它是一种符合标准的技术和规范，使用公钥加密技术为电子商务提供安全的基础平台。 有一个CA（Certificate Authority）机构负责向用户（包括服务提供商和用户）提供数字证书，包括公钥和私钥，CA还需要提供一个CRL（Certificate Revocation List）证书吊销列表，如下表面如图 6 所示。

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

这样，区块链就可以通过PKI系统实现安全认证。 PKI有3个关键点，我们在下面详细介绍。

1.4.1 数字证书

例如Mary Morris符合X.509规范的数字证书中，Subject属性包含她的信息，包括国家C=US，州或省ST=Michigan，城市L=Detroit，单位O =Mitchesll Cars，其他信息OU=Manufacturing，公开信息CN=Mary Morris/UID=123456等，还包含其他信息，如下图7所示。

图7-PKI数字证书

1.4.2 公钥和私钥

CA颁发公钥和私钥两种证书，其中私钥只由服务提供者保存，而公钥可以由所有人（服务使用者）保存。

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

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

图8中，Mary Morris用私钥加密一段信息的内容（如果内容太大，可以先HASH，然后得到一串小圆点），然后生成签名附在信息。 接收者可以从CA获得公钥，用公钥解密签名，然后与内容进行比较，判断消息是否来自Mary Morris，内容是否被篡改。 文件也是如此，小文件直接加密，大文件先哈希再加密，如下图9所示。

图 9 - 签署文件

1.4.3 证书信任链

CA证书有两种类型：RCA（Root CA）根证书和ICA（Intermediate CA）中间证书。 这些证书形成以 RCA 开头的证书信任链，如下面的图 10 所示。

图 10 - CA 证书信任链

有许多 CA 证书颁发机构，每个机构都有自己的 RCA。 如果 RCA 不可信，则其下的 ICA 也无法进行身份验证。

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

在Fabric中，允许不同的公司使用不同的RCA，也可以使用相同的RCA和不同的ICA。 这与下面的 MSP 密切相关。

1.5 总结

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

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

2. fabric的核心概念

Hyperledger fabric 符合上述区块链的所有特性。 我们必须了解它的一些概念，才能进一步了解它的架构设计。 由于大部分是英文资料，我将对这些概念使用英文描述：

2.1 发展理念

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

图11-面料技术人员分层

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

图12-fabric开发模块图

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

图 13 - 开发链接

2.2 MSP

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

图 14 - ORG 可以管理自己的 MSP

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

图 15 - 通道上的全局 MSP 和参与角色上的本地 MSP

本地MSP只保存全局MSP的一个子集，内容保存在本地文件系统中，而全局MSP在逻辑上可以认为是在系统上配置的，它实际上在每个参与者上都保存了一个副本，但是一致性将被维护。

MSP 也被分类。 如图16所示，底层网络MSP负责网络层的接入。 它的MSP归ORG1所有，上面某个channel的MSP由ORG1和ORG2共同管理。

图 16 - MSP 是分层的

MSP 包含以下结构，如图 17 所示。

图 17 - MSP 结构

可以看出，MSP结构包括：

3. Fabric交易提交流程

3.1 对等节点的部署

账本和智能合约保存在对等节点上，如下图所示：

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

当有多个参与者时，例如4个org组织和8个peer节点，通道连接5个节点P1、P3、P5、P7、P8，另外3个节点加入其他通道。 部署图如下：

加入MSP管理身份时，例如P1和P2由ORG1.MSP管理，P3和P4的证书由ORG2.MSP管理。 他们共享一个频道，如下图所示：

3.2 交易执行流程

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

一方先提出动议提案，该动议有相应的选民群体需要对结果进行背书。 这些选民按照自己的习惯投票，并反馈结果； 计算投票结果，只有多数同意才能进行下一步； 获得多数同意的提案被记录下来并公之于众。

当然，三步面料也是少不了的。 当然，它的名字是不同的。 对应的三个步骤如下：

该提案由客户端的 CLI 或 SDK 提出。 客户端根据智能合约链码和背书策略决定将提案发送给哪些背书节点，节点投票，客户端汇总每个背书节点的结果； 投票结果和背书签名）交给orderring服务，orderer将对每个client提交的trasaction交易进行汇总、排序、打包。 orderer将交易打包成block block，然后通知所有commit peer，每个peer验证结果，最后将block block记录到自己的ledger ledger中。

让我们看一个具体的例子。 如果通道上有3个peer endorsers，客户端提交流程如下图所示：

详细解释上图的过程：

首先，客户端发起一个事务transaction，其中包含3W元素等信息：消息是谁发送的，谁在什么时候发送的，什么时候发送的。 消息根据链码中的背书策略发送给三个对等节点EP1、EP2、EP3。 三个对等节点模拟智能合约的执行，并将结果连同各自的 CA 证书签名发送回客户端。 客户端在收集到足够数量的结果后继续下一步。 客户端将包含背书结果的 tx 交易发送给排序服务。 排序服务将打包的块交给提交节点 CP1 和三个背书者 EP1、EP2 和 EP3。 背书人将验证结果并将其写入世界状态和账本。 同时，客户端也会因为订阅了消息而收到通知。

如果我们从编程的角度来看，流程会更清晰：

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

A 首先连接到对等方。 A 调用链码发起提案； 同时P1收到后模拟执行，然后将结果返回给A，A收到各个peer返回的结果。 A向O1发起交易； 同时，O1在生成区块后通知peer，peer更新自己的账本。 最后，通过订阅事件 A 接收结果。

最后以太坊是联盟链吗，让我们仔细看看这三个阶段。

3.2.1 proposal提案阶段

可以看出A1发送、接收两个结果。

3.2.2 package打包阶段

O1会在一个channel上收到很多T笔交易，它会对T笔进行排序。达到块的最大大小后（一般应该配置在1M以下，否则性能会严重下降，Kafka擅长处理小消息）或者之后超时时间到，形成区块P2。

3.2.3 验证阶段

O1 将包含多笔交易 T 的 B2 打包发送到每个对等节点，P1 和 P2 将 B2 添加到各自的 L 账本中。