The previous chapter analyzed hyperledger fabric to build network nodes and create channels step by step. This chapter is based on the smart contract deployed in the official example in Chapter 2, and will also be analyzed step by step.
As usual, first give the download URL of the official sample: https://github.com/hyperledger/fabric-samples
The picture above is the fabric test network I built in the last chapter. I created 6 org nodes and 1 order node .
In the fabric, the smart contract is called chaincode.
Step 1: Pack chaincode
What is packaging chaincode? It is packaging the contract you wrote. You can use go, java, nodejs to develop the contract. These codes need to be built according to a specific format, and then packaged through the command peertool in the bin.
CC_NAME=mychannel
CC_SRC_PATH=你的智能合约代码地址
CC_RUNTIME_LANGUAGE=javascript # or go, java, typescript
CC_VERSION=1.0
peer lifecycle chaincode package ${CC_NAME}.tar.gz --path ${CC_SRC_PATH} --lang ${CC_RUNTIME_LANGUAGE} --label ${CC_NAME}_${CC_VERSION}
Package a tar.gz file, which is the chaincode installation package that fabric nodes can use to install.
Pay attention to all the nouns in this chapter: chaincode=contract=smart contract, I don’t know why IBM calls this chaincode, I prefer the smart contract name, contract.
Step 2: Install chaincode
# 为orgX设置环境变量
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/[email protected]/msp
export CORE_PEER_ADDRESS=localhost:7051
peer lifecycle chaincode install ${CC_NAME}.tar.gz
Note that the bin peercommand given by hyperledger has many uses. It can be used to install chaincode, but it needs to set terminal-level environment variables. This is what I want to complain about. Why can’t it be executed directly through the config file or option? Like ssl commonly used remote connection operations.
If you are installing chaincode for org2, 3, 4..., then you need to modify their environment variables to point to the addresses of encrypted files of other orgs. These encrypted files are created in the previous chapter and used for org cryptogenauthentication All rights are in the organizations directory, which contains the digital certificate of the node.
Step 3: Agree to the chaincode
After installing the chaincode for each node, the node needs to agree to these contracts, that is, the approve operation. This is actually very cumbersome. I think it can be simplified as: installation means approval. There is no need to complete such a link. Since the node has installed this A contract (chaincode) is equal to a default agreement. I find many operating commands in Farbic very tasteless. . .
# 设置当前org环境变量
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/[email protected]/msp
export CORE_PEER_ADDRESS=localhost:7051
ORDERER_CA=${
PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
PACKAGE_ID= #上一个步骤安装chaincode获得的id码
peer lifecycle chaincode approveformyorg -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls --cafile "$ORDERER_CA" --channelID mychannel --name fabcar --version 1 --package-id ${PACKAGE_ID} --sequence 1 --init-require
Note that all peerplaces where the command tool is used need to configure the environment variables of the current node, the same as the previous step. Of course, if you have org2, 3, 4... you need to repeat the above shell and change the environment variable to point to the corresponding org encrypted file address,
Step 4: Commit Chaincode
Forehead. . . I personally think this step is a tasteless step. The nodes are all installed, and the contract has to be committed after agreeing to the contract. Moreover, the steps of commit are very complicated, and I am also drunk. But the official document says so, let's just follow the steps.
parsePeerConnectionParameters() {
PEER_CONN_PARMS=()
PEERS=""
while [ "$#" -gt 0 ]; do
setGlobals $1
PEER="peer0.org$1"
## Set peer addresses
if [ -z "$PEERS" ]
then
PEERS="$PEER"
else
PEERS="$PEERS $PEER"
fi
PEER_CONN_PARMS=("${PEER_CONN_PARMS[@]}" --peerAddresses $CORE_PEER_ADDRESS)
## Set path to TLS certificate
ORG=$1
CA="${
PWD}/organizations/peerOrganizations/org${ORG}.example.com/peers/peer0.org${ORG}.example.com/tls/ca.crt"
TLSINFO=(--tlsRootCertFiles $CA)
PEER_CONN_PARMS=("${PEER_CONN_PARMS[@]}" "${TLSINFO[@]}")
# shift by one to get to the next organization
shift
done
}
ORDERER_CA=${
PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
peer lifecycle chaincode commit -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls --cafile "$ORDERER_CA" --channelID mychannel --name ${CC_NAME} "${PEER_CONN_PARMS[@]}" --version 1 --sequence 1 --init-require
A custom shell function is used here, which is not complete. In fact, all peer nodes are traversed here tlsRoorCertFiles. The actual command line is very long. The final command output by the shell is as follows:
peer lifecycle chaincode commit -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 --channelID mychannel --name fabcar --peerAddresses localhost:7051 --tlsRootCertFiles ${
PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt --version 1 --sequence 1 --init-required
In the source code, I actually used a total of 6 org nodes. Here I simplified it to 2, and the command format is the same.
Here is a simple explanation: this commit operation is actually similar to org reporting the result of accepting the chaincode to order, so the structure of the command is order node + org1 + org2... In this way, as many orgs as there are after passing the contract will be connected to as many orgs , attach the org tlsRootCertFiles.
Step 5: Execute the contract initialization code invoke (not necessary)
This step is to execute the init function in the chaincode. It is not necessary, but the user also needs to execute it when reading and writing the contract, so this step can be attributed to the process of deploying the contract.
Or use peerthe tool to execute invoke
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 fabcar --peerAddresses localhost:7051 --tlsRootCertFiles ${
PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt --isInit -c '{"function":"initLedger","Args":[]}'
This command has the same format as the previous one, but it is executed function initLedger, that is, the ledger is initialized.