浅析 Fabric Peer 节点

Posted 2023-03-13

参考技术A

Hyperledger Fabric，也称之为超级账本，是由 IBM 发起，后成为 Linux 基金会 Hyperledger 中的区块链项目之一。

Fabric 是一个提供分布式账本解决方案的平台，底层的账本数据存储使用了区块链。区块链平台通常可以分为公有链、联盟链和私有链。公有链典型的代表是比特币这些公开的区块链网络，谁都可以加入到这个网络中。联盟链则有准入机制，无法随意加入到网络中，联盟链的典型例子就是 Fabric。

Fabric 不需要发币来激励参与方，也不需要挖矿来防止有人作恶，所以 Fabric 有着更好的性能。在Fabric 网络中，也有着诸多不同类型的节点来组成网络。其中 Peer 节点承载着账本和智能合约，是整个区块链网络的基础。在这篇文章中，会详细分析 Peer 的结构及其运行方式。

在本文中，假设读者已经了解区块链、智能合约等概念。

本文基于 Fabric1.4 LTS。

区块链网络是一个分布式的网络，Fabric 也是如此，由于 Fabric 是联盟链，需要准入机制，所以在网络结构上会复杂很多，下面是一个简化的 Fabric 网络：

各个元素的含义如下：

对于 Fabric 网络，外部的用户需要通过客户端应用，也就是图中的 A1、A2 或者 A3 来访问网络，客户端应用需要通过 CA 证书表明自己的身份，这样才能访问到 Fabric 网络中有权限访问的部分。

在上面的网络中，共有四个组织，R1、R2、R3 和 R4。其中 R4 是整个 Fabric 网络的创建者，网络是根据 NC4 配置的。

在 Fabric 网络中，不同的组织可以组成联盟，不同的联盟之间数据通过 Channel 来隔离。Channel 中的数据只有该联盟中的组织才能访问，每一个新的 Channel 都可以认为是一条新的链。与其他的区块链网络中通常只有一条链不一样，Fabric 可以通过 Channel 在网络中快速的搭建出一个新的区块链。

上面 R1 和 R2 组成了一个联盟，在 C1 上交易。R2 同时又和 R3 组成了另外一个联盟，在 C2 上交易。R1 和 R2 在 C1 上交易时，对 R3 是不可见的，R2 和 R3 在 C2 上交易时，对 R1 是不可见的。Channel 机制提供了很好的隐私保护能力。

Orderer 节点是整个 Fabric 网络共有的，用来为所有的交易排序、打包。比如上面网络中 O4 节点。本文不会对 Orderer 节点进行详细说明，可以把这个功能理解为比特币网络中的挖矿过程。

Peer 节点表示网络中的节点，通常一个 Peer 就表示一个组织，Peer 是整个区块链网络的基础，是智能合约和账本的载体，Peer 也是本文讨论的重点。

一个 Peer 节点可以承载多套账本和智能合约，比如 P2 节点，既维护了 C1 的账本和智能合约，也维护了 C2 的账本和智能合约。

为了可以更深入了解 Peer 节点的作用，先了解一下 Fabric 整体的交易流程。整体的交易流程图如下：

Peer 节点按照功能来分可以分为 背书节点 和 记账节点 。

客户端会提交交易请求到背书节点，背书节点开始模拟执行交易，在模拟执行之后，背书节点并不会去更新账本数据，而是把这个交易进行加密和签名，然后返回给客户端。

客户端收到这个响应之后就会把响应提交到 Orderer 节点，Orderer 节点会对这些交易进行排序，并打包成区块，然后分发到记账节点，记账节点就会对交易进行验证，验证结束之后，就会把交易记录到账本里面。

一笔交易是否能成功是根据背书策略来指定的，每一个智能合约都会指定一个背书策略。

Peer 节点代表着联盟链中的各个组织，区块链网络也是由 Peer 节点来组成的，而且也是账本和智能合约的载体。

通过对上面交易过程的了解可以知道，Peer 节点是主要的参与方。如果用户想要访问账本资源，都必须要和 peer 节点进行交互。在一个 Peer 节点中，可以同时维护多个账本，这些账本属于不同的 Channel 。每个 Peer 节点都会维护一套冗余账本，这样就避免了单点故障。

Peer 节点根据在交易中的不同角色，可以分成背书节点（Endorser）和记账节点（Committer），背书节点会对交易进行模拟执行，记账节点才会真正将数据存储到账本中。

账本可以分成两个部分，一部分是区块链，另一部分是 Current State，也被称之为 World State。

区块链上只能追加，不能对过去的数据进行修改，链上也包含两部分信息，一部分是通道的配置信息，另一部分是不可修改，序列化的记录。每一个区块记录前一个区块的信息，然后连成链，如下图所示：

第一个区块被称之为 genesis block，其中不存储交易信息。每个区块可以被分为 区块头 、 区块数据 和 区块元数据 。区块头中存储着当前区块的区块号、当前区块的 hash 值和上一个区块的 hash 值，这样才能把所有的区块连接起来。区块数据中包含了交易数据。区块元数据中则包括了区块写入的时间、写入人及签名。

其中每一笔交易的结构如下，在 Header 中，包含了 ChainCode 的名称、版本信息。Signature 就是交易发起用户的签名。Proposal 中主要是一些参数。Response 中是智能合约执行的结果。Endorsements 中是背书结果返回的结果。

WorldState中维护了账本的当前状态，数据以 Key-Value 的形式存储，可以快速查询和修改，每一次对 WorldState 的修改都会被记录到区块链中。WorldState 中的数据需要依赖外部的存储，通常使用 LevelDB 或者 CouchDB。

区块链和 WorldState 组成了一个完整的账本，World State 保证的业务数据的灵活变化，而区块链则保证了所有的修改是可追溯和不可篡改的。

在交易完成之后，数据已经写入账本，就需要将这些数据同步到其他的 Peer，Fabric 中使用的是 Gossip 协议。Gossip 也是 Channel 隔离的，只会在 Channel 中的 Peer 中广播和同步账本数据。

智能合约需要安装到 Peer 节点上，智能合约是访问账本的唯一方式。智能合约可以通过 Go、Java 等变成语言进行编写。

智能合约编写完成之后，需要打包到 ChainCode 中，每个 ChainCode 中可以包含多个智能合约。ChainCode 需要安装，ChainCode 需要安装到 Peer 节点上。安装好了之后，ChainCode 需要在 Channel 上实例化，实例化的时候需要指定背书策略。

智能合约在实例化之后就可以用来与账本进行交互了，流程图如下：

用户编写并部署实例化智能合约之后，就可以通过客户端应用程序来向智能合约提交请求，智能合约会对 WorldState 中数据进行 get、put 或者 delete。其中 get 操作直接从 WorldState 中读取交易对象当前的状态信息，不会去区块链上写入信息，但 put 和 delete 操作除了修改 WorldState，还会去区块链中写入一条交易信息，且交易信息不能修改。

区块链上的信息可以通过智能合约访问，也可以在客户端应用通过 API 直接访问。

Event 是客户端应用和 Fabric 网络交互的一种方式，客户端应用可以订阅 Event，当 Event 发生时，客户端应用就会接受到消息。

事件源可以两类，一类是智能合约发出的 Event，另一类是账本变更触发的 Event。用户可以从 Event 中获取到交易的信息，比如区块高度等信息。

在这篇文章中，首先介绍了 Fabric 整体的网络架构，通过对 Fabric 交易流程的分析，讨论了 peer 节点在交易中的作用，然后详细分析了 peer 节点所维护的账本和智能合约，并分析了 peer 节点维护账本以及 peer 节点执行智能合约的流程。

文 / Rayjun

[1] https://hyperledger-fabric.readthedocs.io/zh_CN/release-1.4/whatis.html

[2] https://developer.ibm.com/zh/technologies/blockchain/series/os-academy-hyperledger-fabric/

[3] https://en.wikipedia.org/wiki/Gossip_protocol

Fabric源码分析之Peer链码安装

参考技术A environment:
fabric v1.4.2

在Fabric中交易的处理过程，客户端将提案首先发送到背书节点，背书节点检提案的合法性。如果合法的话，背书节点将通过交易所属的链码临时执行一个交易，并执行背书节点在本地持有的状态副本。
Chaincode应该仅仅被安装于chaincode所有者的背书节点上，链码运行在节点上的沙盒（Docker容器）中，并通过gRPC协议与相应的Peer节点进行交互，以使该chaincode逻辑对整个网络的其他成员保密。
请务必在一条channel上每一个要运行你chaincode的背书节点上安装你的chaincode
其他没有chaincode的成员将无权成为chaincode影响下的交易的认证节点（endorser）。也就是说，他们不能执行chaincode。不过，他们仍可以验证交易并提交到账本上。
ChainCode要在区块链网络中运行，需要经过链码安装和链码实例化两个步骤。

链码的安装涉及到3个服务，分别是client，peer背书节点和LSCC容器
主要流程:

以下是在客户端执行 "peer chaincode install ..." 的业务流程图:

客户端执行链码安装命令:

客户端的整个流程切入点为 fabric/peer/main.go 的 main 函数

然后继续找到 peer/chaincode/chaincode.go

继续找到 peer/chaincode/install.go 的 installCmd 函数，可以看出 chaincodeInstall 为主要的入口函数

我们进去看看 InitCmdFactory 做了什么，位置在 peer/chaincode/common.go

返回了 ChaincodeCmdFactory 的结构体，定义为:

找到定义 genChaincodeDeploymentSpec

先看 getChaincodeSpec ,位于 peer/chaincode/common.go

封装返回 ChaincodeSpec 结构体

刚才生成的 ChaincodeSpec 作为 getChaincodeDeploymentSpec 函数的输入参数，返回 ChaincodeDeploymentSpec 结构体

CreateInstallProposalFromCDS 位于 protos/utils/proutils.go

调用 createProposalFromCDS

从结构体 ChaincodeInvocationSpec 可以看到用户链码安装需要调用到系统链码 lscc
通过 CreateProposalFromCIS=>CreateChaincodeProposal=>CreateChaincodeProposalWithTransient

再看 CreateChaincodeProposalWithTxIDNonceAndTransient 函数

最后返回 Proposal 结构体，定义见 protos\peer\proposal.pb.go

到这里 install 调用的 CreateInstallProposalFromCDS 完毕，返回 Proposal 结构体
关系有点复杂，给出一个类图能看得清晰点

回到 install ，看 GetSignedProposal 对刚创建的提案结构进行签名
函数位于 protos/utils/txutils.go

返回 SignedProposal 结构体,定义位于 protos/peer/proposal.pb.go

提案签名完后 install 调用 ProcessProposal 发送提案到peer节点进行处理，参数带了 SignedProposal 结构体
接下来client端就等到peer的 proposalResponse

当client调用了 ProposalResponse 消息就发送到peer背书节点,也就是走peer节点背书提案流程.
要看安装链码前做了什么，直接看 peer节点背书提案流程 就好。

我们从 core/endorser/endorser.go 的 callChaincode=>Execute 函数开始讲

在 core/chaincode/chaincode_support.go 找到 Execute

主要看 Invoke :

根据之前的信息，我们调用的是 lscc 来安装链码，所以在peer启动的时候已经初始化 lscc 链码容器了，所以回直接返回 handler 对象，后面的语句就不说了，在启动链码容器的章节再详细研究。

接着我们看 execute 函数，调用 createCCMessage 创建一个 ChaincodeMessage结构体消息 . Execute 负责把消息发送出去

在 core/chaincode/handler.go 找到 Execute

这里关键是 h.serialSendAsync(msg) 语句，功能是把包装好的信息以grpc协议发送出去，直接就等返回结果了。
至此 Execute 调用的 Invoke 就在等返回结果，结果返回就调用 processChaincodeExecutionResult 对链码结果进行处理

peer发送的信息哪去了呢？
我们定位到 code/chaincode/shim/chaincode.go ,我们看到两个入口函数 Start 和 StartInProc ， Start 为用户链码的入口函数，而 StartInProc 是系统链码的入口函数，他们同时都调用了 chatWithPeer ,因为我们调用的是lscc，就看 StartInProc

chatWithPeer就是开启grpc的接收模式在等到节点发来信息，接收到信息后就调用 handleMessage 处理信息。

因为我们信息类型为 ChaincodeMessage_TRANSACTION ,所以我们在 core/chaincode/shim/handler.go 顺着 handleMessage=>handleReady 扎到 handleTransaction

其中关键语句 res := handler.cc.Invoke(stub) ,这语句是调用相应链码的 Invoke 函数，所以我们找到 core/scc/lscc/lscc.go 下的 Invoke 函数

进去 core/scc/lscc/lscc.go 的 Invoke 函数可以看到，这里有 "INSTALL", "DEPLOY", "UPGRADE" 等操作，我们只看 INSTALL 部分。
关键调用函数是 executeInstall

接着看 executeInstall

HandleChaincodeInstall 为处理statedb，而 PutChaincodeToLocalStorage 是把链码文件安装到本地文件目录
链码安装到peer的默认路径 /var/hyperledger/production/chaincodes
到此链码的安装完毕

lscc链码安装完毕后，返回信息给peer节点，peer节点就给提案背书返回给client服务端，至此链码安装完毕。

github

参考:
5-ChainCode生命周期、分类及安装、实例化命令解析
fabric源码解读【peer chaincode】：安装链码
Fabric1.4源码解析：客户端安装链码