Changing Endorsement Policy and Chaincode Upgrade After Chaincode Committed (Hyperledger Fabric 2.0)

KC Tam

Feb 20, 2020·12 min read

Overview

This article is another one working on lifecycle chaincode in Hyperledger Fabric 2.0. In this work we will focus on operation after an application chaincode is already deployed and being used. Here are the two demonstrations: The first one is to change the endorsement policy. The second is to upgrade chaincode, that is, to deploy a new version of chaincode while maintaining the existing state. Through these two demonstrations we can understand more the process about lifecycle chaincode introduced in 2.0.

You can refer to my previous article on more about lifecycle chaincode here and here. Besides, you can always refer to the official documentation on this topic.

Review: Lifecycle Chaincode

We use lifecycle chaincode to deploy application chaincode in a fabric network and make it useable. After a chaincode is developed and tested, it gets through these four steps to make it useable and accessible in the fabric network.

Step 1: Package Chaincode

This step is to create a package from the chaincode source and modules into a .tar.gz file. This step does not involve interaction to the fabric network.

Step 2: Install chaincode

This step is to install the chaincode package from previous step to selected peers. A package ID is generated. This package ID is referred when chaincode definition is later approved and committed.

Step 3: Approve chaincode definition

This step to let organization make explicit approval individually on the chaincode definition to a channel. Chaincode definition is a collection of parameters, including name, version, endorsement policy, etc. The requirement of how many approvals are needed before a chaincode can be committed is governed by lifecycle endorsement policy, which by default is majority.

Step 4: Commit chaincode definition

Assuming the number of approvals of organizations meets the requirement in lifecycle endorsement policy, the chaincode definition can be committed to a channel. With everything works fine, the committed chaincode is useable. External world can invoke the chaincode functions defined in the chaincode source.

This is the summary of this flow. This is the base of our next two demonstration.

Setup

As usual, we are using fabric samples. First Network is brought up and Simple Asset Chaincode (SACC) is deployed on the First Network.

This is the same setup in my previous work. Refer to this and this for more detail.

Scenario 1: Change Endorsement Policy

Changing endorsing policy for a committed chaincode involves approval and commit a new chaincode definition. The first two steps, chaincode packaging and installation to peers, are not required. We are using the same Package ID when applying the new endorsing policy.

For demonstration purpose, we first use the default endorsing policy, which is majority (in this case, two organizations are required). We will test and see the chaincode invoke fails if only one endorsement is received.

After this, we will change the endorsing policy such that either organization can endorse the chaincode invoke, that is, the endorsement policy is changed to OR(Org1MSP.peer, Org2MSP.peer). After the change we will test and see that chaincode invoke can be done by only one endorsement.

Bring up the First Network without default abstore chaincode

cd fabric-samples/first-network
./byfn.sh up -n

Here are the steps of demonstration.

Step 1: Package SACC chaincode

docker exec cli peer lifecycle chaincode package sacc.tar.gz --path github.com/hyperledger/fabric-samples/chaincode/sacc/ --label sacc_1

Step 2: Install chaincode package

# install package to peer0.org1
docker exec cli peer lifecycle chaincode install sacc.tar.gz# install package to peer0.org2
docker exec -e CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp -e CORE_PEER_ADDRESS=peer0.org2.example.com:9051 -e CORE_PEER_LOCALMSPID="Org2MSP" -e CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt cli peer lifecycle chaincode install sacc.tar.gz

Note the Package ID. We are using this in next step.

Step 3: Approve Chaincode Definition

There are many items in a chaincode definition. Among them, the following are of our interests

• name: mycc
• version: 1
• sequence: 1
• endorsement policy: majority (default)

We specify the package ID (obtained in previous step) and channel (mychannel) when we make approval and chaincode commit.

# approval for org1
docker exec cli peer lifecycle chaincode approveformyorg --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem --channelID mychannel --name mycc --version 1 --sequence 1 --waitForEvent --package-id sacc_1:bf57e4926742fd0dbd8716058897cbb60d3530914529a4b9b46817d2324f6399# approval for org2
docker exec -e CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp -e CORE_PEER_ADDRESS=peer0.org2.example.com:9051 -e CORE_PEER_LOCALMSPID="Org2MSP" -e CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt cli peer lifecycle chaincode approveformyorg --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem --channelID mychannel --name mycc --version 1 --sequence 1 --waitForEvent --package-id sacc_1:bf57e4926742fd0dbd8716058897cbb60d3530914529a4b9b46817d2324f6399

Step 4: Commit Chaincode Definition

docker exec cli peer lifecycle chaincode commit -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem --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 --channelID mychannel --name mycc --version 1 --sequence 1

Check chaincode definition that have been committed.

docker exec cli peer lifecycle chaincode querycommitted -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem --channelID mychannel --name mycc --output json

Validation parameter is base64-encoded, which is /Channel/Application/Endorsement (i.e. the default set in configtx.yaml).

Step 5: Chaincode Function Invoke Demonstration

Step 5.1: Invoke with endorsing peer from one org and query the ledger

Without specifying any peerAddresses, this chaincode invoke will only be sent to and endorsed by peer0.org1.example.com, the default one specified in CLI.

docker exec cli peer chaincode invoke -o orderer.example.com:7050 --tls true --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C mychannel -n mycc -c '{"Args":["set", "name", "KC"]}'docker exec cli peer chaincode query -C mychannel -n mycc -c '{"Args":["get", "name"]}'

We see here ledger is not updated as the endorsement policy is not met (only one organization has made endorsement).

Step 5.2: Invoke with endorsing peer from two orgs and query the ledger

Now we specify both peer0.org1.example.com and peer0.org2.example.com as the endorsing peers (using peerAddress option).

docker exec cli peer chaincode invoke -o orderer.example.com:7050 --tls true --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C mychannel -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":["set", "name", "KC"]}'docker exec cli peer chaincode query -C mychannel -n mycc -c '{"Args":["get", "name"]}'

So the endorsing policy (majority) works well.

Step 6: Approve a New Chaincode Definition

Here we change the application endorsement policy, from majority to either one organization. As endorsement policy is changed, it is a new chaincode definition. New chaincode definition requires approvals to meet lifecycle chaincode endorsement policy requirement.

Don’t be mixed up with lifecycle chaincode and application chaincode (SACC). We are changing the endorsement policy from the latter. We still require approval from both organizations for making this change.

Here is the new Chaincode Definition

• name: mycc
• version: 1 (Note: this is the same version of chaincode.)
• sequence: 2 (Note: this is a new chaincode definition.)
• endorsement policy: overridden by signature-policy flag

We specify the package ID (obtained in Step 3) and channel (mychannel) when we make approval and chaincode commit.

# approval for org1
docker exec cli peer lifecycle chaincode approveformyorg --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem --channelID mychannel --name mycc --version 1 --sequence 2 --waitForEvent --package-id sacc_1:bf57e4926742fd0dbd8716058897cbb60d3530914529a4b9b46817d2324f6399 --signature-policy "OR ('Org1MSP.peer','Org2MSP.peer')"# approval for org2
docker exec -e CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp -e CORE_PEER_ADDRESS=peer0.org2.example.com:9051 -e CORE_PEER_LOCALMSPID="Org2MSP" -e CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt cli peer lifecycle chaincode approveformyorg --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem --channelID mychannel --name mycc --version 1 --sequence 2 --waitForEvent --package-id sacc_1:bf57e4926742fd0dbd8716058897cbb60d3530914529a4b9b46817d2324f6399 --signature-policy "OR ('Org1MSP.peer','Org2MSP.peer')"

Step 7: Commit this Chaincode Definition

docker exec cli peer lifecycle chaincode commit -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem --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 --channelID mychannel --name mycc --version 1 --sequence 2 --signature-policy "OR ('Org1MSP.peer','Org2MSP.peer')"

Check chaincode definition that have been committed.

docker exec cli peer lifecycle chaincode querycommitted -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem --channelID mychannel --name mycc --output json

Validation parameter is base64-encoded, which is in its own format showing the new policy.

Step 8: Chaincode Function Invoke Demonstration

Step 8.1: We first take a look on an existing state

docker exec cli peer chaincode query -C mychannel -n mycc -c '{"Args":["get", "name"]}'

This new commitment of chaincode definition has no impact on existing state.

Step 8.2: Invoke with endorsing peer from one org and query the ledger

docker exec cli peer chaincode invoke -o orderer.example.com:7050 --tls true --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C mychannel -n mycc -c '{"Args":["set", "age", "30"]}'docker exec cli peer chaincode query -C mychannel -n mycc -c '{"Args":["get", "age"]}'

We see the chaincode definition with modified endorsing policy working fine.

This ends this scenario. Tear down the whole setup and continue with the next scenario.

cd fabric-samples/first-network
./byfn.sh down

Scenario 2: Upgrade Chaincode

In this scenario we modify the chaincode source. It is a brand new chaincode and therefore we need to get through the whole process. By using the same name with a new version number, we can make it more an upgrade.

Note: in Hyperledger 1.4 there is an chaincode upgrade capability. Since lifecycle chaincode requires organization explicit approval for chaincode commit, we need to go through the whole process.

For demonstration purpose, we prepare another chaincode based on SACC, by adding a condition check that the input variable name cannot be “name”. We keep it as in chaincode/saccv2.

cd fabric-samples/chaincode
cp -r sacc saccv2

Then we will modify the file sacc.go, by adding a condition check on “name”.

We first bring up the First Network. Note the first five steps are identical to previous one.

Similarly, bring up the First Network without default abstore chaincode

cd fabric-samples/first-network
./byfn.sh up -n

Step 1: Package SACC chaincode

docker exec cli peer lifecycle chaincode package sacc.tar.gz --path github.com/hyperledger/fabric-samples/chaincode/sacc/ --label sacc_1

Step 2: Install chaincode package

# install package to peer0.org1
docker exec cli peer lifecycle chaincode install sacc.tar.gz# install package to peer0.org2
docker exec -e CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp -e CORE_PEER_ADDRESS=peer0.org2.example.com:9051 -e CORE_PEER_LOCALMSPID="Org2MSP" -e CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt cli peer lifecycle chaincode install sacc.tar.gz

Note the Package ID. We are using this in next step. Also after we modify the chaincode and install it again, we will have a different Package ID.

Step 3: Approve Chaincode Definition

The following items are of our interest in the current Chaincode Definition

• name: mycc
• version: 1
• sequence: 1

We specify the package ID (obtained in previous step) and channel (mychannel) when we make approval and chaincode commit.

# approval for org1
docker exec cli peer lifecycle chaincode approveformyorg --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem --channelID mychannel --name mycc --version 1 --sequence 1 --waitForEvent --package-id sacc_1:bf57e4926742fd0dbd8716058897cbb60d3530914529a4b9b46817d2324f6399# approval for org2
docker exec -e CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp -e CORE_PEER_ADDRESS=peer0.org2.example.com:9051 -e CORE_PEER_LOCALMSPID="Org2MSP" -e CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt cli peer lifecycle chaincode approveformyorg --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem --channelID mychannel --name mycc --version 1 --sequence 1 --waitForEvent --package-id sacc_1:bf57e4926742fd0dbd8716058897cbb60d3530914529a4b9b46817d2324f6399

Step 4: Commit Chaincode Definition

docker exec cli peer lifecycle chaincode commit -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem --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 --channelID mychannel --name mycc --version 1 --sequence 1

Check chaincode definition that have been committed.

docker exec cli peer lifecycle chaincode querycommitted -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem --channelID mychannel --name mycc --output json

Step 5: Chaincode Function Invoke Demonstration

Invoke the function to set a value to “name”.

docker exec cli peer chaincode invoke -o orderer.example.com:7050 --tls true --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C mychannel -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":["set", "name", "KC"]}'docker exec cli peer chaincode query -C mychannel -n mycc -c '{"Args":["get", "name"]}'

It works fine as in this version of chaincode, you can set the “name”.

Step 6: Package a new SACC chaincode

docker exec cli peer lifecycle chaincode package saccv2.tar.gz --path github.com/hyperledger/fabric-samples/chaincode/saccv2/ --label sacc_2

Note we are specifying our new chaincode directory, and the result package is stored in saccv2.tar.gz.

Step 7: Install chaincode package

# install package to peer0.org1
docker exec cli peer lifecycle chaincode install saccv2.tar.gz# install package to peer0.org2
docker exec -e CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp -e CORE_PEER_ADDRESS=peer0.org2.example.com:9051 -e CORE_PEER_LOCALMSPID="Org2MSP" -e CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt cli peer lifecycle chaincode install saccv2.tar.gz

Note that we now have a new Package ID. We will use this in the next step.

Step 8: Approve Chaincode Definition

In the new Chaincode Definition

• name: mycc
• version: 2 (Note: this is a new version of chaincode.)
• sequence: 2 (Note: this is a new chaincode definition.)

Using the name with different version show it is an upgrade instead of a brand new chaincode. A new sequence as it is another commit from the previous one.

# approval for org1
docker exec cli peer lifecycle chaincode approveformyorg --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem --channelID mychannel --name mycc --version 2 --sequence 2 --waitForEvent --package-id sacc_2:24b26ec4f9e49321e5d5329968db8f43e0d4132e0fe832aed458f0f30eb271e3# approval for org2
docker exec -e CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp -e CORE_PEER_ADDRESS=peer0.org2.example.com:9051 -e CORE_PEER_LOCALMSPID="Org2MSP" -e CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt cli peer lifecycle chaincode approveformyorg --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem --channelID mychannel --name mycc --version 2 --sequence 2 --waitForEvent --package-id sacc_2:24b26ec4f9e49321e5d5329968db8f43e0d4132e0fe832aed458f0f30eb271e3

Step 9: Commit the New Chaincode Definition

docker exec cli peer lifecycle chaincode commit -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem --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 --channelID mychannel --name mycc --version 2 --sequence 2

Check chaincode definition that have been committed.

docker exec cli peer lifecycle chaincode querycommitted -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem --channelID mychannel --name mycc --output json

Step 10: Chaincode Function Invoke Demonstration

Step 10.1: We first take a look on existing state

docker exec cli peer chaincode query -C mychannel -n mycc -c '{"Args":["get", "name"]}'

By using the same name with different version, this is equivalent to a chaincode upgrade, which does not impact the existing state.

Step 10.2: Invoke the function to set a new value to “name”

docker exec cli peer chaincode invoke -o orderer.example.com:7050 --tls true --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C mychannel -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":["set", "name", "Peter"]}'docker exec cli peer chaincode query -C mychannel -n mycc -c '{"Args":["get", "name"]}'

With the new chaincode in effect, we can no longer set the name.

This ends the scenario of chaincode upgrade.

Observation

Here are some observation over the process.

• Changing endorsement policy after a chaincode is deployed for use requires a change on chaincode definition. This does not involve a new chaincode and a new chaincode package as the same source code is being used.
• The approval process is still governed by lifecycle chaincode endorsement policy.
• This process does not have impact on existing state already in the ledger.
• Upgrading application chaincode requires a complete process of chaincode operation, from packaging to commit chaincode definition.
• As far as the chaincode definition keeps the same name but a different version, this is considered a chaincode upgrade, and the existing state in the ledger is kept. If a different name is used, this is a complete separate deployment of application chaincode, even though one is using the same chaincode package. The state between deployed chaincode of different names are handled separately in the ledger.

Hope you like this article.