Fabric官方教程（release 2.2）翻译及总结——链码的生命周期管理

1. 将智能合约部署到通道

将智能合约部署到信道最终用户通过调用智能合约来与区块链账进行交互。在Hyperledger Fabric中，智能合约以称为chaincode的软件包部署。想要验证交易或查询帐本的组织需要在其peers上安装链码。在已加入通道的peer上安装链码后，通道成员可以将链码部署到通道，并使用链码中的智能合约在通道账本上创建或更新资产。

使用称为Fabric链码生命周期的过程将链码部署到通道。 Fabric链码生命周期允许多个组织在使用链码创建交易之前就如何操作链码达成共识。例如，虽然背书策略指定哪些组织需要执行链码以验证交易，但信道成员需要使用Fabric链码生命周期来同意链码背书策略。有关如何在通道上部署和管理链码的更深入的概述，请参阅结构链码生命周期。

您可以使用本教程来学习如何使用peer生命周期chaincode命令将链码部署到Fabric测试网络的通道。一旦了解了命令，就可以使用本教程中的步骤将自己的链码部署到测试网络，或将链码部署到生产网络。在本教程中，您将部署“编写第一个应用程序”教程所使用的资产转移（基本）链码。注意：这些说明使用v2.0版本中引入的Fabric链码生命周期。如果您想使用以前的生命周期来安装和实例化链码，请访问Fabric文档的v1.4版本。

我们可以使用Peer CLI来部署基础的交易链码到通道中，通过以下四步来实现
第一步：打包智能合约
第二步：安装打包好的智能合约
第三步：部署智能合约
第四部：确信通道中合约的定义

设置 Logspout (optional)

此步骤不是必需的，但是对于故障排除链码非常有用。 要监视智能合约的日志，管理员可以使用logspout工具查看一组Docker容器的聚合输出。 该工具将来自不同Docker容器的输出流收集到一个位置，从而可以轻松地从单个窗口查看发生的情况。 这可以帮助管理员在安装智能合约时调试问题，或者在调用智能合约时为开发人员调试问题。 由于某些容器的创建纯粹是为了启动智能合约，并且仅存在很短的时间，因此从网络中收集所有日志将很有帮助。

Fabric示例中的商业用纸示例中已经包含了用于安装和配置Logspout的脚本monitordocker.sh。 我们还将在本教程中使用相同的脚本。 Logspout工具将持续将日志流传输到您的终端，因此您将需要使用新的终端窗口。 打开一个新终端，然后导航到test-network目录。

打包智能合约

在把链码安装到peer节点上之前，需要先打包链码. 不同语言编写的智能合约，在步骤上有所不同

Go

在我们打包链码之前，我们需要安装链码依赖项。 移步到包含资产转移(基本)链代码的Go版本的文件夹。

cd fabric-samples/asset-transfer-basic/chaincode-go

The sample uses a Go module to install the chaincode dependencies. The dependencies are listed in a go.mod file in the asset-transfer-basic/chaincode-go directory. You should take a moment to examine this file.

$ cat go.mod
module github.com/hyperledger/fabric-samples/asset-transfer-basic/chaincode-go

go 1.14

require (
        github.com/golang/protobuf v1.3.2
        github.com/hyperledger/fabric-chaincode-go v0.0.0-20200424173110-d7076418f212
        github.com/hyperledger/fabric-contract-api-go v1.1.0
        github.com/hyperledger/fabric-protos-go v0.0.0-20200424173316-dd554ba3746e
        github.com/stretchr/testify v1.5.1
)

“go. mod '文件将Fabric合约API导入智能合约包。 你可以在文本编辑器中打开‘asset-transfer-basic/chaincode-go/chaincode/smartcontract’查看合约API是如何在智能合约的开头定义“SmartContract”类型的:

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

然后使用“SmartContract”类型为智能合约中定义的函数创建事务上下文，这些函数向区块链分类账读写数据。

// 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)
}

You can learn more about the Go contract API by visiting the API documentation and the smart contract processing topic.

To install the smart contract dependencies, run the following command from the asset-transfer-basic/chaincode-go directory.

关键步骤：

GO111MODULE=on go mod vendor
cd ../../test-network

您可以使用peerCLI创建所需格式的链码包。 peer二进制文件位于fabric-samples存储库的bin文件夹中。 使用以下命令将这些二进制文件添加到您的CLI路径：

export PATH=${PWD}/../bin:$PATH

You also need to set the FABRIC_CFG_PATH to point to the core.yaml file in the fabric-samples repository:

export FABRIC_CFG_PATH=$PWD/../config/

To confirm that you are able to use the peer CLI, check the version of the binaries. The binaries need to be version 2.0.0 or later to run this tutorial.

peer version

现在可以使用 peer lifecycle chaincode 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标志用于指定链码标签，该链码标签将在安装链码后对其进行标识。 建议您的标签包含链码名称和版本。

现在我们已经创建了chaincode包，我们可以在测试网络的peer点上安装chaincode了。

安装链码包

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

• peer0.org1.example.com
• peer0.org2.example.com

让我们安装链码 首先在Org1peer节点上。 设置以下环境变量以以Org1 admin用户的身份运行peerCLI。 CORE_PEER_ADDRESS将设置为指向Org1peerpeer0.org1.example.com。

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

使用peer 生命周期命令安装链码：

peer lifecycle chaincode install basic.tar.gz

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

2020-07-16 10:09:57.534 CDT [cli.lifecycle.chaincode] submitInstallProposal -> INFO 001 Installed remotely: response:<status:200 payload:"\nJbasic_1.0:e2db7f693d4aa6156e652741d5606e9c5f0de9ebb88c5721cb8248c3aead8123\022\tbasic_1.0" >
2020-07-16 10:09:57.534 CDT [cli.lifecycle.chaincode] submitInstallProposal -> INFO 002 Chaincode code package identifier: basic_1.0:e2db7f693d4aa6156e652741d5606e9c5f0de9ebb88c5721cb8248c3aead8123

在peer节点 Org2 peer上安装，设置环境变量切换过去：

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

安装链码时，链码由peer构建。 如果智能合约代码存在问题，install命令将从链码中返回所有构建错误。

批准链码定义

安装chaincode程序包后，需要批准组织的chaincode定义。 该定义包括链码管理的重要参数，例如名称，版本和链码认可策略。

在部署链码之前，需要由“应用程序/通道/ lifeycleEndorsement”策略控制一组通道成员批准。 默认情况下，此策略要求大多数通道成员需要批准链码后才能在通道上使用。 因为通道上只有两个组织，而2个中的大多数是2个，所以我们需要批准资产转移（基本）的链码定义为Org1和Org2。

如果组织已在其peer上安装了链码，则他们需要在其组织批准的链码定义中包括packageID。 程序包ID用于将peer上安装的链码与批准的链码定义相关联，并允许组织使用链码对交易进行背书。 您可以使用peer生命周期chaincode queryinstalled命令来查询peer节点，从而找到链代码的程序包ID。

ID查询：

peer lifecycle chaincode queryinstalled

程序包ID是链码标签和链码二进制文件的哈希值的组合。 每个peer方将生成相同的程序包ID。 您应该看到类似于以下内容的输出：

Installed chaincodes on peer:
Package ID: basic_1.0:69de748301770f6ef64b42aa6bb6cb291df20aa39542c3ef94008615704007f3, Label: basic_1.0

批准链码时，我们将使用包ID，因此，继续将其保存为环境变量。 将由安装的peer生命周期链码查询返回的程序包ID粘贴到以下命令中。 注意：软件包ID对于所有用户而言都不相同，因此您需要使用上一步中从命令窗口返回的软件包ID来完成此步骤。

export CC_PACKAGE_ID=basic_1.0:69de748301770f6ef64b42aa6bb6cb291df20aa39542c3ef94008615704007f3

因为已经设置了环境变量以将peer CLI作为Org2管理员运行，所以我们可以以Org2身份批准资产转移（基本）的链码定义。 Chaincode在组织级别得到批准，因此该命令仅需要针对一个peer。 使用八卦将批准分配给组织中的其他peer方。 使用peer生命周期chaincode approveformyorg命令来批准chaincode定义：

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

上面的命令使用

• –package-id标志将程序包标识符包括在链码定义中。
• -sequence参数是一个整数，用于跟踪已定义或更新链码的次数。 由于链码是第一次部署到通道，因此序列号为1。升级资产转移（基本）链码时，序列号将增加为2。如果使用的是提供的低级API 通过Fabric Chaincode Shim API，
• 您可以将–init-required标志传递给上述命令，以请求执行Init函数来初始化链码。
• 链代码的首次调用需要以Init函数为目标，并包括–isInit标志，

然后才能使用链代码中的其他函数与账本进行交互。

我们可以为approveformyorg命令提供**–signature-policy或–channel-config-policy参数，以指定链码背书策略**。 背书策略指定需要多少个属于不同通道成员的peer才能根据给定的链码验证交易。 由于我们未设置政策，因此资产转移（基本）的定义将使用默认的背书政策，该政策要求在提交交易时，该交易必须获得出席的大多数通道成员的认可。 这意味着，如果在通道中添加或删除了新的组织，则背书策略会自动更新，以要求更多或更少的背书。 在本教程中，默认策略将需要2个中的2个中的大多数，并且事务将需要由Org1和Org2的peer方认可。 如果要指定自定义认可策略，则可以使用“认可策略”操作指南来了解策略语法。

您需要具有管理员角色的身份批准链码定义。 因此，CORE_PEER_MSPCONFIGPATH变量需要指向包含管理员身份的MSP文件夹。 您无法以客户用户身份来批准链码定义。 批准需要提交到排序服务，排序服务将验证管理员签名，然后将批准分发给您的同级。

我们仍然需要以Org1身份批准链码定义。 设置以下环境变量以以Org1管理员身份运行：

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

现在，我们拥有多数，我们需要将资产转移（基本）链代码部署到通道。 虽然只有大多数组织需要批准链码定义（具有默认策略），但是所有组织都需要批准链码定义才能在其peer方启动链码。 如果您在通道成员批准链码之前提交定义，则组织将无法批准交易。 结果，建议所有通道成员在提交链码定义之前批准链码。

将链码定义提交给通道

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

您可以使用peer lifecycle chaincode checkcommitreadiness命令来检查通道成员是否已批准相同的链码定义。 用于checkcommitreadiness命令的标志与用于批准组织的链码的标志相同。 但是，您不需要包括–package-id标志。

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

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

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

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

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

上面的交易使用**–peerAddresses标志将Org1中的peer0.org1.example.com和Org2中的peer0.org2.example.com定位为目标**。提交交易将提交给已加入通道的peer，以查询由操作peer的组织批准的链码定义。该命令需要针对足够数量的组织中的peer，以满足部署链码的策略。由于批准是在每个组织内分配的，因此您可以定位属于信道成员的任何peer。

**信道成员对链码定义的认可将提交给排序服务，以添加到模块中并分发给信道。然后，通道上的peer将验证是否有足够的组织批准了链码定义。**peer生命周期chaincode commit命令将在返回响应之前等待来自peer节点的验证。您可以使用peer生命周期chaincode querycommitted命令来确认chaincode定义已提交给通道。

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

If the chaincode was successful committed to the channel, the querycommitted command will return the sequence and version of the chaincode definition:

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]

调用链码

将链码定义提交到通道后，链码将从加入通道的peer（链码安装的地方）开始。 资产转移（基本）链码现在可以由客户端应用程序调用。 使用以下命令在账本上创建一组初始资产。 请注意**，invoke命令需要以足够数量的peer为目标，以符合链码认可策略。**

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 basicyy --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":[]}'

If the command is successful, you should be able to a response similar to the following:

2020-02-12 18:22:20.576 EST [chaincodeCmd] chaincodeInvokeOrQuery -> INFO 001 Chaincode invoke successful. result: status:200

We can use a query function to read the set of cars that were created by the chaincode:

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

The response to the query should be the following list of assets:

[{"Key":"asset1","Record":{"ID":"asset1","color":"blue","size":5,"owner":"Tomoko","appraisedValue":300}},
{"Key":"asset2","Record":{"ID":"asset2","color":"red","size":5,"owner":"Brad","appraisedValue":400}},
{"Key":"asset3","Record":{"ID":"asset3","color":"green","size":10,"owner":"Jin Soo","appraisedValue":500}},
{"Key":"asset4","Record":{"ID":"asset4","color":"yellow","size":10,"owner":"Max","appraisedValue":600}},
{"Key":"asset5","Record":{"ID":"asset5","color":"black","size":15,"owner":"Adriana","appraisedValue":700}},
{"Key":"asset6","Record":{"ID":"asset6","color":"white","size":15,"owner":"Michel","appraisedValue":800}}]

升级智能合约

您可以使用相同的Fabric链码生命周期过程来升级已经部署到通道的链码。信道成员可以通过以下方式升级链码：安装新的链码软件包，然后批准具有新的软件包ID，新的链码版本以及序列号加1的链码定义。将链码定义提交到通道后，可以使用新的链码。此过程允许通道成员协调何时升级链码，并确保在将新链码部署到通道之前，有足够数量的通道成员准备使用新链码。

信道成员还可以使用升级过程来更改链码背书策略。通过批准具有新背书策略的链码定义并将链码定义提交给信道，信道成员可以更改管理链码的认可策略，而无需安装新的链码包。

为了提供升级我们刚刚部署的资产转移（基本）链码的方案，我们假设Org1和Org2希望安装用另一种语言编写的链码版本。他们将使用Fabric链码生命周期来更新链码版本，并确保两个组织都在通道上启用新链码之前就已经安装了新链码。

我们将假设Org1和Org2最初安装了资产转移（基本）链码的GO版本，但是使用JavaScript编写的链码会更舒适。第一步是打包资产转移（基本）链码的JavaScript版本。如果在阅读本教程时使用了JavaScript指令打包链码，则可以按照打包用Go或TypeScript编写的链码的步骤安装新的链码二进制文件。

Issue the following commands from the test-network directory to install the chaincode dependences.

cd ../asset-transfer-basic/chaincode-javascript
npm install
cd ../../test-network

You can then issue the following commands to package the JavaScript chaincode from the test-network directory. We will set the environment variables needed to use the peer CLI again in case you closed your terminal.

export PATH=${PWD}/../bin:$PATH
export FABRIC_CFG_PATH=$PWD/../config/
export CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp
peer lifecycle chaincode package basic_2.tar.gz --path ../asset-transfer-basic/chaincode-javascript/ --lang node --label basic_2.0

Run the following commands to operate the peer CLI as the Org1 admin:

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

We can now use the following command to install the new chaincode package on the Org1 peer.

peer lifecycle chaincode install basic_2.tar.gz

The new chaincode package will create a new package ID. We can find the new package ID by querying our peer.

peer lifecycle chaincode queryinstalled

The queryinstalled command will return a list of the chaincode that have been installed on your peer similar to this output.

Installed chaincodes on peer:
Package ID: basic_1.0:69de748301770f6ef64b42aa6bb6cb291df20aa39542c3ef94008615704007f3, Label: basic_1.0
Package ID: basic_2.0:1d559f9fb3dd879601ee17047658c7e0c84eab732dca7c841102f20e42a9e7d4, Label: basic_2.0

You can use the package label to find the package ID of the new chaincode and save it as a new environment variable. This output is for example only – your package ID will be different, so DO NOT COPY AND PASTE!

export NEW_CC_PACKAGE_ID=basic_2.0:1d559f9fb3dd879601ee17047658c7e0c84eab732dca7c841102f20e42a9e7d4

Org1 can now approve a new chaincode definition:

peer lifecycle chaincode approveformyorg -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --channelID mychannel --name basic --version 2.0 --package-id $NEW_CC_PACKAGE_ID --sequence 2 --tls --cafile ${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem

新的chaincode定义使用JavaScript chaincode包的包ID，并更新了chaincode版本。 因为Fabric链码生命周期使用sequence参数来跟踪链码升级，Org1还需要将序列号从1增加到2。可以使用 peer lifecycle chaincode querycommitted 命令查找最后提交到通道的链码序列。

We now need to install the chaincode package and approve the chaincode definition as Org2 in order to upgrade the chaincode. Run the following commands to operate the peer CLI as the 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

We can now use the following command to install the new chaincode package on the Org2 peer.

peer lifecycle chaincode install basic_2.tar.gz

You can now approve the new chaincode definition for Org2.

peer lifecycle chaincode approveformyorg -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --channelID mychannel --name basic --version 2.0 --package-id $NEW_CC_PACKAGE_ID --sequence 2 --tls --cafile ${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem

Use the peer lifecycle chaincode checkcommitreadiness command to check if the chaincode definition with sequence 2 is ready to be committed to the channel:

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

The chaincode is ready to be upgraded if the command returns the following JSON:

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

提交新的链码定义后，链码将在频道上升级。 在此之前，之前的链码将继续在两个组织的同行上运行。 Org2可以使用以下命令升级chaincode:

peer lifecycle chaincode commit -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --channelID mychannel --name basic --version 2.0 --sequence 2 --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

成功提交事务将立即启动新的链码。 如果链码定义改变了背书政策，新的政策将生效。
您可以使用’ docker ps '命令来验证新的chaincode已经在您的同行上启动:

$ docker ps
CONTAINER ID        IMAGE                                                                                                                                                                    COMMAND                  CREATED             STATUS              PORTS                              NAMES
7bf2f1bf792b        dev-peer0.org1.example.com-basic_2.0-572cafd6a972a9b6aa3fa4f6a944efb6648d363c0ba4602f56bc8b3f9e66f46c-69c9e3e44ed18cafd1e58de37a70e2ec54cd49c7da0cd461fbd5e333de32879b   "docker-entrypoint.s…"   2 minutes ago       Up 2 minutes                                           dev-peer0.org1.example.com-basic_2.0-572cafd6a972a9b6aa3fa4f6a944efb6648d363c0ba4602f56bc8b3f9e66f46c
985e0967c27a        dev-peer0.org2.example.com-basic_2.0-572cafd6a972a9b6aa3fa4f6a944efb6648d363c0ba4602f56bc8b3f9e66f46c-158e9c6a4cb51dea043461fc4d3580e7df4c74a52b41e69a25705ce85405d760   "docker-entrypoint.s…"   2 minutes ago       Up 2 minutes                                           dev-peer0.org2.example.com-basic_2.0-572cafd6a972a9b6aa3fa4f6a944efb6648d363c0ba4602f56bc8b3f9e66f46c
31fdd19c3be7        hyperledger/fabric-peer:latest                                                                                                                                           "peer node start"        About an hour ago   Up About an hour    0.0.0.0:7051->7051/tcp             peer0.org1.example.com
1b17ff866fe0        hyperledger/fabric-peer:latest                                                                                                                                           "peer node start"        About an hour ago   Up About an hour    7051/tcp, 0.0.0.0:9051->9051/tcp   peer0.org2.example.com
4cf170c7ae9b        hyperledger/fabric-orderer:latest

如果你使用了’–Init -required '标志，你需要在使用升级后的chaincode之前调用Init函数。 因为我们没有请求Init的执行，所以我们可以通过创建一个新汽车来测试新的JavaScript链代码:

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":"CreateAsset","Args":["asset8","blue","16","Kelley","750"]}'

You can query all the cars on the ledger again to see the new car:

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

You should see the following result from the JavaScript chaincode:

[{"Key":"asset1","Record":{"ID":"asset1","color":"blue","size":5,"owner":"Tomoko","appraisedValue":300}},
{"Key":"asset2","Record":{"ID":"asset2","color":"red","size":5,"owner":"Brad","appraisedValue":400}},
{"Key":"asset3","Record":{"ID":"asset3","color":"green","size":10,"owner":"Jin Soo","appraisedValue":500}},
{"Key":"asset4","Record":{"ID":"asset4","color":"yellow","size":10,"owner":"Max","appraisedValue":600}},
{"Key":"asset5","Record":{"ID":"asset5","color":"black","size":15,"owner":"Adriana","appraisedValue":700}},
{"Key":"asset6","Record":{"ID":"asset6","color":"white","size":15,"owner":"Michel","appraisedValue":800}},
"Key":"asset8","Record":{"ID":"asset8","color":"blue","size":16,"owner":"Kelley","appraisedValue":750}}]