Hyperledger Fabric基础概念

作者: 青柠果嗄 | 来源:发表于2019-06-20 10:42 被阅读0次

本文主要从概念的层次来介绍什么是hyperledger。在学习本文之前需要先进行区块链基础的学习。

介绍

hyperledger的区块链网络是由组织构成，每个组织拥有自己的peer节点；除此之外，一个或者多个orderer节点为整个网络提供排序（或者说共识）服务，每个组织可能会有ca server节点来提供身份服务。组织之间可以建立channel，channel之间的数据是隔离的。

1.1 基础概念

1.1.1 ledger

ledger更多的是一个概念而不是实体，你可以认为它是账本。账本包含交易日志（或者说是区块）和当前的业务状态（类比以太坊的world state或者后端数据库内的数据）。

交易日志提供了在系统运行过程中发生的可验证历史，它包含所有成功的状态更改（有效交易）和不成功的状态更改尝试（无效交易）。

简单来说，区块链不可变地记录交易（transation），交易会更新ledger中状态。智能合约以编程方式访问ledger的两个不同部分 - 一个区块链（这里并不是名词上的区块链，而是一个个区块通过hash指针构成一条链），不可变地记录所有交易的历史记录；一个世界状态，保存这些状态的当前值的缓存（或者说快照），一个对象的当前值通常是需要的。

智能合约主要put get delete世界状态下的状态，还可以查询不可变的区块链交易记录。

一个GET通常代表一个查询，检索有关业务对象的当前状态信息。
一个put通常会创建一个新的业务对象或修改总帐状态现有之一。
一个delete典型代表去除总账的当前状态的业务对象，而不是它的历史。

智能合约有许多API可供他们使用。重要的是，在所有情况下，无论transaction是创建，读取，更新还是删除世界状态中的业务对象，区块链都包含这些更改的不可变记录。

1.1.2 peer

peer就是区块链通常意义上的节点，每个节点都归属于一个组织。

peer节点托管着账本和链码，是Fabric网络的基础组成部分。

1.1.3 orderer

通过上面我们知道，peer可以安装链码，区块链网络中有许许多多的peer，而链码的数据或者说“世界状态”同步的（在区块链正常状态下，区块链自身容错机制来决定可以容忍多少节点崩溃或作恶而正常节点保持同步）。

orderer是特殊节点，orderer节点执行交易排序，与其他节点一起形成ordering服务，以确保每一个peer节点上的账本保持一致性。

1.1.4 chaincode

chaincode是链码或者说智能合约，通俗来说，就是业务逻辑。从应用程序开发人员的角度来看，智能合约与ledger一起构成了Hyperledger Fabric区块链系统的核心。ledger保存有关一组业务对象的当前和历史状态的事实，而智能合约定义生成添加到ledger的新事实的可执行逻辑。

1.1.5 Transaction

交易，可以理解成链码执行的操作（调用或者部署）。跟通用区块链概念里的交易是一样的。

1.1.6 endorsement

每份智能合约都有与之相关的背书策略（认可政策，endorsement）。此背书策略确定哪些组织必须批准智能合约生成的交易，然后才能将这些交易识别为有效。所有transaction（无论是有效还是无效）都会添加到分布式账本中，但只有有效transaction才会更新世界状态。

1.1.7 channel

Hyperledger Fabric允许组织通过channel(通道)同时参与多个独立的区块链网络。通道提供有效的基础设施共享，同时维护数据和通信隐私。channel之间有充分的独立性，可以帮助org将业务与不同的竞争对手分开；同时也能在必要的时候使独立的组织联合起来。

channel

通俗来讲通道在组织之间提供了完全独立的通信机制，实现了业务的隔离；只有同channel的组织才能共享此channel内的数据，同时一个组织也可以加入不同的channel。

1.1.8 CA节点

其实是Fabric CA server节点。具体功能在Certificate Authorit有介绍。可以通过网络访问其API。

1.1.9 identity

区块链网络中的不同参与者包括peers, orderers, client applications, administrators等。这些参与者中的每一个(无论网络内部或外部的能够使用服务的活动元素)都具有封装在X.509（一种标准，有兴趣可以自行了解）数字证书中的数字身份。这些身份确实很重要，因为它们定义了对资源的确切权限，和参与者在区块链网络中对各种信息的访问权限。

此外，数字身份还具有Fabric用于确定权限的一些附加属性，并且它为身份和相关属性的集合提供了特殊名称 - 主体。主体就像userID或groupID一样，但更灵活一点，因为他们可以包括参与者身份更广泛的属性，如参与者的组织，组织单位，角色，甚至参与者的具体身份。当我们谈论主体时，它就代表决定其权限的属性。

要使身份可以验证，它必须来自可信任的机构。membership service provider（MSP）是上述内容在fabric中的实现。更具体地说，MSP是定义管理该组织的有效身份的规则的组件。Fabric中的默认MSP实现使用X.509证书作为身份，采用传统的公钥基础结构（PKI）分层模型（本教程不会详细介绍PKI，有兴趣可以在这里查看）。

身份是由Certificate Authority（CA）发行的，由于此项内容比较重要fabric中提供了内置的实现fabric ca。

1.1.10 Certificate Authority

通常情况下，数字身份（或简称身份identity）是可以通过加密方式验证的数字证书并符合X.509标准，是由证书颁发机构（CA）颁发的。

Hyperledger Fabric CA是Hyperledger Fabric的证书颁发机制。它提供如下功能：

注册身份，或作为用户注册表连接到LDAP（Lightweight Directory Access Protocol）
签发注册证书（ECerts）
证书续签和撤销

Fabric CA包含server（服务器部分，负责后端功能）和client（通常在sdk中使用，用于跟server交互）。server带restful API可以通过网络访问。

1.2 区块链网络结构

下图是一个示例网络最终状态图

示例网络最终状态图

图中可以看出，有四个组织，他们共同决定并签署协议，建立并利用Hyperledger Fabric网络。（网络配置NC4，由R1和R4控制管理）四个组织每个都有证书颁布机构^[1]（CA1，CA2，CA3，CA4）

其中R4是网络发起者（被赋予设置网络初始版本的权利，没有去执行业务交易的目的）

R1和R2在整个网络中需要专用通道^[2]（通道C1，通道配置CC1，由R1，R2控制管理）；同样R2和R3在整个网络中也需要专用通道（通道C2，通道配置CC2，由R2，R3控制管理）。

R2有一个应用程序A2，可以在通道C1和C2执行类似的工作。

peer节点^[3]P1安装并在通道C1上实例化智能合约S5，peer节点P1维护与通道C1相关联的账本^[4]L1的副本，使得A1可以通过调用S5来访问账本L1的副本。同理，peer节点P2维护与通道C1相关联的账本L1的副本和通道C2相关联的账本L2的副本。

一个简单网络的形成过程如下：

1.2.1 创建网络

创建网络

orderer节点^[5]O4最初由组织R4中的管理员配置并启动，并在R4中托管，O4启动形成网络，网络配置NC4（network config）给予组织R4管理权限，证书颁发机构CA4将身份分配给R4组织的管理员和网络节点。
网络配置包含有关网络组成的实际情况，例如consortium及其组织的名称。网络配置定义的策略控制着网络访问。

1.2.2 添加网络管理员

添加网络管理员

组织R4更新网络配置NC4，使组织R1也成为管理员。这样，R1和R4对网络配置具有相同的权限。

修改策略

Hyperledger Fabric提供了一个独特的强大策略，允许网络和通道管理员管理更改策略。

在上面的示例网络图中，最初建立网络的时候，只允许组织R4管理网络，这是通过网络配置NC4中定义网络资源权限来实现的。然后，R4通过更新网络配置NC4将R1添加为管理员。

1.2.3 定义一个consortium

定义一个consortium

网络管理员定义了一个包含两个成员的consortium X1，即组织R1和R2。该consortium定义存储在网络配置NC4中，并将用于网络开发的下一阶段通道创建，CA1和CA2是R1和R2相应的证书颁发机构。

1.2.4 创建通道

创建通道

consortium X1为R1和R2创建通道C1，用于R1和R2之间的交易处理。通道C1由通道配置CC1控制，完全独立于网络配置。CC1由R1和R2管理，他们对C1拥有相同的权利，R4对CC1没有任何权利。
通道配置定义的策略用来控制对通道资源的访问。

1.2.5 peer节点和ledger

peer节点和ledger

peer节点P1加入到通道C1，P1物理托管账本L1的副本，P1和O4可以使用通道C1相互通信。

P1启动后，可以使用orderer节点O4 加入通道C1。当O4收到此加入请求时，它使用通道配置CC1来确定P1在此通道上的权限。

1.2.6 应用程序和智能合约链码（智能合约先安装，后实例化）

应用程序和链码

组织R1中的管理员将智能合约S5安装到peer节点P1上，然后，智能合约S5必需在通道C1上实例化，组织R1中的应用程序A1才可以调用S5通过peer节点P1访问账本L1的副本。
智能合约必须在节点上安装并在通道上实例化之后才能被调用。

调用智能合约

一旦智能合约在peer节点上安装并在通道上实例化，它就可以由应用程序调用。应用程序通过向认可策略中组织所拥有的peer节点发送交易提议，来实现智能合约的调用，交易流程详见于第二部分。

1.2.7 初始网络形成

初始网络形成

组织R2将peer节点P2加入到通道C1上，P2托管着账本L1和智能合约S5的副本。R2还添加了应用程序A2加入通道C1，它可以通过通道C1连接到网络。

至此，我们创建了第一个网络。在网络开发的阶段，组织R1和R2可以通过通道C1相互进行交易。具体而言，应用程序A1和A2可以调用智能合约S5和通道C1上的账本L1生成交易。

生成和接受交易

托管智能合约的peer节点具有特殊功能 - 帮助生成交易。所有peer节点都可以在验证之后决定在其帐本L1副本上接受或拒绝交易。只有安装了智能合约的peer节点才能参与交易认可过程，这对于生成有效交易至关重要。交易流程详见第二部分。

安装智能合约
在开发智能合约之后，组织中的管理员必须将其安装到peer节点上。

实例化智能合约
peer节点安装了智能合约之后，只能合约必须在通道上实例化，这样连接到通道的其他组件才能调用智能合约。

通俗来讲，一份智能合约在一个peer节点上安装一次，在不同通道上分别实例化。

安装智能合约和实例化智能合约的区别是，安装智能合约可以理解为是物理上托管在peer节点上，实例化智能合约可以理解为逻辑上托管在通道上。

安装未实例化

由于S5已经由组织R1在通道C1上实例化，组织R2不需要在通道C1上实例化智能合约S5。实例化只需要发生一次，随后加入通道C1的任何peer节点都知道智能合约S5可用于该通道。这说明账本L1和智能合约S5在peer节点上以物理方式存在，在通道上以逻辑方式存在。。

简化网络图

简化网络图

上图概括而言，客户端应用A1和A2可以使用通道C1与peer节点P1和P2以及orderer节点O4进行通信。peer节点P1和P2可以使用通道C1的通信服务，ordering服务O4可以使用通道C1的通信服务，通道配置CC1适用于通道C1。

1.2.8 添加一个新consortium

添加一个新consortium

组织R1或R4的网络管理员添加了一个新的consortium X2，其中包括组织R2和R3，用于为X2定义新通道。

1.2.9 添加一个新通道

添加一个新通道

consortium X2为R2和R3创建了新的通道C2，通道C2由R2和R3管理。

通道C2为consortium X2提供专用通信机制。它由R2和R3独家管理，R1和R4在通道C2中没有权限。（通道政策始终保持彼此独立，并且只能由获得授权的组织在通道中进行更改。）

1.2.10 新peer节点加入通道中

新peer节点加入到通道中

添加一个新peer节点P3，P3加入到通道C2，使得应用程序A3可以使用通道C2与P3和ordering服务O4进行通信。

因为peer节点P3连接到通道C2，所以它与使用通道C1的peer节点具有不同的账本L2，账本L2范围是通道C2。同理，安装在peer节点P3上并在通道C2上实例化的智能合约S6用于提供对账本L2的访问。应用程序A3可以通过通道C2来调用智能合约S6提供的服务，以生成可以被接受到网络账本L2副本中的交易。

1.2.11 将peer节点加入多个通道

将peer节点加入多个通道

peer节点P2加入到通道C2上，P2物理托管账本L2的副本，智能合约S6安装到P2上。

如上图，应用A1可以通过通道C1与对peer节点P1和P2以及ordering服务O4进行通信，应用A2可以通过通道C1与peer节点P1和P2进行通信，并通过通道C2与peer节点P2和P3以及ordering服务O4进行通信; 应用A3可以通过通道C2与peer节点P3和P2以及ordering服务O4进行通信。ordering服务O4可以使用通道C1和C2的通信服务。

ordering服务

ordering服务可能由不同组织拥有的许多单个节点组成，ordering服务本身也可以完全分布式的。

ordering服务

多组织ordering服务，ordering服务包括ordering服务节点O1和O4。节点O1由组织R1提供，节点O4由组织R4提供。
上图可以看出这个ordering服务的分布式 - 它在组织R1中运行，也在组织R4中运行。

除了作为网络的管理点之外，ordering服务还是交易的分配点。
ordering服务是从应用程序收集认可的交易并将它们打包成交易块，交易块随后被分发到通道中的每个peer节点。在每个committer节点中，记录交易，无论是有效还是无效，账本的副本都被更新。

1.2.12 网络最终形成

网络最终形成

在上图中，Fabric区块链网络由两个通道和一个ordering通道组成。组织R1和R4负责订购通道，R1和R2负责蓝色应用程序通道，而R2和R3负责红色应用程序通道。应用程序A1是组织R1的元素，CA1是其证书颁发机构。组织R2的peer节点P2可以使用蓝色和红色应用程序通道的通信设施。

2. 交易流程介绍

2.1 交易流程

本章节概述了标准资产交换过程中发生的交易机制。该示例包括两个client A和B，他们正在买卖萝卜。他们每个人在网络上都有一个peer节点，通过他们发送交易并与ledger进行交互。

买卖萝卜

假设
此流程假定已创建并运行一个通道，应用程序中用户已注册，并且注册了组织的证书颁发机构（CA），链码（包含定义一组交易指令的逻辑和萝卜的商定价格）也已安装并实例化，还为此链码设置了一个认可策略，声明peerA和peerB都必须认可任何交易。

假设

1. client A启动交易

client A正在发送购买萝卜的请求。背书策略中规定两个peer节点必须支持任何交易，因此请求将转发给peerA和peerB。

应用程序调用SDK的API来生成交易提议，该提议是调用链码功能的请求，以便将数据读取或写入ledger。 SDK将交易提议打包为正确的架构格式（gRPC上的协议缓冲区），并使用用户的加密凭据为此交易提议生成唯一签名。

启动交易

2. 背书节点验证签名 & 执行交易
endorser节点

在应用程序向节点发起交易背书请求的peer节点是endorser节点，负责检验某个交易是否合法，是否愿意为之背书、签名。

背书节点验证：
（1）交易提议格式正确
（2）过去未提交过（重放攻击保护）
（3）签名有效（使用MSP）
（4）提交者（在示例中为client A）在该通道上适当被授予执行提议操作的权限（即每个背书节点确保提交者满足通道的写入策略）。
背书节点将交易提议输入作为调用链码函数的参数。然后针对当前状态数据库执行链码以产生包括响应值、读取集和写入集的交易结果。 此时没有对ledger进行更新。这些值的集合以及背书节点的签名将作为“提议响应”传递回SDK，该SDK解析应用程序要使用的有效负载。

验证签名&执行交易

3. 检查提议响应
应用程序验证背书节点签名并比较提议响应，以确定提议响应是否相同。 如果链码仅查询总账，则应用程序将检查查询响应，并且通常不会将交易提交给Ordering 服务。如果客户端应用程序打算将交易提交给Ordering 服务以更新总账，则应用程序在提交之前确定是否已满足指定的背书策略（即peerA和peerB都认可）。在该体系结构中，即使应用程序选择不检查响应或以其他方式转发未经许可的交易，该背书策略仍将由peer节点强制执行并在提交验证阶段维持。

检查提议响应

4. client将认可集中到交易中
该应用程序将交易提议和交易消息中的响应“广播”到Ordering 服务。该交易将包含读取集/写入集，背书节点签名和通道ID。 Ordering服务不需要检查交易的整个内容以执行其操作，它只是从网络中的所有通道中接收交易，按时间顺序按通道对它们进行排序，并创建每个通道的交易块。

集中认可到交易中

5. 交易已被验证和提交
交易块被“交付”到通道上的所有peer节点，验证块内的交易以确保满足背书策略并确保自交易执行产生读取集以来，读取集变量的ledger状态没有变化，块中的交易被标记为有效或无效。

交易已被验证和提交

6. 更新Ledger
每个peer节点将块附加到通道的链上，并且对于每个有效的交易，写入集被提交到当前状态数据库。发出一个事件，通知客户端应用程序交易（调用）已被不可变地附加到链中，并且通知该交易是否已验证或无效。

2.2 一个可能的交易流程（常见案例）

一个可能的交易流程
如上图所示：
① client创建一条交易并将其发送到背书节点上
为了执行（invoke）一条交易，client向其选择的一组背书节点集发送一条PROPOSE消息。
其中PROPOSE消息格式是<PROPOSE,tx,[archor]>，其中tx是必需参数，anchor是可选参数。anchor包含读取版本依赖关系，tx格式如下：
tx=<clientID,chaincodeID,txPayload,timestamp,clientSig>，参数说明如下：
* clientID：submitting clientID
* chaincodeID：交易涉及的链码ID
* txPayload：包含提交交易本身的有效负载
* timestamp：client维护的单调递增（对于每条新的交易）整数
* clientSig：client在tx其他字段的签名

② 背书节点模拟交易并生成背书签名
在接收来自client的<PROPOSE,tx,[archor]>消息时，背书节点epID（endorsing peer ID）首先校验client签名clientSig然后去模拟交易。如果client指定了anchor，那么背书节点只能在其在本地KVS(key-value store)中读取对应密钥的版本号（即如下定义的readset）与anchor指定版本号相匹配时模拟交易。
模拟交易涉及到通过调用交易引用的链码以及背书节点本地保存的状态副本来对暂时执行交易的peer节点进行认可。

③ submitting client收集交易背书，并通过ordering服务进行广播
submitting client等待它收到足够的消息和语句签名，以得出交易提议已获得批准的结论。“足够”的确切数量取决于链码认可策略。如果满足背书策略，那么交易将获得批准。如果submitting client没有设法收集交易提议的背书，它将放弃此交易，并选择稍后重试。对于有效认可的交易，submitting client使用广播（blob）调用ordering服务。

④ ordering服务向peer节点提供交易
deliver(seqno, prevhash, blob)：ordering服务调用这个接口分发消息到peer节点，分发过程指定一个非负整形序列号、最近分发blob的hash值。也就是，这是一个ordering服务的输出事件。

当peer节点收到deliver(seqno, prevhash, blob)事件后，同时peer已经完成所有序列号小于seqno的deliver事件的更新。Peer节点会做以下操作：

根据引用链码的背书策略检查blob.endorsement是否有效
一般情况下，peer节点验证依赖关系blob.endorsement.tran-proposal.readset没有同时被违反。复杂情况是，endorsement中的tran-proposals字段可能会不相同（endorsement中有多个背书节点返回的tran-proposal），这时endorsement策略指定了状态怎样更新。

-如果所有这些检查都通过，则该交易被视为有效或已提交，peer节点在PeerLedger的位掩码用1标记该交易，并将blob.endorsement.tran-proposal.writeset应用于区块链状态。
-如果认可策略验证blob.endorsement失败，则交易无效，peer节点在PeerLedger的位掩码用0标记该交易。注意，无效事务不会更改状态。

在ordering服务的保证下，所有的正常peer节点将会收到相同的deliver事件序列。当endorsement策略是规范的，readset中的版本依赖是确定的时，无论交易是否在一个有效的区块里，所有的正常peer节点最终都会是一样的结局。因此所有peer节点提交和应用相同的交易序列，并以相同的方式更新它们的状态。

参考

CA节点是Hyperledger Fabric的证书颁发机构，是可选的，可以用其他成熟的第三方CA颁发证书。CA节点接收客户端的注册申请，返回注册密码用于用户登录，以便获取身份证书。 ↩
通道，通道在组织之间提供了完全独立的通信机制，通俗来说，通道实现了业务隔离。 ↩
peer节点是托管着账本和链码的节点，构成Fabric网络的物理结构。 ↩
ledger，账本是由ordering服务构建的一个全部有序的交易哈希链块，包含所有成功的状态更改（有效交易）和不成功的状态更改尝试（无效交易）。 ↩
orderer是特殊节点，orderer节点执行交易排序，与其他节点一起形成ordering服务，以确保每一个peer节点上的账本保持一致性。 ↩