Centos7 Fabric2.4 网络搭建（三）

提示：上一篇文章讲到创建通道，orderer用osnadmin指令激活通道，peer加入通道，然后更新锚节点，现在安装链码

目录

前言

一、主脚本中安装链码

二、deployCC.sh 

2.1 链码

 2.2 打包链码

2.3 在peer节点上安装链码

2.4 批准链码定义

2.5 将链码定义提交到通道

2.6 调用链码

---

前言

第一部分：Centos7 Fabric2.4 网络搭建（一）_Big. boss的博客-CSDN博客

第二部分：Centos7 Fabric2.4 网络搭建（二）_Big. boss的博客-CSDN博客

---

提示：用的是官方的例子学习搭建自己的网络，本次是用cryptogen生成证书，单机多节点部署

最终用户通过调用智能合约与区块链账本进行交互。在 Hyperledger Fabric 中，智能合约部署在称为链码的包中。想要验证交易或者查询账本的组织必须要有peer节点上安装链码，加入通道的peer节点都可以安装链码，在安装完链码后，通道成员就可以将链码部署到通道并使用链码中的智能合约在通道账本上创建或者更新资产。

想要验证交易或查询账本的组织需要在其对等节点上安装链码。在加入通道的节点上安装链码后，通道成员可以将链码部署到通道并使用链码中的智能合约在通道账本上创建或更新资产。

一、主脚本中安装链码

用户最终还是通过调用智能合约与区块链账本进行交互的，在Hyperledger Fabric 中，智能合约部署在称为链码的包中，

我们可以通过将链码部署到通道来确认通道已成功创建。我们可以使用network.sh脚本将资产转移的链码部署到已经创建的通道上，使用以下命令将链码部署到通道上。

./network.sh deployCC -ccn basic -ccp ../asset-transfer-basic/chaincode-go -ccl go

## 调用脚本将链码部署到通道
function deployCC() {
  scripts/deployCC.sh $CHANNEL_NAME $CC_NAME $CC_SRC_PATH $CC_SRC_LANGUAGE $CC_VERSION $CC_SEQUENCE $CC_INIT_FCN $CC_END_POLICY $CC_COLL_CONFIG $CLI_DELAY $MAX_RETRY $VERBOSE

  if [ $? -ne 0 ]; then
    fatalln "Deploying chaincode failed"
  fi
}

二、deployCC.sh 

2.1 链码

我们需要先打包链码，然后才能将其安装到我们的peer节点上，我们这里用go的智能合约。

在打包链码之前，我们需要安装链码的依赖，打开链码所在文件夹

 依赖项列举在目录中的go.mod文件中

 go.mod文件将Fabric合约API导入到智能合约包中，你可以打开chaincode/smartcontract.go了解合同API如何用于在智能合同开始时定义SmartContract类型

// SmartContract provides functions for managing an Asset
type SmartContract struct {
	contractapi.Contract
}

然后使用SmartContract类型为在智能合同中定义的函数创建事务上下文，该智能合同中读取和写入BlockChain分类帐，

// CreateAsset issues a new asset to the world state with given details.
func (s *SmartContract) CreateAsset(ctx contractapi.TransactionContextInterface, id string, color string, size int, owner string, appraisedValue int) error {
	exists, err := s.AssetExists(ctx, id)
	if err != nil {
		return err
	}
	if exists {
		return fmt.Errorf("the asset %s already exists", id)
	}

	asset := Asset{
		ID:             id,
		Color:          color,
		Size:           size,
		Owner:          owner,
		AppraisedValue: appraisedValue,
	}
	assetJSON, err := json.Marshal(asset)
	if err != nil {
		return err
	}

	return ctx.GetStub().PutState(id, assetJSON)
}

 2.2 打包链码

要安装智能合同依赖项，请从 asset-transfer-basic/chaincode-go目录运行以下命令

GO111MODULE=on go mod vendor

如果命令成功，go包将安装在一个vendor文件夹中

现在我们有了依赖包，我们就可以打包链码包，回到我们工作目录，以便于我们可以将链码包与我们的其他网络工件一起打包。

你可以使用 peer CLI 创建所需格式的链码包，peer 二进制文件位于工作目录的bin文件夹中，还需要设置 FABRIC_CFG_PATH指向工作目录中的core.yaml文件。

export PATH=${ROOTDIR}/bin:${PWD}/bin:$PATH
export FABRIC_CFG_PATH=${PWD}/config/

如果你想确认自己是否能够使用peer CLI，就可以检查peer的版本，提示需要版本为2.0.0或者更高版本

接下来使用 peer 生命周期package命令创建链码：

peer lifecycle chaincode package basic.tar.gz --path ./asset-transfer-basic/chaincode-go/ --lang golang --label basic_1.0

这一条命令会在当前目录创建一个名为basic.tar.gz的包。--lang 标志用于指定链码语言，--path标志提供智能合同代码的位置，该路径必须是完全限定路径或相对于你当前工作目录的路径。--label标志用于指定链码标签，该标签将在安装后识别链码，建议标签包括链码名称和版本。

2.3 在peer节点上安装链码

在我们打包资产转移（basic）智能合约后，我们可以在我们的peer节点上安装链码。链码需要安装在每个将支持交易的peer上，因为我们要将背书策略设置为需要来自 Org1 和 Org2 的背书，所以我们需要在两个组织运营的对等节点上安装链码：

• peer0.org1.hmw.com
• peer1.org1.hmw.com
• peer0.org2.hmw.com
• peer1.org2.hmw.com

让我们先在 Org1 peer0 上安装链码，设置以下环境变量，以 Org1 管理员用户身份操作peer CLI。将CORE_PEER_ADDRESS 被设置为指向peer0.org1.hmw.com

export CORE_PEER_TLS_ENABLED=true
export CORE_PEER_LOCALMSPID="Org1MSP"
export CORE_PEER_TLS_ROOTCERT_FILE=${PWD}/organizations/peerOrganizations/org1.hmw.com/tlsca/tlsca.org1.hmw.com-cert.pem
export CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org1.hmw.com/users/[email protected]/msp
export CORE_PEER_ADDRESS=localhost:8051

发送 peer 生命周期链码install命令在peer0.org1上安装链码

peer lifecycle chaincode install basic.tar.gz

如果命令成功，peer端将生成并返回包标识符，此包 ID 将用于在下一步中批准链码，你应该会看到类似于以下内容的输出： 

 同理，分别在剩下的peer节点上安装链码。

当安装链码时，链码由peer构建的。如果智能合同代码存在问题，则安装命令将返回来自链码的任何构建错误。

2.4 批准链码定义

安装链码包后，你需要为我们的组织批准链码定义，该定义包括链码包的重要参数，例如名称、版本和链码背书策略。

在可以部署它之前需要批准链码的频道成员集是由/Channel/Application/LifecycleEndorsement策略管理，默认情况下，此策略要求大多数通道成员需要批准链码才能在通道上使用。因此我们在通道上只有两个组织，两个组织的大多数就是2，所以需要Org1和Org2同时批准我们的basic链码。

如果组织已经在其peer节点上安装了链码，那么就需要他们在组织批准的链码定义中包含packageID。packageID用于将安装在对等节点上的链码与批准链码定义相关联，并允许组织使用链码来背书交易，我们可以使用peer生命周期链码 queryinstalled 命令来查询peer上安装的packageID

peer lifecycle chaincode queryinstalled

 packageID是链码标签和链码二进制文件的哈希组合，每个peer都会生成相同的packageID，

 接下来，当我们批准链码的时候，我们就会用到packageID，所以继续设置环境变量，将返回的packageID粘贴到下面的命令中。注意：并非所有用户的packageID都相同，要根据查询返回的packageID来完成此步骤。

export CC_PACKAGE_ID=basic_1.0:dee2d612e15f5059478b9048fa4b3c9f792096554841d642b9b59099fa0e04a4
export ORDERER_CA=${PWD}/organizations/ordererOrganizations/hmw.com/tlsca/tlsca.hmw.com-cert.pem
peer lifecycle chaincode approveformyorg -o localhost:7050 --ordererTLSHostnameOverride orderer0.hmw.com --tls --cafile "$ORDERER_CA" --channelID mychannel --name basic --version 1.0 --package-id $CC_PACKAGE_ID --sequence 1

上面的命令使用 --package-id标志将包标识符包含在链码定义中， --sequence参数是一个整数，用于跟踪链码已定义或更新的次数，因为链码是第一次部署到通道，所以序列号是1。升级basic链码时，序列号会递增到2。如果使用的是提供的低级的 Fabric Chaincode Shim API，你可以将 --init-required标志传递给上面的命令，以请求执行 Init 函数来初始化链码。链代码的第一次调用需要以 Init 函数为目标并包含--isInit标志，然后你才能使用链代码中的其他函数与分类帐交互。

刚刚是用的Org2的身份批准链码定义，Org1同理配置环境变量，完成Org1批准链码定义。

我们现在已经将basic链码部署到通道上的大部分节点，虽然只是大多数组织需要批准链码定义（默认策略），但是所有组织都需要批准链码定义才可以在peer节点上启动链码。如果你在通道成员批准链码之前提交定义，组织将无法为交易背书，所以，建议将所有通道成员提交链码之前批准链码。

2.5 将链码定义提交到通道

在足够数量的组织批准链码定义后，一个组织就可以将链码定义提交给通道，如果大多数通道成员都批准了链码定义，则成功提交事务，链码定义中约定的参数将在通道上实现。

你可以使用peer生命周期链码 checkcommitreadiness命令检查通道成员是否批准了相同的链码定义，用于该checkcommitreadiness命令的标志与用于批准你的组织的链码的标志相同，但是，不需要 --package-id标志。

peer lifecycle chaincode checkcommitreadiness --channelID mychannel --name basic --version 1.0 --sequence 1  --output json

该命令会生成一个json映射，显示通道成员是否批准checkcommitreadiness命令中指定的参数

由于作为通道成员的两个组织都批准了相同的参数，因此链码定义已经准备好提交给通道，可以使用peer生命周期链码 commit命令将链码提交到通道，提交命令需要有组织管理员提交。

export PEER0_ORG1_CA=${PWD}/organizations/peerOrganizations/org1.hmw.com/tlsca/tlsca.org1.hmw.com-cert.pem
export PEER0_ORG2_CA=${PWD}/organizations/peerOrganizations/org2.hmw.com/tlsca/tlsca.org2.hmw.com-cert.pem
peer lifecycle chaincode commit -o localhost:7050 --ordererTLSHostnameOverride orderer0.hmw.com --channelID mychannel --name basic --version 1.0 --sequence 1 --tls --cafile "$ORDERER_CA" --peerAddresses localhost:8051 --tlsRootCertFiles "$PEER0_ORG1_CA" --peerAddresses localhost:8055 --tlsRootCertFiles "$PEER0_ORG2_CA"

上面的事务使用--peerAddresses标志来定位Org1的peer0.org1.hmw.com和Org2的peer0.org2.hmw.com。commit 交易被提交给加入通道的peer，以查询操作peer的组织批准的链码定义。该命令需要针对来自足够数量的组织的peer，以满足部署链代码的策略。由于批准分布在每个组织内，因此你可以针对属于通道成员的任何peer

通道成员对链码定义的背书提交给排序服务，以添加到块中并分发到通道。然后通道上的peer验证是否有足够数量的组织批准了链码定义，peer生命周期链码 commit命令将在返回响应之前等待peer的验证。

可以使用peer生命周期链码 querycommitted 命令来确认链码是否提交到通道

peer lifecycle chaincode querycommitted --channelID mychannel --name basic --cafile "$ORDERER_CA"

如果链码成功提交到通道，该querycommitted 命令将返回链码定义的序列和版本

 

2.6 调用链码

将链码定义提交到通道后，链码将在加入安装链码的通道的peer节点上启动。资产转移（basic）链码现在已准备好由客户端应用程序调用。使用以下命令在分类帐上创建一组初始资产，请注意，invoke 命令需要针对足够数量的对等方以满足链码背书策略。（注意 CLI 不访问 Fabric Gateway 对等体，因此必须指定每个背书节点。）

peer chaincode invoke -o localhost:7050 --ordererTLSHostnameOverride orderer0.hmw.com --tls --cafile "$ORDERER_CA" -C mychannel -n basic --peerAddresses localhost:8051 --tlsRootCertFiles "$PEER0_ORG1_CA" --peerAddresses localhost:8055 --tlsRootCertFiles "$PEER0_ORG2_CA" -c '{"function":"InitLedger","Args":[]}'

如果命令成功，你应该会看到类似于以下内容的响应：

 我们可以使用查询函数来读取由链码创建的汽车集合：

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

 如果命令成功，你应该会看到类似于以下内容的响应：

至此，链码安装完成

相关代码请参考：Centos7 Fabric2.4 部署用到的脚本_Big. boss的博客-CSDN博客

---