10.2 应用程序开发的SDK

本节先介绍应用开发SDK的基本功能。

10.2.1　概述

HFC（Hyperledger Fabric Client）是提供给应用程序开发的SDK，提供了gRPC连接的API。API包含了交易处理、安全的成员管理服务、区块链查询和事件处理等。 Hyperledger Fabric 1.0取消了0.6版本的RESTful接口，只能选择封装了gRPC接口的SDK。采用gRPC的原因主要有以下四点。

·底层的接口调用很多都是异步返回结果的，采用gRPC能够很好地双向传输数据。

·gRPC结合Protocol Buffers能减少传输数据量，提升网络传输性能。

·支持的语言较多，如Go、C#、Java、JavaScript、Python、C++等。

·和内部模块采用相同的通信接口，减少端口开放，也会减少安全的风险。

整个Fabric网络中，除了可选的fabric-ca采用的是RESTful接口之外，其他所有组件之间的通信都采用gRPC接口。

10.2.2　SDK规范

SDK定义了两种模块的接口：一个是访问fabric-ca的接口，一个是访问Fabric的接口。其中fabric-ca模块是可选的，可以选用其他成熟的第三方CA系统。官方提供了如下几种语言的SDK实现。

·Golang：https://github.com/hyperledger/fabric-sdk-go。

·Node.js：https://github.com/hyperledger/fabric-sdk-node。

·Python：https://github.com/hyperledger/fabric-sdk-py。

·Java：https://github.com/hyperledger/fabric-sdk-java。

下面以Golang为主介绍一下SDK的设计和实现。

1.访问Fabric模块介绍

我们先来看一下Fabric模块的UML图，如图10-2所示。

主要的模块包括FabricClient、Config、Channel、Peer、Orderer、User、 KeyValueStore、EventHub、Logger等，SDK本身还会复用fabric源码提供的功能。还有一些其他的模块（比如 Proposal、SignedProposal、ProposalResponse、Transaction、CryptoSuite等）在这里没有展 示。下面介绍各模块接口。

（1）FabricClient模块

FabricClient是应用程序的入口模块，提供通道管理、链码管理、数据存储、密码学相关的功能。每个 FabricClient实例对应一个区块链的网络，包括记账节点、排序节点等。如果应用程序需要访问多个网络，可以建立多个FabricClient的 实例，不同的实例对应不同的网络。

（2）Config模块

初始化FabricClient的时候需要离线获取配置信息，包括可信的根证书、排序服务节点证书和IP地址、记 账节点证书和IP地址等，配置模块Config读取后传递给FabricClient。配置信息是动态传递的，SDK不会持久化存储，应用程序负责维护这 些配置信息。

（3）Channel模块

通道是排序服务创建的隔离不同链上交易的实例，加入到不同通道的节点接收到的是不同的交易。通道在配置了排序服务节点和Peer节点后需要初始化，初始化的时候给排序服务节点发送获取配置区块的请求。

（4）Peer模块

Peer节点是HFC模块发送背书请求、交易查询的节点。Peer实例包含了节点名称、地址、角色、注册证书（ECert）等信息。

（5）Orderer模块

Orderer节点是HFC模块发送交易进行排序的节点。Orderer实例包含了排序服务节点地址信息，定义了发送原子广播请求和获取区块的接口。

（6）User模块

User代表了已经生成注册证书和签名密钥的实体，注册证书必须是区块链网络信任的CA颁发的证书，只有生成了注册证书的实体才能进行部署链码、提交交易和查询交易等操作。注册证书可以从第三方CA获取，也可以通过fabric-ca模块获取。

特别说明一下，用户身份（User Identity）和节点身份（Peer Identity）是有区别的。在SDK里面，用户身份能访问私钥信息，是可以进行签名的。而节点身份不能访问私钥，只能验证签名。

（7）KeyValueStore模块

KeyValueStore提供给应用程序保存敏感信息的功能，比如用户私钥、证书信息等。

（8）EventHub模块

EventHub封装了与Peer节点交互的事件流，接收Peer的各种异步通知事件。

（9）Logger模块

Logger是日志模块，提供了不同的日志接口，基本都是日常开发过程中用到的通用日志模块，这里就不详细展开了。

2.访问fabric-ca模块介绍

这里主要介绍FabricCAClient模块，其他的模块在前面已经介绍过。

FabricCAClient是应用程序的入口模块，提供通道管理、链码管理、数据存储、密码学相关的功能。每个 FabricCAClient实例对应一个区块链的网络，包括记账节点、排序节点等。如果应用程序需要访问多个网络，可以建立多个 FabricCAClient的实例，不同的实例对应不同的网络。

10.2.3　应用场景介绍

下面介绍几个基于SDK的典型应用场景，这些应用场景在应用开发的过程中都会遇到。

1.用户登记和注册

用户登记和注册是一个可选的场景，采用fabric-ca颁发证书时，应用程序、SDK和fabric-ca之间交互的时序图如图10-4所示。

各个组件之间的交互过程如下。

第1步：根据配置文件获取CA和CSP的配置信息，也可以采用其他的方式获取到这些配置信息；

第2步：根据配置信息创建FabricClient的实例，并设置CryptoSuite和KeyValueStore等信息，FabricClient实例是整个操作的入口；

第3步：获取负责提交用户资料的登记员信息Registrar，如果不存在，则需要先初始化登记员用户，获取登记员的注册证书和私钥信息；

第4步：根据配置信息和组织信息创建FabricCAClient的实例；

第5步：根据需要登记的用户信息生成RegistrationRequest请求，提交给FabricCAClient；

第6步：登记员Registrar会提交访问fabric-ca的POST请求，请求的URL是/api/v1/register；

第7步：fabric-ca验证请求生成用户注册的密码Secret，最终返回给应用程序，完成用户信息登记的步骤；

第8步：应用程序利用申请的用户信息和返回的注册密码，调用FabricCAClient的Enroll接口；

第9步：FabricCAClient生成私钥和证书签名请求CSR（Certificate Signing Request），调用fabric-ca提供的enroll接口生成注册证书；

第10步：返回生成的注册证书和私钥给应用程序；

第11步：可选的保存用户信息到KeyValueStore里。

fabric-ca还提供了重新注册生成注册证书和吊销证书的功能，目前fabric并不能完整地支持CRL和OCSP的功能。

2.在排序服务上创建通道

创建通道需要先利用工具configtxgen生成通道配置文件mychannel.tx。

创建通道涉及3个部分，应用程序或者客户端、HFC SDK、排序服务节点。各个组件之间的交互如下。

·第1步：应用程序读取通道配置文件mychannel.tx，这个文件是利用工具configtxgen生成的，包含了通道名称、组织配置等信息，详细的内容请参考第6章。

·第2步：创建通道只和排序服务节点通信，需要通过排序服务节点的配置生成Orderer实例。

·第3步：指定通道名称，并通过通道配置文件和Orderer实例生成创建通道请求CreateChannelRequest。

·第4步：创建FabricClient实例，调用CreateChannel创建通道，输入参数是上一步生成的创建通道请求CreateChannelRequest。

·第5步：HFC SDK转换创建通道的请求CreateChannelRequest，生成HeaderType_CONFIG_UPDATE类型的交易common.Payload。

·第6步：HFC SDK对common.Payload进行签名，签名者需要有通道创建的管理员权限。

·第7步：通过Orderer实例发送SendBroadcast请求，提交请求给排序服务节点。

·第8步：排序服务节点会检查提交的请求，校验是否有权限创建新的通道，创建通道以后排序服务节点就可以接收新通道的请求了。详细的内容请参考第6章。

3.Peer节点加入通道

创建通道完成以后，排序服务节点上就有了新通道的基本信息，可以对新通道的交易进行排序打包生成区块了。下一步需要把Peer加入到新通道中，应用程序或者客户端才能通过Peer节点发起交易请求。

Peer节点加入通道时需要先从排序服务节点获取创世区块，再在本地Peer节点初始化链，各个组件之间的交互如下。

·第1步：必要的初始化配置，比如创建FabricClient实例，设置发起加入通道请求的用户、Channel实例、Orderer实例等。

·第2步：调用GenesisBlock的请求获取创世区块，Channel实例会构造HeaderType_DELIVER_SEEK_INFO的请求，通过Orderer实例发送SendDeliver请求给排序服务节点，获取该通道的创世区块。

·第3步：应用程序利用获取到的创世区块构造JoinChannelRequest请求，通过Channel实例发起JoinChannel请求。

·第4步：HFC SDK的JoinChannel操作会根据JoinChannelRequest请求重新构造类型为 HeaderType_ENDORSER_TRANSACTION的Proposal，Proposal会用FabricClient实例设置的用户进行 签名，生成SignedProposal。

·第5步：需要为每个加入通道的Peer节点创建一个Peer实例，通过Peer实例调用ProcessProposal向Peer节点发送加入通道的SignedProposal。

·第6步：SignedProposal是调用CSCC 的JoinChain请求，Peer节点接收到SignedProposal请求后会调用CSCC进行必要的消息有效性检查和权限检查，然后在本地 Peer节点初始化链。初始化的过程会根据通道名称在本地目录创建账本数据，写入通道的创世区块，账本数据的目录结构请参考第5章。

·第7步：创建好通道的本地账本以后，Peer节点会启动Gossip服务从排序服务节点同步最新的区块数据。根据Peer节点的配置，参与主节点的选举或者直接作为主节点进行Peer节点之间的P2P通信，详细的过程参考第4章。

·第8步：Peer节点完成初始化链以后就可以接收新链的交易请求了。

4.通过Peer节点实例化链码

Peer节点加入到通道以后，需要部署链码才能模拟执行智能合约的功能。安装链码的过程相对比较简单，第9章已经介绍过。下面直接讨论实例化链码的流程，如图10-7所示。

安装链码只是把包含链码源码的ChaincodeDeploymentSpec上传到Peer节点，并没有进行初 始化。实例化链码的时候才会创建链码镜像，启动链码容器并调用链码的Init接口初始化，生成的交易会发送给排序服务节点生成区块记录到账本中。各个组件 之间的交互过程如下。

·第1步：实例化操作需要创建多个实例，包含FabricClient实例、User实例、Channel实例、Peer实例等。

·第2步：通过调用Channel实例的SendInstantiateProposal进行链码实例化。

·第3步：HFC SDK会构造包含ChaincodeDeploymentSpec的ChaincodeInvocationSpec，调用的是LSCC的deploy请求，详细的结构请参考第9章。

·第4步：发送给Peer节点的请求同样会用Channel关联的用户进行签名，通过Peer实例的ProcessTransactionProposal提交生成的SignedProposal。

·第5步：每次给Peer节点发送SignedProposal的时候都会新建一个gRPC的连接，通过ProcessProposal接口提交请求。

·第6步：Peer节点通过SignedProposal进行验证以后，会调用LSCC执行链码部署的操作，详细的过程请参考第9章。

·第7步：Peer节点返回的只是背书节点模拟执行和背书签名的结果，还需要提交给排序服务节点生成最终的区块才能生效，调用的过程同Peer节点接入通道的过程。

·第8步：生成的新区块会通过主节点分发给组织内的其他Peer节点，详细的内容请参考第4章。

5.发起交易请求并生成区块

实例化链码的过程本身也是一种交易，所以发起交易请求的过程和上一节的过程非常类似，如图10-8所示。

这里只讨论和上一节实例化链码过程不同的几个地方。

·普通的交易请求调用链码的Invoke接口，实例化链码调用的是Init接口。

·普通的交易请求是不嵌套的ChaincodeInvocationSpec请求，包含通道的名称和调用链码的函数和参数等。

·实例化链码的时候才开始构建链码镜像并启动链码容器，所以实例化链码的过程都比较慢。调用链码的背书节点已经启 动了链码容器，所以调用链码的过程是比较快的，除非链码的功能比较复杂或者出于系统的原因。第一次接收调用链码请求的背书节点会自动构建链码镜像并启动链 码容器，返回结果的时间会比较长。

来源：我是码农，转载请保留出处和链接！

本文链接：http://www.54manong.com/?id=1052

'); (window.slotbydup = window.slotbydup || []).push({ id: "u3646208", container: s }); })();

'); (window.slotbydup = window.slotbydup || []).push({ id: "u3646147", container: s }); })();