前言

本部分主要讲解智能合约的部署，已经commercial paper部分的使用和代码解析

end users通过调用智能合约与区块链分类账进行交互。在Hyperledger Fabric中，智能合约部署在称为chaincode的程序包中。想要验证交易或查询分类帐的组织需要在其peer上安装chaincode。在已加入channel的peer上安装 chaincode后，通道成员可以将链码部署到通道，并使用链码中的智能合约在通道分类帐上创建或更新资产。
使用称为Fabric chaincode lifecycle的程序将链码部署到通道。Fabric chaincode lifecycle允许多个组织在使用链码创建事务之前就如何操作链码达成共识。例如，虽然背书策略指定哪些组织需要执行链码以验证交易，但渠道成员需要使用Fabric链码生命周期来同意链码背书策略。

应用部署

使用 fabric-sample 中的示例 commercial-paper 和 asset-transfer-basic 来进行演示

首先要先启动测试网络 test-network ，并创建通道 mychannel

网络中将有两个组织org1和org2（）以及一个排序节点order

日志监控

在开始进行完整的商业流程实现之前，需要Logspout工具以便监控过程中所有的日志信息

启动

1 2	$ cd fabric-sample/commercial-paper/organization/digibank/configuration/cli/monitordocker.sh $ ./monitordocker.sh fabric_test

chaincode

设置环境变量，让Org1以admin用户的身份使用 peer 指令操作链码

$ export CORE_PEER_TLS_ENABLED=true
$ export CORE_PEER_LOCALMSPID="Org1MSP"
$ export CORE_PEER_TLS_ROOTCERT_FILE=${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt
$ export CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp
$ export CORE_PEER_ADDRESS=localhost:7051

链码部署过程：package - install - approveformyorg - commit
查看部署情况：queryinstalled - checkcommitreadiness - querycommitted

打包智能合约

此处以go语言为例，使用目录 fabric-samples/asset-transfer-basic/chaincode-go 下的智能合约

go.mod：列出合约依赖项
- 将Fabric合约API导入到智能合约包中。
- 可以asset-transfer-basic/chaincode-go/chaincode/smartcontract.go在文本编辑器中打开以查看如何SmartContract在智能合约开始时使用合约API定义类型

安装合约依赖关系

1 2	$ cd fabric-samples/asset-transfer-basic/chaincode-go $ GO111MODULE=on go mod vendor

使用 peer 指令打包所需链码

1 2	$ export PATH=${PWD}/../../bin:$PATH $ export FABRIC_CFG_PATH=$PWD/../../config/

主要是指出bin和config两个二进制文件夹所在的位置（fabric-sample目录下）
根据你的当前位置写路径

1	$ peer lifecycle chaincode package basic.tar.gz --path ./ --lang golang --label basic_1.0

参数：
- basic.tar.gz：打包后的文件名
- –path：提供智能合约代码的位置
  - 当前位置 fabric-sample/asset-transfer-basic/chaincode-go 的相对路径
- –lang：指定链码语言
- –label：指定一个链码标签，该标签将在安装后识别您的链码。
  - 建议您的标签包含链码名称和版本
此时已在当前路径下创建了一个链码包（basic.tar.gz），之后可以使用此包安装链码

部署智能合约到channel

安装chaincode包

使用 peer chaincode install 命令在对等方上安装链码

1	$ peer lifecycle chaincode install basic.tar.gz

如果命令成功，则对等方将生成并返回包标识符
此程序包ID将用于批准链码

根据fabric的背书策略，链码需要mychannel上认可交易的每个对等方安装链码，所以我们切换 peer 到Org2 admin用户

# 设置环境变量
$ export CORE_PEER_LOCALMSPID="Org2MSP"
$ export CORE_PEER_TLS_ROOTCERT_FILE=${PWD}/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt
$ export CORE_PEER_TLS_ROOTCERT_FILE=${PWD}/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt
$ export CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp
$ export CORE_PEER_ADDRESS=localhost:9051
# 安装链码包
$ peer lifecycle chaincode install basic.tar.gz

批准chaincode包

注意：

在部署链码之前需要批准链码的一组通道成员受 /Channel/Application/LifecycleEndorsement 策略控制。
- 默认情况下，此策略要求大多数频道成员需要批准链码后才能在频道上使用。因为渠道上只有两个组织，而2个中的大多数是2个，所以我们需要批准资产转移（基本）的链码定义为Org1和Org2。
如果组织已在其对等方上安装了链码，则他们需要在其组织批准的链码定义中包括packageID。程序包ID用于将对等方上安装的链码与批准的链码定义相关联，并允许组织使用链码对交易进行背书。您可以使用对 peer lifecycle chaincode queryinstalled 命令来查询对等节点，从而找到链代码的程序包ID 。

查询安装的链码包的 PACKEDGE_ID

1
2
3

$ peer lifecycle chaincode queryinstalled
Installed chaincodes on peer:
Package ID: basic_1.0:(一串数字即为package id)

先在当前org2组织上批准链码包

# 设置环境变量
$ export CC_PACKAGE_ID=basic_1.0:(那串package id的数字)
# 批准
$ peer lifecycle chaincode approveformyorg -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --channelID mychannel --name basic --version 1.0 --package-id $CC_PACKAGE_ID --sequence 1 --tls --cafile "${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem"

参数：
- –tls：是否启动tls
- –cafile：ca证书的路径
- –channelID：智能合约安装的通道名称
- –name：合约名称
- –version：合约版本
- –package-id：在链码定义中包含程序包标识符
- –sequence：一个整数，用于跟踪已定义或更新链码的次数
  - 由于链码是第一次部署到通道，因此序列号为1。升级链码时，序列号将增加为2。
  - –init-required：如果使用的是提供的低级API通过Fabric Chaincode Shim API，您可以使用此标志传递给上面的命令，以请求执行Init函数来初始化链码。
  - –isInit：链代码的第一次调用需要以Init函数为目标并包括该--isInit标志，然后才能使用链代码中的其他函数与分类帐进行交互。
- --signature-policy / –channel-config-policy：指定链码背书策略
  - 默认背书策略是需要得到channel上的大多数成员的认可
- –waitForEvent：等待peer提交交易返回
- –init-required：合约是否必须执行init

切换 peer 到Org1 admin用户来批准之前安装的链码包

$ export CORE_PEER_LOCALMSPID="Org1MSP"
$ export CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp
$ export CORE_PEER_TLS_ROOTCERT_FILE=${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt
$ export CORE_PEER_ADDRESS=localhost:7051
$ peer lifecycle chaincode approveformyorg -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --channelID mychannel --name basic --version 1.0 --package-id $CC_PACKAGE_ID --sequence 1 --tls --cafile "${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem"

虽然只有大多数组织需要批准链码定义（具有默认策略），但是所有组织都需要批准链码定义才能在其对等方启动链码。
如果您在渠道成员批准链码之前提交定义，则组织将无法批准交易。所以，建议所有通道成员在提交链码定义之前批准链码。

提交链码定义

在足够多的组织批准了链码定义之后，一个组织可以将链码定义提交给渠道。如果大多数通道成员已批准该定义，则提交事务将成功，并且链码定义中同意的参数将在该通道上实现。

查看channel成员是否已经批准了此链码

$ peer lifecycle chaincode checkcommitreadiness --channelID mychannel --name basic --version 1.0 --sequence 1 --tls --cafile "${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem" --output json

此命令标志与批准链码的标志 approveformyorg 相同，所以不需要 --package-id 标志。

该命令将生成一个JSON映射，显示通道成员是否批准链码

{
  "Approvals": {
    "Org1MSP": true,
    "Org2MSP": true
  }
}

当多数人都批准了之后，管理员就可以将链码定义提交到channel

$ peer lifecycle chaincode commit -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --channelID mychannel --name basic --version 1.0 --sequence 1 --tls --cafile "${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem" --peerAddresses localhost:7051 --tlsRootCertFiles "${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt" --peerAddresses localhost:9051 --tlsRootCertFiles "${PWD}/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt"

参数：
- –tls：是否启动tls
- –channelID：智能合约安装通道
- –name：合约名
- –version：合约版本
- –cafile：ca证书路径
- –peerAddresses：节点路径，上面标示peer0.org1.example.com从Org1和peer0.org2.example.comOrg2进行定位。
- –tlsRootCertFiles：节点ca根证书路径
  - --peerAddresses --tlsRootCertFiles 连用，可多个节点，多个节点即将合约部署到对应节点集合上
- –package-id：queryinstalled查询的合约ID
- –sequence：序列号
- –waitForEvent：等待peer提交交易返回
- –init-required：合约是否必须执行init
该commit交易被提交到加入该频道来查询被批准经营的同行组织的chaincode定义的peer。该命令需要针对足够数量的组织中的对等方，以满足部署链码的策略。由于批准是在每个组织内分配的，因此您可以定位属于渠道成员的任何对等方。
通道成员对链码定义的 approve 将提交给ordering service，以添加到区块中并分发给通道。然后，通道上的对等方将验证是否有足够的组织批准了链码定义。peer lifecycle chaincode commit命令将在返回响应之前等待对等方的验证。

确认chaincode定义已提交给channel

$ peer lifecycle chaincode querycommitted --channelID mychannel --name basic --cafile "${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem"
# 返回 sequence 和 version
Committed chaincode definition for chaincode 'basic' on channel 'mychannel':
Version: 1.0, Sequence: 1, Endorsement Plugin: escc, Validation Plugin: vscc, Approvals: [Org1MSP: true, Org2MSP: true]

调用合约

fabric智能合约操作主要有 invoke 跟 query

调用链码 InitLedger 方法

$ peer chaincode invoke -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls --cafile "${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem" -C mychannel -n basic --peerAddresses localhost:7051 --tlsRootCertFiles "${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt" --peerAddresses localhost:9051 --tlsRootCertFiles "${PWD}/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt" -c '{"function":"InitLedger","Args":[]}'

查询集合

1	$ peer chaincode query -C mychannel -n basic -c '{"Args":["GetAllAssets"]}'

合约升级

1
2
3

$ 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
$ peer chaincode upgrade -o orderer.example.com:7050 --tls --cafile $ORDERER_CA -C mychannel -n basic -v 1.2 -c '{"Args":["init","a","100","b","200","c","300"]}' -P "AND ('Org1MSP.peer','Org2MSP.peer')"

CouchDB

CouchDB与对等方一起作为独立的数据库进程运行

需要为每个对等方设置一个CouchDB容器，并通过更改配置文件core.yaml以指向CouchDB容器来更新每个对等方容器。该core.yaml 文件必须位于环境变量FABRIC_CFG_PATH指定的目录中：

对于Docker部署，它core.yaml是预先配置的，位于对等容器FABRIC_CFG_PATH文件夹中。但是，在使用Docker环境时，您可以传递环境变量以覆盖core.yaml属性，例如CORE_LEDGER_STATE_COUCHDBCONFIG_COUCHDBADDRESS，设置CouchDB地址。
对于本机二进制部署，core.yaml包含在发布工件分发中。

编辑的stateDatabase部分core.yaml。指定CouchDB为 stateDatabase并填写关联的couchDBConfig属性。有关更多信息，请参见CouchDB配置。

Channel

建立通道

peer create channel

添加组织到通道

更新通道配置

commercial-paper

启动网络

1 2	$ cd fabric-samples/commercial-paper $ ./network-starter.sh

可以使用 docker ps 命令查看本地计算机上运行的Fabric节点

1 2	$ cd commercial-paper/organization/magnetocorp/configuration/cli $ ./monitordocker.sh fabric_test <port_number>

在新的窗口下监视 MagnetoCorp 的日志信息

部署智能合约

在papercontract被应用程序调用之前，必须将其安装到测试网络的适当对等节点上，然后使用 peer lifecycle 在通道上进行定义。Fabric链码生命周期允许多个组织在将链码部署到通道之前就链码的参数达成一致。因此，我们需要以MagnetoCorp和DigiBank的管理员身份安装和批准链式代码。

打包智能合约为文件 cp.tar.gz

1
2
3

$ cd commercial-paper/organization/magnetocorp
$ source magnetocorp.sh
$ peer lifecycle chaincode package cp.tar.gz --lang node --path ./contract --label cp_0

在 magnetocorp 的目录下，第二条命令用来设置示例所需的环境变量

在channel上安装智能合约

1	$ peer lifecycle chaincode install cp.tar.gz

批准合约

# 查询package id
$ peer lifecycle chaincode queryinstalled
Installed chaincodes on peer:
Package ID: cp_0:(一串数字即为package id)
# 设置package id环境变量
$ export PACKAGE_ID=cp_0:(那串package id的数字)
# 运行命令批准合约
$ peer lifecycle chaincode approveformyorg --orderer localhost:7050 --ordererTLSHostnameOverride orderer.example.com --channelID mychannel --name papercontract -v 0 --package-id $PACKAGE_ID --sequence 1 --tls --cafile $ORDERER_CA

再以 DigiBank 的身份部署合约

# 打包合约
$ cd commercial-paper/organization/digibank/
# 安装合约
$ source digibank.sh
$ peer lifecycle chaincode package cp.tar.gz --lang node --path ./contract --label cp_0
$ peer lifecycle chaincode install cp.tar.gz
# 查询设置package id
$ peer lifecycle chaincode queryinstalled
$ export PACKAGE_ID=cp_0:...
# 批准合约
$ peer lifecycle chaincode approveformyorg --orderer localhost:7050 --ordererTLSHostnameOverride orderer.example.com --channelID mychannel --name papercontract -v 0 --package-id $PACKAGE_ID --sequence 1 --tls --cafile $ORDERER_CA

提交链码到channel

查看通道上 approve 的情况，是否满足 commit 的条件

1	$ peer lifecycle chaincode checkcommitreadiness --channelID mychannel --name papercontract --version 0 --sequence 1

当 MagnetoCorp 和 DigiBank 均批准了链码之后，我们就可以提交链码定义了

$ peer lifecycle chaincode commit -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --peerAddresses localhost:7051 --tlsRootCertFiles ${PEER0_ORG1_CA} --peerAddresses localhost:9051 --tlsRootCertFiles ${PEER0_ORG2_CA} --channelID mychannel --name papercontract -v 0 --sequence 1 --tls --cafile $ORDERER_CA --waitForEvent

查看提交的链码

# 1. 查看通道 mychannel 上安装了哪些链码
$ peer lifecycle chaincode querycommitted -C mychannel
# 输出：
Committed chaincode definitions on channel 'mychannel':
Name: papercontract, Version: 0, Sequence: 1, Endorsement Plugin: escc, Validation Plugin: vscc

# 2. 查看通道 mychannel 上安装的链码 papercontract 的详情
$ peer lifecycle chaincode querycommitted -C mychannel --name papercontract
# 输出：
Committed chaincode definition for chaincode 'papercontract' on channel 'mychannel':
Version: 0, Sequence: 1, Endorsement Plugin: escc, Validation Plugin: vscc, Approvals: [Org1MSP: true, Org2MSP: true]

-C / –channelID：通道名称
–name：链码名称

更新链码

在fabric2.0新增的命令peer lifecycle chaincode下，链码更新的步骤和部署链码的步骤相同。

sequence：版本，表示这是本链码的第几个版本
version：版本号，表示本链码此版本的版本号
比如下面演示部分就是将链码更新为版本号为1的第二个版本

打包成版本 1.0

1
2
3

$ cd commercial-paper/organization/magnetocorp
$ source magnetocorp.sh
$ peer lifecycle chaincode package cp.tar.gz --lang node --path ./contract --label cp_1

安装链码 1.0 版本

1	$ peer lifecycle chaincode install cp.tar.gz

批准链码

# 查询package id
$ peer lifecycle chaincode queryinstalled
Installed chaincodes on peer:
Package ID: cp_1:(一串数字即为package id)
# 设置package id环境变量
$ export PACKAGE_ID=cp_1:(那串package id的数字)
# 运行命令批准合约
$ peer lifecycle chaincode approveformyorg --orderer localhost:7050 --ordererTLSHostnameOverride orderer.example.com --channelID mychannel --name papercontract -v 1 --package-id $PACKAGE_ID --sequence 2 --tls --cafile $ORDERER_CA

注意，此处版本号为1，因为是第二个版本，所以 sequence 为2

如果要在 DigiBank 上也更新的话，需要执行相同的流程

# 打包合约
$ cd commercial-paper/organization/digibank/
# 安装合约
$ source digibank.sh
$ peer lifecycle chaincode package cp.tar.gz --lang node --path ./contract --label cp_1
$ peer lifecycle chaincode install cp.tar.gz
# 查询设置package id
$ peer lifecycle chaincode queryinstalled
$ export PACKAGE_ID=cp_1:...
# 批准合约
$ peer lifecycle chaincode approveformyorg --orderer localhost:7050 --ordererTLSHostnameOverride orderer.example.com --channelID mychannel --name papercontract -v 1 --package-id $PACKAGE_ID --sequence 2 --tls --cafile $ORDERER_CA

提及更新后的链码
- 只有下载并提交了新链码的peer才能使用新链码，否则依然使用旧链码

# 查看 approve 的情况
$ peer lifecycle chaincode checkcommitreadiness --channelID mychannel --name papercontract --version 1 --sequence 2
# 提交
$ peer lifecycle chaincode commit -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --peerAddresses localhost:7051 --tlsRootCertFiles ${PEER0_ORG1_CA} --peerAddresses localhost:9051 --tlsRootCertFiles ${PEER0_ORG2_CA} --channelID mychannel --name papercontract -v 1 --sequence 2 --tls --cafile $ORDERER_CA --waitForEvent

之后调用链码 papercontract时便是使用的更新后的版本

应用结构及代码

每次运行 Application 前，都需要删除 identity 文件夹，清除上次运行分发的身份，重新enroll当前网络

MagnetoCorp

目录：fabric-samples/commercial-paper/organization/magnetocorp/application

安装依赖

1	$ npm install

注册用户，生成用户钱包

1	$ node enrollUser.js

发行commercial paper

1	$ node issue.js

DigiBank

目录：fabric-samples/commercial-paper/organization/digibank/application

安装依赖

1	$ npm install

注册用户，生成用户钱包

1	$ node enrollUser.js

购买commercial paper

1	$ node buy.js

赎回

1	$ node reedem.js

Application

应用程序提交交易步骤：

（前提是用户已经加入到网络中，拥有了一个身份）
从钱包中选择一个身份
连接到网关
访问所需的网络
构建智能合约的交易请求
将交易提交到网络
处理回应

代码框架：

const { Wallets, Gateway } = require('fabric-network');
async function main(){
	  // 得到钱包
    const wallet = await Wallets.newFileSystemWallet('../identity/user/isabella/wallet');
    // 接入网关
		const gateway = new Gateway();
    try {
        const userName = 'isabella.issuer@magnetocorp.com';
        let connectionProfile = yaml.safeLoad(fs.readFileSync('../gateway/connection-org2.yaml', 'utf8'));
        let connectionOptions = {
		  		  identity: userName,
		  	   	wallet: wallet,
			  	  discovery: { enabled:true, asLocalhost: true }
	  	  };
	  	  await gateway.connect(connectionProfile, connectionOptions); 
        ...
	  }
}

Wallet
- 钱包包含一组身份（X.509数字证书），可用于访问PaperNet或任何其他Fabric网络

Gateway
- 网关标识一个或多个对等网络，这些对等网络提供对网络的访问权限 - 示例中的PaperNet
- 负责使用连接配置文件和连接选项将交易建议发送到网络中正确的对等节点
  1
  await gateway.connect(connectionProfile, connectionOptions);
  - connectionProfile：连接配置文件的系统位置，该配置文件将一组对等方标识为PaperNet的网关
    1
    2
    // 加载并转换为JSON对象
    let connectionProfile = yaml.safeLoad(fs.readFileSync('../gateway/connection-org2.yaml', 'utf8'));
  - connectionOptions：用于控制 issue.js 与PaperNet交互方式的一组选项

Contract

目录结构：

lib：主要的paper相关操作
- paper.js：定义 commercial paper 相关属性的set、get、is…和相关静态方法（序列化、反序列化等）
  1
  class CommercialPaper extends State {}
- papercontract.js：定义了交易逻辑（此处包括issue、buy、redeem、transfer等）
  1
  2
  class CommercialPaperContext extends Context {}
  class CommercialPaperContract extends Contract {}
  - CommercialPaperContext：创建并维护 paperList，用来定位到所需操作的paper
  - CommercialPaperContract：定义交易主要逻辑，在交易中完成paper的状态转移
- paperlist.js：维护 paperList 相关的方法 - add、get、update
  1
  class PaperList extends StateList {}

ledger-api：

state.js：主要控制 paper 的 stateClass 和 keyParts

statelist.js：根据paper的state和key来控制paperlist的状态，并调用fabric-contract-api与区块链交互

该类不存储任何单个状态或者状态列表，而是委派给Fabric数据库
这是一种重要的设计模式–减少了Hyperledger Fabric中分类账MVCC冲突的机会。

async addState(state) {
    let key = this.ctx.stub.createCompositeKey(this.name, state.getSplitKey());
    let data = State.serialize(state);
    await this.ctx.stub.putState(key, data);
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

  * **分类账**：每个状态数据都需要以下两个基本元素

    1. **密钥**：`key` 是 `createCompositeKey()` 使用固定名称和 `state` 的密钥形成的。
       * `this.name` 是在 `PaperList` 构造对象时分配的
       * `state.getSplitKey()`确定每个状态的唯一键。
    2. **数据**：`data `只是使用 `State.serialize()` 实用程序方法创建的commercial paper状态的序列化形式。
       *  `State` 类使用JSON来序列化和反序列化数据，state的对象类需要，在我们的例子`CommercialPaper`中， `PaperList` 对象构建时需要重定义。





# fabcar

提供了Fabric功能的广泛演示



## 











 

# 代码工具

[工具使用](http://cw.hubwiz.com/card/c/fabric-command-manual/1/1/27/)



## peer

[汇智网命令大全](http://cw.hubwiz.com/card/c/fabric-command-manual/1/1/1/)



有以下5个子命令

```shell
$ peer chaincode [option] [flags]
$ peer channel   [option] [flags]
$ peer logging   [option] [flags]
$ peer node      [option] [flags]
$ peer version   [option] [flags]

**通用 [flag]**：

–cafile string
- Path to file containing PEM-encoded trusted certificate(s) for the ordering endpoint
- 包含用于订购端点的PEM编码的受信任证书的文件的路径
–certfile string
- Path to file containing PEM-encoded X509 public key to use for mutual TLS communication with the orderer endpoint
- 包含用于与订购者端点进行相互TLS通信的PEM编码X509公钥的文件的路径
–clientauth
- Use mutual TLS when communicating with the orderer endpoint
–connTimeout duration
- Timeout for client to connect (default 3s)
-h, –help
- help for channel
–keyfile string
- Path to file containing PEM-encoded private key to use for mutual TLS communication with the orderer endpoint
- 包含用于与订购者端点进行相互TLS通信的PEM编码的私钥的文件的路径
-o, –orderer string
- Ordering service endpoint
- 订购服务端点指定为 <hostname or IP address>:<port>
–ordererTLSHostnameOverride string
- The hostname override to use when validating the TLS connection to the orderer.
- 验证与订购者的TLS连接时要使用的主机名覆盖
–tls
- Use TLS when communicating with the orderer endpoint
- 与订购者端点进行通信时使用TLS
–transient string
- JSON编码中的参数的瞬时映射

peer chaincode

peer chaincode invoke

peer chaincode query

peer chaincode install

peer chaincode instantiate

peer chaincode list

peer chaincode package

peer chaincode signpackage

peer chaincode upgrade

peer channel

peer channel list：列出当前组织所属的所有通道列表

peer lifecycle chaincode

包含以下子命令:

package：打包链码
*
install：安装链码
*
queryinstalled：查询指定peer节点上已经安装的链码
approveformyorg：批准链码定义
*
checkcommitreadiness：检查链码是否可以向通道提交
*
commit：向通道提交链码定义
*
querycommitted：按通道查询已经提交的链码定义
*
getinstalledpackage：从peer节点获取已经安装的链码包

可用标志:

–cafile string PEM编码的CA证书文件路径
–certfile string 双向TLS通讯所需的PEM编码的X509证书文件路径
–clientauth 与排序节点的通讯是否启用双向TLS
–connTimeout duration 客户端连接超时，默认值：3秒
-h, –help 帮助信息
–keyfile string 双向TLS通讯所需的PEM编码的私钥文件
-o, –orderer string 排序节点地址
–ordererTLSHostnameOverride string 验证TLS连接时使用的排序节点主机名
–tls 与排序节点通信时是否启用TLS