Fabric1.4：链码管理与测试

1 链码介绍

智能合约在 Hyperledger Fabric 中称为链码（chaincode），是提供分布式账本的状态处理逻辑。链码被部署在fabric 的网络节点中，能够独立运行在具有安全特性的受保护的 Docker 容器中，以 gRPC 协议与相应的 peer 节点进行通信，以操作分布式账本中的数据。

一般链码分为两种：系统链码和用户链码。

1.1 系统链码

负责 Fabric 节点自身的处理逻辑，包括系统配置、背书、校验等工作，在 Peer 节点启动时会自动完成注册和部署。系统链码分为以下五种：

  • 配置系统链码（Configuration System Chaincode，CSCC）：负责处理 Peer 端的 Channel 配置；
  • 生命周期系统链码（Lifecycle System Chaincode，LSCC）：负责对用户链码的生命周期进行管理；
  • 查询系统链码（Query System Chaincode，QSCC）： 提供账本查询 API。如获取区块和交易等信息；
  • 背书管理系统链码（Endorsement System Chaincode，ESCC）：负责背书(签名)过程, 并可以支持对背书策略进行管理；
  • 验证系统链码（Validation System Chaincode，VSCC）：处理交易的验证，包括检查背书策略以及多版本并发控制。

1.2 用户链码

用户链码不同于系统链码，系统链码是 fabric 的内置链码，而用户链码是由应用程序开发人员根据不同场景需求编写的基于分布式账本的状态的业务处理逻辑代码，运行在链码容器中，通过 Fabric 提供的接口与账本状态进行交互。

用户链码向下可对账本数据进行操作，向上可以给企业级应用程序提供调用接口。

1.3 链码生命周期

管理 Chaincode 的生命周期共有五个命令：

  • install：将已编写完成的链码安装在网络节点中；
  • instantiate：对已安装的链码进行实例化；
  • upgrade：对已有链码进行升级，链代码可以在安装后根据具体需求的变化进行升级；
  • package：对指定的链码进行打包的操作。
  • singnpackage：对已打包的文件进行签名。

2 链码的使用

我们使用 fabric v1.4.3 版本的 fabric-samples 提供的 first-network 网络进行说明，修改 first-network/scripts/script.sh 脚本中的下列代码：

# 将判断语句中的 true 改为 false，first-network 网络就不会进行链码的安装、实例化等操作
if [ "${NO_CHAINCODE}" != "false" ]; then
    ## Install chaincode on peer0.org1 and peer0.org2
    echo "Installing chaincode on peer0.org1..."
    installChaincode 0 1
    echo "Install chaincode on peer0.org2..."
    installChaincode 0 2
    #...
    #...
fi

启动 first-network 网络：

$ ./byfn.sh up

进入 CLI 客户端容器，CLI 客户端默认以 Admin.org1 身份连接 peer0.org1 节点：

$ docker exec -it cli bash

检查当前节点（peer0.org1.example.com）以加入哪些通道：

# peer channel list

执行结果返回：

Channels peers has joined:
mychannel

说明当前节点已经加入通道 mychannel。

2.1 安装链码

使用 install 命令安装链码：

# peer chaincode install -n mycc -v 1.0 -p github.com/chaincode/chaincode_example02/go/
  • -n： 指定要安装的链码的名称
  • -v： 指定链码的版本
  • -p： 指定要安装的链码源代码的所在路径

执行结果返回：

[chaincodeCmd] install -> INFO 04c Installed remotely response:<status:200 payload:"OK" >

说明链码成功安装至 peer 节点中。

注意：链码需要根据指定的背书策略安装在需要背书的所有 peer 节点中。未安装链码的节点不能执行链码逻辑，但仍可以验证交易并提交到账本中。

2.2 实例化链码

设置通道名称的环境变量：

# export CHANNEL_NAME=mychannel
# echo $CHANNEL_NAME

设置 orderer 节点的证书路径的环境变量：

# export ORDERER_CA=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
# echo $ORDERER_CA

使用 instantiate 命令进行链码的实例化：

# peer chaincode instantiate -o orderer.example.com:7050 --tls --cafile $ORDERER_CA -C $CHANNEL_NAME -n mycc -v 1.0 -c '{"Args":["init","a", "100", "b","200"]}' -P "OR ('Org1MSP.peer','Org2MSP.peer')"
  • -o： 指定 Oderer 服务节点地址
  • --tls： 开启 TLS 验证
  • --cafile： 指定 TLS_CA 证书的所在路径
  • -n： 指定要实例化的链码名称，必须与安装时指定的链码名称相同
  • -v： 指定要实例化的链码的版本号，必须与安装时指定的链码版本号相同
  • -C： 指定通道名称
  • -c： 实例化链码时指定的参数
  • -P： 指定背书策略

背书策略的背书实体一般表示为：MSP.ROLE，其中 MSP 是 MSP ID，ROLE 支持 client、peer、admin 和 member 四种角色。 例如： Org1MSP.admin 表示 Org1 这个 MSP 下的任意管理员; Org1MSP.member 表示 Org1 这个 MSP 下的任意成员。

背书策略语法结构如下：

// 基础表达式形式，EXPR 可以是 AND、OR 和 OutOf 逻辑符，E 是实体或者嵌套的表达式
EXPR(E[, E...])
// 需要三个组织 org1、org2 和 org3 的 member 共同背书签名
AND('Org1MSP.member', 'Org2MSP.member', 'Org3MSP.member')
// 需要 org1 和 org2 其中一个组织的 member 背书签名
OR('Org1MSP.member', 'Org2MSP.member')
// 需要 Org1 的 admin 背书，或者 Org2 和 Org3 下的 member 共同背书签名
OR('Org1MSP.admin', AND('Org2MSP.member', 'Org3MSP.member'))
// 需要 org1、org2、org3 的 member 的至少两个背书签名
OutOf(2, 'Org1MSP.member', 'Org2MSP.member', 'Org3MSP.member')

注意：链码需要安装在多个背书的 Peer 节点中，但实例化只需执行一次。

2.3 查询链码

链码部署成功之后，可以通过特定的命令调用链码，从而发起交易或查询请求，对账本数据进行操作。

使用 query 命令查询链码：

# peer chaincode query -C $CHANNEL_NAME -n mycc -c '{"Args":["query","a"]}'
  • -n： 指定要调用的链码名称
  • -C： 指定通道名称
  • -c 指定调用链码时所需要的参数

执行成功后，返回输出结果 100。

2.4 调用链码

客户端发起交易，对账本数据进行更改，需要将背书之后的交易发送给排序节点上链。因此，需要开启 TLS 验证并指定对应的 orderer 证书路径。

需要注意，链码执行查询操作和执行事务（改变账本数据）操作的流程是不同的：

  • 链码查询操作：客户端接收到背书节点的交易提案响应后不会将交易请求提交给 Orderer 节点，即查询操作不需要上链，任选一个背书节点进行链码查询操作即可；
  • 链码事务操作：客户端先需要根据指定背书策略收集到足够的交易提案的背书签名，再将背书后的交易提交给 Orderer 节点，即事务操作的交易需要成块上链。

使用 invoke 命令调用链码：

# peer chaincode invoke -o orderer.example.com:7050 --tls --cafile $ORDERER_CA  -C $CHANNEL_NAME -n mycc -c '{"Args":["invoke","a","b","10"]}'
  • -o： 指定orderer节点地址
  • --tls： 开启TLS验证
  • --cafile： 指定TLS_CA证书路径
  • -n: 指定链码名称
  • -C： 指定通道名称
  • -c： 指定调用链码的所需参数

执行返回以下结果，说明交易执行成功：

[chaincodeCmd] chaincodeInvokeOrQuery -> INFO 04c Chaincode invoke successful. result: status:200

再次查询 a 账户的余额，如果执行结果返回 90，说明交易被正确执行了：

# peer chaincode query -C $CHANNEL_NAME -n mycc -c '{"Args":["query","a"]}'

注意：如果交易需要多个背书节点的背书，可以使用 --peerAddresses 标志指定节点。例如：交易需要 peer0.org1 和 peer0.org2 的共同背书：

# peer chaincode invoke -o orderer.example.com:7050 --tls --cafile $ORDERER_CA -C $CHANNEL_NAME -n mycc --peerAddresses peer0.org1.example.com:7051 --tlsRootCertFiles /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt --peerAddresses peer0.org2.example.com:9051 --tlsRootCertFiles /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt -c '{"Args":["invoke","a","b","10"]}'

2.5 链码的打包与签名

链码部署除了正常的安装、实例化操作步骤之外，还有一种部署方式，即先将链码进行打包，然后对已打包的文件进行签名，最后再进行安装与实例的操作。

使用如下的命令进行打包操作：

# peer chaincode package -n exacc -v 1.0 -p github.com/chaincode/chaincode_example02/go/  -s -S -i "AND('Org1MSP.admin')" ccpack.out

参数说明：

  • -s： 创建一个可以被多个所有者签名的包
  • -S： 可选参数，使用 core.yaml 文件中被 localMspId 相关属性值定义的 MSP 对包进行签名
  • -i： 指定链码的实例化策略（指定谁可以实例化链码）

打包后的文件可以直接使用 install 命令安装，如：peer chaincode install ccpack.out，但是一般对打包后的文件签名再进一步安装。

使用如下的命令对打包文件进行签名操作（添加当前 MSP 签名到签名列表中）：

# peer chaincode signpackage ccpack.out signedccpack.out

signedccpack.out 包含一个用本地 MSP 对包进行的附加签名。

安装已签名的打包文件：

# peer chaincode install signedccpack.out

对已安装的链码进行实例化操作，指定背书策略：

# peer chaincode instantiate -o orderer.example.com:7050 --tls --cafile $ORDERER_CA -C $CHANNEL_NAME -n exacc -v 1.0 -c '{"Args":["init","a", "100", "b","200"]}' -P "OR ('Org1MSP.peer','Org2MSP.peer')"

测试：

使用如下命令查询链码，输出结果为 100：

# peer chaincode query -C $CHANNEL_NAME -n exacc -c '{"Args":["query","a"]}'

使用如下命令调用链码进行转账操作：

# peer chaincode invoke -o orderer.example.com:7050  --tls --cafile $ORDERER_CA  -C $CHANNEL_NAME -n exacc -c '{"Args":["invoke","a","b","10"]}'

使用如下命令再次查询链码，输出结果为 90：

# peer chaincode query -C $CHANNEL_NAME -n exacc -c '{"Args":["query","a"]}'

2.6 升级链码

首先，先对修改之后的链码进行安装：

# peer chaincode install -n mycc -v 2.0 -p github.com/chaincode/chaincode_example02/go/

然后，使用如下命令对已安装的链码进行升级：

# peer chaincode upgrade -o orderer.example.com:7050 --tls --cafile $ORDERER_CA -C $CHANNEL_NAME -n mycc -v 2.0 -c '{"Args":["init","a", "100", "b","200"]}' -P "OR ('Org1MSP.peer','Org2MSP.peer')"

测试：

使用如下命令查询链码，输出结果为 100：

# peer chaincode query -C $CHANNEL_NAME -n mycc -c '{"Args":["query","a"]}'

使用如下命令调用链码进行转账操作：

# peer chaincode invoke -o orderer.example.com:7050  --tls --cafile $ORDERER_CA  -C $CHANNEL_NAME -n mycc -c '{"Args":["invoke","a","b","10"]}'

使用如下命令再次查询链码，输出结果为 90：

# peer chaincode query -C $CHANNEL_NAME -n mycc -c '{"Args":["query","a"]}'

需要注意的是，升级过程中，chaincode 的 Init 函数会被调用以执行数据相关的操作，或者重新初始化数据；所以需要多加小心，以避免在升级 chaincode 时重设状态信息。

2.7 查看链码日志

使用 docker ps 命令可以查看到当前网络中有以下三个链码容器启动：

  • dev-peer0.org1.example.com-mycc-1.0
  • dev-peer0.org1.example.com-mycc-2.0
  • dev-peer0.org1.example.com-exacc-1.0

使用 docker logs 命令可以查看链码日志：

$ docker logs dev-peer0.org1.example.com-mycc-1.0
ex02 Init
Aval = 100, Bval = 200
ex02 Invoke
Query Response:{"Name":"a","Amount":"100"}
ex02 Invoke
Aval = 90, Bval = 210
ex02 Invoke
Query Response:{"Name":"a","Amount":"90"}
$ docker logs dev-peer0.org1.example.com-mycc-2.0
ex02 Init
Aval = 100, Bval = 200
ex02 Invoke
Query Response:{"Name":"a","Amount":"100"}
ex02 Invoke
Aval = 90, Bval = 210
ex02 Invoke
Query Response:{"Name":"a","Amount":"90"}
$ docker logs dev-peer0.org1.example.com-exacc-1.0
ex02 Init
Aval = 100, Bval = 200
ex02 Invoke
Query Response:{"Name":"a","Amount":"100"}
ex02 Invoke
Aval = 90, Bval = 210
ex02 Invoke
Query Response:{"Name":"a","Amount":"90"}

3 dev 模式下的链码测试

3.1 启动测试网络

上述过程是在 first-network 网络下的链码测试，但是该网络下的链码测试过于复杂，需要指定很多参数，如果只是想测试所编写的链码的正确性，可以使用 dev 开发模式。

进入 chaincode-docker-devmode 目录：

$ cd ./fabric-samples/chaincode-docker-devmode/

该目录下存在如下五个文件：

  • docker-compose-simple.yaml：网络启动依赖的配置文件，该配置文件中指定了四个容器，分别为：orderer、peer、cli、chaincode
  • msp：网络环境的 MSP，包含一系列的证书及私钥
  • myc.block：通道配置块文件
  • myc.tx：通道交易配置文件
  • orderer.block： 排序服务初始区块配置文件

使用如下命令启动网络：

$ docker-compose -f docker-compose-simple.yaml up -d
Creating network "chaincodedockerdevmode_default" with the default driver
Creating orderer ...
Creating orderer ... done
Creating peer ...
Creating peer ... done
Creating cli ...
Creating chaincode ...
Creating cli
Creating cli ... done

以开发模式开启 peer，还启动了两个容器：chaincode 容器，用于链码环境；CLI 容器，用于与链码进行交互，其中创建和连接通道的命令已经被嵌入 CLI 容器中了，所以可以直接进行链码调用。

3.2 构建并启动链码

使用如下命令进入 chaincode 容器 ：

$ docker exec -it chaincode bash

出现如下结果，则运行成功：

[email protected]:/opt/gopath/src/chaincode#

查看该 chaincode 容器的定义：

 chaincode:
    container_name: chaincode
    image: hyperledger/fabric-ccenv
    tty: true
    environment:
      - GOPATH=/opt/gopath
      - CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
      - FABRIC_LOGGING_SPEC=DEBUG
      - CORE_PEER_ID=example02
      - CORE_PEER_ADDRESS=peer:7051
      - CORE_PEER_LOCALMSPID=DEFAULT
      - CORE_PEER_MSPCONFIGPATH=/etc/hyperledger/msp
    working_dir: /opt/gopath/src/chaincode
    command: /bin/sh -c 'sleep 6000000'
    volumes:
        - /var/run/:/host/var/run/
        - ./msp:/etc/hyperledger/msp
        - ./../chaincode:/opt/gopath/src/chaincode
    depends_on:
      - orderer
      - peer

该容器的当前目录 /opt/gopath/src/chaincode 对应本地系统中的 ./../chaincode，我们使用该目录下的 chaincode_example02 链码进行测试。进入 chaincode_example02/go/ 目录编译链码：

# cd chaincode_example02/go/
# go build

使用如下命令启动并运行链码：

# CORE_PEER_ADDRESS=peer:7052 CORE_CHAINCODE_ID_NAME=mycc:0 ./go

命令含义：

  • CORE_PEER_ADDRESS：用于指定 peer，其中 7052 端口是链码的专用监听端口（7051 是 peer 节点监听的网络端口）
  • CORE_CHAINCODE_ID_NAME：用于注册到 peer 的链码
    • mycc： 指定链码名称
    • 0： 指定链码初始版本号
    • ./go： 指定链码文件

开启一个新的终端，使用如下命令进行 CLI 容器：

$ docker exec -it cli bash

进入 CLI 容器后，使用如下命令安装链码：

# peer chaincode install -p chaincodedev/chaincode/chaincode_example02/go -n mycc -v 0

使用如下命令实例化链码：

# peer chaincode instantiate -n mycc -v 0 -c '{"Args":["init","a", "100", "b","200"]}' -C myc

测试：

使用如下命令查询链码，输出结果为 100：

# peer chaincode query -n mycc  -c '{"Args":["query","a"]}' -C myc

使用如下命令调用链码进行转账操作：

# peer chaincode invoke -n mycc -c '{"Args":["invoke","a","b","10"]}' -C myc

使用如下命令再次查询链码，输出结果为 90：

# peer chaincode query -n mycc  -c '{"Args":["query","a"]}' -C myc

3.3 关闭测试网络

使用如下命令关闭测试网络：

$ docker-compose -f docker-compose-simple.yaml down

参考

  1. 《Hyperledger Fabric 菜鸟进阶攻略》

原文地址：https://www.cnblogs.com/zongmin/p/11842562.html

时间： 2024-10-11 18:32:15

Fabric1.4：链码管理与测试的相关文章

如何管理好测试团队

如何管理好测试团队 1.作为一个团队的管理者,最起码的是要自己懂自己产品或项目的业务.这一点很重要,第一这样有助自己分配工作给团队中的成员,要不然自己都搞不清楚业务难度和业量就分配工作给team member是件很让人难以接受的事情.第二,有助于自己和其它team或department的合作和沟通,不至于其它team提出的问题,自己还不清楚就答应或否定要做. 2.作为一个管理者,要懂更多的技术,至少是了解更多的测试技术,要了解其工作原理,这样有助于自己帮助团队成员research或者说技术的应用

Android 内存溢出管理与测试

今天发现正在做的项目,时不时的会报错:dalvikvm heap out of memory on a 7458832-byte allocation (堆分配的内存溢出) 为什么会内存溢出呢?我以前从未遇见这种情况.后来在网上查了查资料,还是挺多的. 怎么说呢?因为Android开发基本上是以java语言为基础,那么程序是在java虚拟机上运行的.而虚拟机不允许单个程序中的Bitmap占用超过8M的内存,从报错的日志可以看出:7458832-byte大约就是7M多的样子,基本吻合上述数据.在我

软件测试管理之测试度量

一.定义: 产生.分析.报告.采取行动的测试度量过少,且不具有实际意义 . 二.发生时间段 1.项目过大及复杂,需要管理. 2.一个或多个管理人员需要测试程序是可视的 三.陷阱表现 1.未产生.分析.报告或采取行动的及使用测试度量作为决策基础 2.主要测试度量不表现测试人员的工作效率 ,也不是团队发现缺陷的有效性. 只计算缺陷数量,不考虑初始缺陷密度. 只记录每个缺陷代价高的成本的初始质量,因当待发现的缺陷数量降低时,每个缺陷的成本升高. 3.仅计算开发并pass的测试的数量 ,不考虑测试规模和

内存管理[6]测试堆的内存占用情况

本例效果图: unit Unit1; interface uses   Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,   Dialogs, StdCtrls; type   TForm1 = class(TForm)     Button1: TButton;     Button2: TButton;     Memo1: TMemo;     Memo2: TMemo;     proce

测试管理工具列表大全

ID Name Notes 1 TestDirector/Quality Center 业界第一个基于Web的测试管理系统,它可以在您公司组织内进行全球范围内测试的协调.通过在一个整体的应用系统中提供并且集成了测试需求管理,测试计划,测试日程控制以及测试执行和错误跟踪等功能,TestDirector极大地加速测试过程.8.0后改称QC. 由于HP QC可以单独使用Defect模块,也可单独申请Defect模块的License,它也是名副其实的缺陷管理工具. 网址:http://www.mercu

测试管理平台大比拼

测试管理平台很多,在选择时也会想那个好用那个适合自己,在腾讯云tmq团队的分析下,为大家带来测试平台的综合评价. 作者:solinazhao 简介 测试管理平台是贯穿测试整个生命周期的工具集合,它主要解决的是测试过程中团队协作的问题,比如缺陷管理.用例管理.测试任务管理等. 目前市面上比较流行的测试管理工具有QC. Mantis. BugZilla.TestLink.Redmine等.有开源软件,也有商业软件.这些软件的各自侧重点不同:比如Mantis.BugZilla偏重缺陷管理,TestLi

学生管理App测试计划余测试矩阵

学生管理测试计划: 里程碑项目 开始时间 结束时间 测试规划 2017.4.1 2017.4.2 测试设计 2017.4.2 2017.4.3 测试设计实施 2017.4.4 2017.4.8 测试执行 2017.4.9 2017.4.11 测试总结 2017.4.12 2017.4.14 学生管理App测试矩阵:   用户类型 屏幕分辨率 操作系统 缺省语言 组合总数 变量数目 2 2 3 2 4   用户 720*1280 Android 中文     管理员 800*600 IOS 英文

华为软件开发云测评报告三：测试管理

往期文章: 华为软件开发云测评报告一:项目管理 华为软件开发云测评报告二:代码检查 体验环境 体验方式:PC端 系统:Windows 64位 浏览器类型:Chrome浏览器 浏览器版本:58.0.3029.110 体验时间:2017.07.06 分析目的 了解华为软件开发云的测试管理服务功能,分析其优缺点: 自动化测试工具未来的发展趋势: 产品简介 产品名称:华为软件开发云 定位:华为软件开发云(DevCloud)是集华为研发实践.前沿研发理念.先进研发工具为一体的研发云平台,面向开发者提供研发

常用测试管理工具对比

本文简介: 对于中小企业来说,选择一款适合的测试管理工具或者工具集合石走向规划管理的必经之路,本文从以下几个方面对目前流行的几款工具:1.QC(QC是TC的升级版,QC的升级版QC 11就是ALM11)2.禅道(bugfree升级版)3.mantis4.JIRA5.TestLink6.Bugzilla 从以下几个方面进行一个简单的对比,供大家参考.其中一些数据来之网上,不全和不对的地方欢迎大家回帖补充. 功能(1.原始需求管理2.测试需求管理3.测试用例管理4.测试过程管理(测试任务分配)5.B