Hyperledger-Fabric

Hyperledger-Fabric安装开发部署(五)NodeJs-SDK详解

简介

  • 开发我们的区块链对外的API接口,实现之前我们在Cli中进行的查询数据、插入数据、查询区块信息、查询交易信息、安装链码等等,将这些操作统一写成对外开放的RUSTful Web API。
  • 本篇内容介绍的相关代码可能需要了解很多Nodejs相关的知识,还有许多NPM中的插件框架;诸如express、log4j、express-jwt等等。

官方英文版教程:
http://hyperledger-fabric.readthedocs.io/en/latest/index.html

官方Nodejs-SDK教程:
https://fabric-sdk-node.github.io/


1. 详解balance-transfer中Nodejs-SDK相关内容

这里我们的侧重点完全在于区块链相关的代码部分,其他如JWT、express等内容不做深究。
先简单介绍一下涉及到的相关文件:

此次讲解的重点全部在app文件夹内,看命名也能看出来相关功能。主要讲解balance-transfer项目内的相关代码;从WebAPI接口逐渐深入,解释一些常用方法的使用,说明相关Nodejs-SDK的功能及使用方法等。
注:[1]意为标注额外说明

1.1 Register and enroll user-注册用户

源码中标记此部分的title为【Register and enroll user】,起初不是很理解Register和enroll在歪果仁眼里有什么样的区别;后来略有深入便知道了区别,先吧这两个当做不同的概念看待,接下来会讲述。

API:http://localhost:5010/users
在helper.js中有一个getRegisteredUsers方法:

具体代码运行流程可以使用VScode调试功能逐步查阅;总结下来就是说如果需要注册一个用户,流程是:
1. 调用FabricCAClient.register()得到用户对应的secret;
2. 调用FabricCAClient.enroll(),传入对应用户与secret,得到用户对应的证书信息。

额外的方法还有:
FabricCAClient.reenroll()
重新给某用户颁发证书。

FabricCAClient.revoke()
撤销现有证书(注册证书或交易证书),或撤消发放给所有用户的证书。如果撤销特定的证书,则需要管理者密钥标识符和序列号。如果通过注册ID撤销,那么未来所有注册此ID的请求都将被拒绝。


[1]–‘/tmp/fabric-client-kvs’创建用户的时候会在这里生成三个文件,如下图:

‘qaz’是注册的用户名,另外两个文件就是一对公私钥。可以记事本打开qaz文件:

可以明显的看到’signingIdentity’所对应的value与其他两个文件名一致。
(此处公私钥观察下来不是同一时间生成的,具体有待之后深入考究)
这个文件夹内保存了相关证书信息。

1.2 调用ChainCode执行交易

这里可能是大部分人最关心的地方,怎么调用ChainCode。

api:http://localhost:5010/channels/mychannel/chaincodes/mycc
先找到app.js中如下的方法,这个api就是调用chaincode执行交易;

先看结果再讲过程:

有一个点需要说明一下,”fcn”:”invoke”,这个fcn对应的值在某一个版本是move而不是invoke;args就是传递的参数,a向b转1(在chaincode中已经定义好了)。

返回值是e16ed0b21094030d796ee210c0fd20922fdc099517ddf3c90f87b3a2a32bb0a8
这就是txid,在后边查询这比交易我们还会用到。


打开app/invoke-transaction.js,这里便是调用ChainCode执行交易的主方法:

总结一下其中的大概流程及其重点:
1. helper.getRegisteredUsers()//验证并获取一个用户
2. Client.newTransactionID()//生成一个txid
3. Channel.sendTransactionProposal()//传入对应的chennel、chaincode、方法名参数等信息,并将得到的结果验证处理。
4. EventHub.registerTxEvent()//注册一个事件,等待事务提交到块后返回
5. Channel.sendTransaction()//将包含交易信息的数据发送给orderer进行进一步处理


[2]–关于’helper.newEventHubs()’这里简单介绍一下,在helper.js中有如下代码:

1.3 调用ChainCode查询数据

这里依然是大部分人关心的地方,数据怎么查。

api:http://localhost:5010/channels/mychannel/chaincodes/mycc?peer=peer1&fcn=query&args=%5B%22b%22%5D
此API地址看起来和刚才的一样,只不过请求方式是get,歪果仁经常使用post、get、delete、put;国内大多统一使用post;

注意URL中最后的args=%5B%22b%22%5D,URLDecode后是args=[“b”];其他参数与上一个接口的雷同。
下图是执行结果:


查询的方法与上边执行交易的方法比较相似,我本地的这个版本的源码在此处有一个小BUG,无伤大雅,可以查看标注[3]。
打开app/query.js,这里便是调用ChainCode执行查询的主方法:

总结一下,简单说这里只有一个步骤:
1. Channel.queryByChaincode()//这里相对就很简单了,只有这一个重点

有了前边的基础,这里看起来就非常简单了


[3]–关于query.js中queryChaincode方法的一个bug,找到如下代码:

以下是修改后的代码:

可以明显的看到channel.queryByChaincode()其实只有一个参数,这一点与之前执行交易方法的代码相同,targets是一个数组所以在这里使用[target]赋值,道理和之前也一样,可以同时在多个节点上操作,并返回其对应的操作结果。

1.4 使用txid查询

这一步在整个区块链中也是非常重要的一个环节,查询验证每一次的交易。
在1.2 中我们执行了一笔交易得到一个返回值
e16ed0b21094030d796ee210c0fd20922fdc099517ddf3c90f87b3a2a32bb0a8

来试一试能否查询到结果:
API:http://localhost:5010/channels/mychannel/transactions/e16ed0b21094030d796ee210c0fd20922fdc099517ddf3c90f87b3a2a32bb0a8?peer=peer1

返回了一个非常复杂的json,这个json建议查看官方教程学习,这里我们继续分析代码。
打开query.js,找到如下方法:

1.5 Chaincode安装更新

在真实的项目中我们可能要频繁的更新升级智能合约,以便于符合我们新的业务。

Fabric的智能合约是有版本管理的,可以用同样的chaincode名称(如mycc),但是拥有不同的版本号,区分调用,不同的节点也可以使用不同版本的chaincode,一个节点也可以加入数个chaincode。

新的chaincode必须被安装、实例后才可以使用,并且实例化的时候会调用对应chaincode中Init()方法。

chaincode还有一个操作是更新,但是更新在此项目中没有对应代码,也是比较简单的,使用”Channel.sendUpgradeProposal()”类似于实例化的过程,前提也是链码已经安装。

有了以上的基础相信自己写一个更新chaincode并不难。

更新chaincode的流程可以参照【1.2 调用ChainCode执行交易】来做,必须要调用sendTransaction()方法。
和1.2流程相同的有4种,如SDK原文所示:

sendTransaction(request)
Send the proposal responses that contain the endorsements of a transaction proposal to the orderer for further processing. This is the 2nd phase of the transaction lifecycle in the fabric. The orderer will globally order the transactions in the context of this channel and deliver the resulting blocks to the committing peers for validation against the chaincode’s endorsement policy. When the committering peers successfully validate the transactions, it will mark the transaction as valid inside the block. After all transactions in a block have been validated, and marked either as valid or invalid (with a reason code), the block will be appended (committed) to the channel’s ledger on the peer.

The caller of this method must use the proposal responses returned from the endorser along with the original proposal that was sent to the endorser. Both of these objects are contained in the ProposalResponseObject returned by calls to any of the following methods:
installChaincode()
sendInstantiateProposal()
sendUpgradeProposal()
sendTransactionProposal()

下图的我在另一个项目中写个一个查询chaincode的API,可以看到peer1对应了好几个chaincode,并且有不同版本:

1.6 其他SDK

在balance-transfer项目中,还有很多API接口;诸如创建channel、peer加入channel、查询块信息等等,这些内容相对比较简单一些,由于时间等原因这里暂时不再继续对此项目分析讲解;
将写作的重点转意至Fabric其他方面(如概念的汇总、运行的流程、基本原理等),SDK的深入留给大家慢慢自己拓展。


关于SDK能说的东西其实还是非常多的,如果有哪部分的流程不熟悉,可以留言,会后续补充对应的SDK内容。

.
.
.
.
.
.
.
.
【本文章出自NM1024.com,转载请注明作者出处。】

4 thoughts on “Hyperledger-Fabric安装开发部署(五)NodeJs-SDK详解”

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据