Deploying smart contract with the Hyperledger Fabric chaincode
Why smart contracts are smart?
In Hyperledger Fabric, smart contracts are deployed in packages known as chain codes. When two or more parties sign a contract and execute it, there are a lot of intermediaries that are involved in the process, making it lengthy, cumbersome, costly, and less credible.
A smart-contract that is based on Blockchain technology is faster, immutable, and has the ability to handle business models more effectively.
Deploying a smart contract
Blockchain technology emphasis on trust and changes the way the enterprises operate. Blockchain smart contracts are one of the most trustworthy way of publishing and saving contracts. This technol0gy helps to eliminate any third parties in the business operations, and increases the overall efficiency.
A Blockchain chaincode is deployed to a channel by means of the Fabric chaincode lifecycle. Let’s have a look at how smart contracts are deployed on the Hyperledger Fabric network:
1. Start the network
We will take the example of Fabric test network. Make sure that the pre-requisites and samples ae installed before the deployment process.
- The following command can be used to direct to the test network directory:
- After this, the following command can be used to start the test network:
./network.sh up createChannel
The createChannel command creates a channel i.e. mychannel. This channel further contains two-channel members, Org1 and Org2.
Following steps are used to deploy the chaincode to the channel:
Step One: Package the smart contract
- In the
package.jsonfile in the
package.jsonfabric contract class is imported into the smart contract package.
AssetTransferclass mentions the business context for the functions that are demarcated within the smart contract.
- After defining the dependencies, we can install the chaincode package. The
test-networkfolder helps us to package the chaincode together with other artifacts.
- To create a chaincode package in the required format
PeerCLI is employed. The
Peerbinaries are located in the
binfolder of the
To confirm that you can use the
Peer CLI, check the version of the binaries. The binaries need to be a version of 2.0.0 or later.
The command will create a package named in the
basic.tar.gz current directory.
Step two: Install the chaincode package
After we package the basic smart contract, we can install the chaincode on our peers.
Both the peers need to be installed as we are going to set the endorsement policy to require the authorizations:
Let’s install the chaincode on the Org1 peer first, set the following environment variables to operate the peer CLI as the Org1 admin user. The
CORE_PEER_ADDRESS will direct to the Org1 peer,
- The following command is issued to install the chaincode on the peer:
peer lifecycle chaincode install basic.tar.gz
- If the command is successful, the peer would generate and return the package identifier. The chaincode on the Org2 peer can now be installed. Set the following environment variables to operate as the Org2 admin and target the Org2 peer,
- The following command should be issued to install the chaincod
peer lifecycle chaincode install basic.tar.gz
After this command, the chaincode would be built. The install command will return any build errors from the chaincode, in case there is a problem with the smart contract code.
Step three: Approve a chaincode definition
After you have installed the chaincode package, it is important to approve the chaincode definition for your organization. The definition includes the important parameters of the chaincode governance.
- The package ID of any chain-code can be found by the following command:
peer lifecycle chaincode queryinstalled
Note: The package ID will not be the same for all the users.
- You need to approve the chaincode definition with an identity that has an admin role. As a result, the
CORE_PEER_MSPCONFIGPATHvariable needs to point to the MSP folder that contains an admin identity.
Step four: Constraining the chaincode characterisation to the channel
An organization can obligate the chaincode definition to channel when a required number of organizations have approved the chaincode definition.
- The peer
lifecycle chaincode check commit readinesscommand can be used to check whether channel members have approved the same chaincode definition.
- The chaincode description authorizations by channel members are submitted to the ordering service to be distributed to the channel. The command will wait for the validations from the peer before returning a response.
- If the chaincode was successfully committed to the channel, the
query committedcommand will return the sequence and version of the chaincode definition.
Step five: Invoking the chaincode
When we are done constraining the chain-code definition to a channel, the chain-code would start working on the peers that are joined to the chain-code channel.
The asset-transfer (basic) chaincode is now prepared to be appealed by consumer applications.
Remember that the invoke-command needs to target a sufficient number of peers to meet the chaincode authorization policy.
When you are finished using the chaincode, the following commands can be used to remove the Logspout tool.
docker stop logspout
docker rm logspout
You can then bring down the test network by issuing the following command from the test-network directory: