The Chaincode Lifecycle on Hyperledger Fabric v2
In this story, we will examine how the chaincode process is operated. We can use the Fabric chaincode lifecycle by creating a new channel and setting the channel capabilities to v2. The new chaincode lifecycle must be used instead of the old lifecycle such as install, instantiate, or update a chaincode. After we enable v2 capabilities, we can use chaincode invoke as we did in v1.4
In Hyperledger Fabric documentation, it says “Chaincodes are invoked when a network member wants to transfer or change an asset on the ledger.”
According to documentation, the Fabric chaincode lifecycle requires that organizations agree to the parameters that define a chaincode, such as a name, version, and the chaincode endorsement policy. Channel members come to an agreement using the following four steps (Not every organization on a channel needs to complete each step). I examined all steps on my custom network whose name is be-network
and there are 2 peers which are peer0.be.be-network.com
and peer0.beyond.be-network.com
so the commands we will examine the steps below are modified by considering this situation.
We will use
peer lifecycle chaincode
command with several subcommands. These subcommands accept several flags and parameters. You can use other flags that you want if you need them. You can find the details of flags from here.
Before we examine these steps, you must know that you do these operations by entering the CLI container. We use -e
to add the environment variables of each organization that we have by the following command;
docker exec -e "CORE_PEER_LOCALMSPID=BurakcanEkiciMSP" -e "CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/fabric-samples/be-network/crypto-config/peerOrganizations/be.be-network.com/peers/peer0.be.be-network.com/tls/ca.crt" -e "CORE_PEER_MSPCONFIGPATH=/opt/gopath/fabric-samples/be-network/crypto-config/peerOrganizations/be.be-network.com/users/Admin@be.be-network.com/msp" -e "CORE_PEER_ADDRESS=peer0.be.be-network.com:7051" -it cli bash
Also, in another terminal we can enter CLI container for other organizations by changing environment variables according to the organization we want.
docker exec -e "CORE_PEER_LOCALMSPID=BeyondMSP" -e "CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/fabric-samples/be-network/crypto-config/peerOrganizations/beyond.be-network.com/peers/peer0.beyond.be-network.com/tls/ca.crt" -e "CORE_PEER_MSPCONFIGPATH=/opt/gopath/fabric-samples/be-network/crypto-config/peerOrganizations/beyond.be-network.com/users/Admin@beyond.be-network.com/msp" -e "CORE_PEER_ADDRESS=peer0.beyond.be-network.com:7051" -it cli bash
We must see the following if it is successful;
bash-5.0#
So what the steps are (I mention the definitions of each step that placed in the documentation);
Step 1: Package the chaincode
This step can be completed by one organization. Before installing each peer, the chaincode needs to be packaged. We use peer lifecycle chaincode package
command. It will be executed by peer0.be.be-network.com
peer.
peer lifecycle chaincode package <PACKAGE_NAME> --path <PATH> --lang <LANG> --label <LABEL>
In here;
PACKAGE_NAME
must be a tar file so it must be ending withtar.gz
file extension => I entitled as becc.tar.gzPATH
refers to chaincode path and must be located under the /opt/gopath/src/ directory due to we enter CLI container => I created my chaincode under /opt/gopath/src/chain/mediumchaincode/go/ directory and wrote just chain/mediumchaincode/go/ part due to my chaincode has been written by go, we don’t use /opt/gopath/src/ path if the chaincode is written by goLANG
refers to language that we have used to write the chaincode => I chose golangLABEL
can be any text you want => I entitled as becc_1
Step 2: Install the chaincode on your peers
Every organization that will use the chaincode to endorse a transaction or query the ledger needs to complete this step. We use peer lifecycle chaincode install
and peer lifecycle chaincode queryinstall
commands orderly. They will be executed by peer0.be.be-network.com
and peer0.beyond.be-network.com
peers.
peer lifecycle chaincode install <PACKAGE_NAME>
In here;
PACKAGE_NAME
must be the same as what we gave in the previous step => I entitled as becc.tar.gz
peer lifecycle chaincode queryinstalled
With this command, we approve a chaincode definition to our organizations and it generates the PACKAGE_ID
that will be needed at the next step. It looks like in the image below.
Step 3: Approve a chaincode definition for your organization
Every organization that will use the chaincode needs to complete this step. The chaincode definition needs to be approved by a sufficient number of organizations to satisfy the channel’s LifecycleEndorsment policy (a majority, by default) before the chaincode can be started on the channel. We use peer lifecycle chaincode approvemyorg
command after setting the ORDERER_CA
and PACKAGE_ID
variables for each organization. It will be executed by peer0.be.be-network.com
and peer0.beyond.be-network.com
peers.
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.pemexport PACKAGE_ID={Enter the package id that has been generated at previous step}peer lifecycle chaincode approveformyorg -o orderer.be-network.com:7050 --tls --cafile $ORDERER_CA --channelID <CHANNEL_NAME> --name <CHAINCODE_NAME> --version <VERSION_TAG> --init-required --package-id $PACKAGE_ID --sequence 1 --signature-policy "OR('BurakcanEkiciMSP.peer', 'BeyondMSP.peer')"
In here;
CHANNEL_NAME
refers to channel name that we created=> I entitled as channeldemoCHAINCODE_NAME
refers to channel name that we gave=> I entitled as beccVERSION_TAG
refers to channel name that we gave=> I entitled as 1--signature-policy
can be changed by the organizations in the network (we have just 2 organizations which areBurakcanEkici
andBeyond
)
You must get the following message if the chaincode definitions have been made successfully;
Step 4: Commit the chaincode definition to the channel
The commit transaction needs to be submitted by one organization once the required number of organizations on the channel have approved. The submitter first collects endorsements from enough peers of the organizations that have approved and then submits the transaction to commit the chaincode definition. We use peer lifecycle chaincode checkcommitreadness
and peer lifecycle chaincode check
command in this step. They will be executed by peer0.be.be-network.com
peer.
The peer lifecycle chaincode checkcommitreadness
command is not necessary but we need to check whether we make chaincode definitions successfully for all organizations.
peer lifecycle chaincode checkcommitreadiness -o orderer.be-network.com:7050 --channelID <CHANNEL_NAME> --name <CHAINCODE_NAME> --version <VERSION_TAG> --tls --cafile $ORDERER_CA --init-required --sequence 1
In here;
CHANNEL_NAME
,CHAINCODE_NAME
andVERSION_TAG
must be the same as what we wrote at previous steps.
You must get the following message if the chaincode is ready to commit. We can see that BurakcanEkici
and Beyond
are ready to commit.
If we get the message above, we will execute peer lifecycle chaincode check
command.
peer lifecycle chaincode commit -o orderer.be-network.com:7050 ----channelID <CHANNEL_NAME> --name <CHAINCODE_NAME> --version <VERSION_TAG> --sequence 1 --init-required --tls --cafile $ORDERER_CA --peerAddresses <PEER_ADDRESS> --tlsRootCertFiles <TLS_ROOT_CERT_FILES>
In here;
CHANNEL_NAME
,CHAINCODE_NAME
andVERSION_TAG
must be the same as what we wrote at previous steps.PEER_ADDRESS
andTLS_ROOT_CERT_FILES
refer to peer address and .crt file’s path of each peer that we will commit so write— peerAddress
and— tlsRootCertFiles
as much as the number of our peers.
If we get the message above, everything is ok. We will able to query or invoke whatever peer we want.