Installing Hyperledger Fabric v1.1 on Ubuntu 16.04 — Part II & Part III

 

This entire tutorial is the second part of the installation of Hyperledger Fabric v1.1. In the previous article, we installed all the dependencies required for us to make the Fabric environment run. In this part of the tutorial, we aim to launch our own example network and learn to fire some transactions and query the Blockchain network to retrieve the values.

So, at first, Hyperledger Fabric Project has provided a lot of detailed examples and documentation on its site. But the one we’ll be following is the e2e_cli code example in examples directory.

To get started, we first need to clone the Fabric Project on your machine. So, go ahead and fire the command below:

git clone https://github.com/hyperledger/fabric.git

After cloning the project to a safe location, make sure the directory structure is similar to one described below:

<word directory>/src/github.com/hyperledger/fabric

Please refer to the below image for further explanation:

 

I already have the project cloned, so my output will differ from yours. But, at the end, you should have fabric project in your current directory. Now, that we have the project cloned into our work directory, we need some functions to be build to ensure our smooth journey towards the execution environment. So, we need to build functions, like:

configtxgen
cryptogen

“configtxgen” takes in configtx.yaml file and builds your genesis block for the channel and contains metadata associated with the channel, which is broadcasted to the Orderer. So, this is like the block 0 of the network, which is needed to make sure that our chaincode is deployed on top of it. “Cryptogen” is used to generate the certificates according to the organizational structure of the organizations participating in the blockchain.

To enable the building of the tools, we need to set the GOPATH variable in the ~/.bashrc or ~/.bash_profile file of the user logged into. This is to enable fabric to locate the source code to enable building of the commands. For that, we add the following line to the ~/.bashrc or ~/.bash_profile file:

export GOPATH=~/Documents/Blockchain

GOPATH will always be your work directory. So, if you have a different Work Directory, then please state that as your GOPATH. Now, we are ready to build the tool. To build the tool, we write (from the root directory of the fabric project):

make configtxgen cryptogen

So, if all goes well, we will have the following output:

 

If there is some error regarding a library, ‘ltdl.h’, fire the following command and it should probably be fixed:

sudo apt install libtool libltdl-dev

If still the problem pertains, maybe you want to check out the stackoverflow and jira for the Hyperledger Project, link (https://jira.hyperledger.org)

So, considering all goes well, we now have our tools, configtxgen and cryptogen, in build/bin directory, relative to Fabric’s root directory.

Now, we move to the examples/e2e_cli directory, for some real blockchain deployment and transactions stuff. So, to use the configtxgen tool and generate the genesis block and configurations for the channel, we use the following script, which by-default creates the files.

 

This is the output one should receive after a successful execution of the command:

./generateArtifacts.sh

Now, that we have the genesis block, we need containers to run our blockchain network. Hyperledger Fabric suggests that one should use Docker containers for these kinds of work, so that it is isolated from the host tasks and enables customization and tweaking. So, to download all the required images, run the command from the fabric root directory:

make docker

This will download all the required images and when you check the installed images using:

docker images

You should see a similar output as below:

 

Now, that we have the images with us, we will now start our network and run the all-in-one script to test everything is working fine or not. In our ecosystem, we have 1 Orderer, 2 Peers from 2 Organisations each and 1 CLI to access the logs and fire custom transactions.

./network_setup.sh up <channel-id>

If you provide a channel-id argument, it will create the channel with the specific channel-id or else keep “mychannel” as the default channel-id name.

If everything goes well, then, upon a successful execution, you should see the following output:

 

Now, that we have run the automated tests, we know that now we can create our own network and fire transactions from that too. Stay tuned for the next article, depicting, how to manually do the steps, we just did with the network_setup.sh file.

To bring down the network, fire the command:

./network_up.sh down

The above command deletes all the extra images that were created to ensure the channel and chaincode data access.

Last Updated: 2018–07–09

---

Now, that we have run our first sample Hyperledger Fabric Network using All-in-one script in the previous article, we are going to rip that apart and write our custom commands from scratch to understand how it works and what is the correct way of writing the commands.

For this tutorial, we’ll need the images running, so, we need to first edit the docker-compose-cli.yaml, in examples/e2e_cli directory, file to ensure that all-in-one script is not run when starting the images. So, scroll down to the part where the cli image is configured and change the commented lines as shown in the picture below:

 

So, now use the following command, from the examples/e2e_cli directory:

docker-compose -f docker-compose-cli.yaml up

Upon successful execution, you should have an output similar to mine:

 

Now, that we have our network running, we want the execute the following queries in sequence:

1. Create a new Channel
2. Join Peers on that channel
3. Install Chaincode
4. Instantiate Chaincode
5. Invoke Chaincode
6. Query Chaincode

So, we’ll go through all these steps, one by one.

Create a new Channel

So, to run our network, HF v1.0, uses the concept of Channel, which logically differentiates your chaincode from other parties chaincode. So, to create a new channel, we need to login into the CLI image and fire commands from that only.

To login into the CLI image, use the following command:

docker exec -it cli bash

You should see an output similar to the one shown below:

 

Now, we need to create a new channel, so the let us first set some environment variables, so that we don’t need to edit them again and again. This tutorial focuses on creating the transactions on a single peer, but the network is multiple peer. To keep the simplicity of the tutorial, we use only peer0 to fire the queries from. Other peers can be used, just by altering some environment variables and TCerts.

CORE_PEER_MSPCONFIGPATH = /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peer/peer0/localMspConfig
CORE_PEER_ADDRESS = peer:7051
CORE_PEER_LOCALMSPID = “Org0MSP”
CORE_PEER_TLS_ROOTCERT_FILE = /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peer/peer0/localMspConfig/cacerts/peerOrg0.pem
ORDERER_CA = /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/orderer/localMspConfig/cacerts/ordererOrg0.pem

Here is the screen shot of all the variables, we have set:

 

Now, let us get a brief understanding of what every variable means:

1. CORE_PEER_MSPCONFIGPATH = This variable takes into account the path where it can find the peer’s certificates for signing the transactions.
2. CORE_PEER_ADDRESS = This defines the IP Address of the Peer we are contacting and firing the transaction on.
3. CORE_PEER_LOCALMSPID = This variable takes into account the Organisation name, it belongs to.
4. CORE_PEER_TLS_ROOTCERT_FILE = This variable is the path to the CA file of the peer, which is used in mutual TLS with the Orderer.
5. ORDERER_CA = This path is for the CA Certificate of the Orderer, which is required when creating channel and joining peers, as only Orderer has the authority to create the channel.

Now, that we have a basic understanding of how everything work, let’s get started and create our first channel:

peer channel create -o orderer0:7050 -c mychannel -f crypto/orderer/channel.tx — tls true — cafile $ORDERER_CA

From the command, it is clear that “-o” is used to define the orderer’s IP Address we are trying to connect to. “-c” defines the channel name we are giving to our new channel. “-f” is the genesis file that we will need to create our genesis block, which contains data about the network, organizations and affiliations. “ — tls true — cafile <filename>” is for enabling the TLS and sending the transaction, as our network we just started above is running on Mutual TLS and will require a CA Certs file.

After the successful execution of the above command, you should a similar to below:

 

Now, that we have created our channel, we are good to go and join our peers on the channel. Let’s move to the next section then.

Join Peers on the Channel

Once, we create a new channel, Orderer sends us a new .block file, which is the genesis block of the network. We will need this .block file to tell the peers where are we joining.

peer channel join -b mychannel.block

After successful joining, you should have an output similar to mine:

 

Please take into account that we are only joining 1 Peer to the network, so that to attain simplicity in the transactions. You can always go ahead and add more peers by changing the variables we just created above.

Now that we have a successful join, we now move onto the next section.

Install Chaincode on the Peers

Now, that we have joined our peer to the network, we need to install the chaincode too. Chaincode is basically the business logic of the application, that we are trying to run on the network. Some might even call it as Smart Contracts.

peer chaincode install -n mycc -v 1.0 -p github.com/hyperledger/fabric/examples/chaincode /go/chaincode_example02

Let us understand what we are trying to achieve here. We are naming our chaincode as “mycc”, so that we don’t need to refer to our chaincode via the path always. “-v” tells the network that this is my version of the chaincode, accept it. “-p” describes the path to the actual chaincode directory.

Here is the output upon successful execution:

 

Now, that we have our chaincode installed, let us create some entities and assign some value to it. As this is our first transaction related to the Chaincode, we have to use the Instantiate command, which is explained the next section.

Instantiate Chaincode

Now, lets create some new entities and assign values to them. The chaincode we just installed above is about transferring value from one user to another.

peer chaincode instantiate -o orderer0:7050 — tls true — cafile $ORDERER_CA -C mychannel -n mycc -v 1.0 -c ‘{“Args”:[“init”,”a”,”100",”b”,”200"]}’ -P “OR (‘Org0MSP.member’)”

Now, let us understand what each flag means. We already about the “-o”, “ — tls true — cafile $ORDERER_CA”. Now let us look into the others. “-C” defines the channel name, “-c” defines the argument we are passing to the chaincode. “-P” is the endorsement policy, which defines how many people should endorse before a transaction becomes a valid transaction. Here we are writing that a member of Org0 should sign it and only then it should become a valid transaction.

After creating the transaction, the output should similar to mine:

 

Now, as we are only using 1 peer to fire all the transactions, if we want to use another peers, we need to join them to the channel and install the chaincode onto them, separately. But, we don’t need to fire the instantiate chaincode command again and that is taken care of by the network, once you install the chaincode.

So, having done with it, let’s move onto invoking some transactions onto the network.

Invoke a Transaction

Now, that we have created two entities, a and b, we will want to transfer some amount between to create a transaction. So, for this tutorial, we are going to transfer 10 units from a to b. The command looks like the following:

peer chaincode invoke -o orderer0:7050 — tls true — cafile $ORDERER_CA -C mychannel -n mycc -c ‘{“Args”:[“invoke”,”a”,”b”,”10"]}’

We already know all the command line tags, so we move onto the screenshot of the final result, to let you verify of the correct result.

 

The highlighted part shows that the transaction went through and we have successfully transferred 10 units from a to b. Now, we will query the chaincode to see if we can fetch the new values of a and b.

Query Chaincode

Now, that we have invoked the chaincode for the transfer of 10 units from a to b, we want to check whether our transaction really went through or not. Also, we want to fetch the new values of a and b.

peer chaincode query -C mychannel -n mycc -c ‘{“Args”:[“query”,”a”]}’ 
peer chaincode query -C mychannel -n mycc -c ‘{“Args”:[“query”,”b”]}’

Here is the screen shot to verify the result:

 

So, I did fire a query request for both the variables to check that the 10 unit subtracted from a did get added to b.

So, with this, we are at the end of the tutorial.

In this, we tried to run the network one step at a time and tried to explain what each term means to have a better understanding and knowledge for creating our own Chaincode. Please do write in the comment section below for any queries you might have.

If you have any doubts or errors, please email hyperledger@mlgblockchain.com and we shall get back to you as soon as possible, with a solution.