Hyperledger Fabric in practice. Main components and running them locally

Vitaly Bezgachev
Coinmonks
Published in
9 min readJul 22, 2017

--

hyperledger కోసం చిత్ర ఫలితం
source

Motivation

Nowadays one of the hyped technologies, along with Machine Learning/Artificial Intelligence, is a blockchain. We are still exploring use cases outside of a crypto-currency world, but the technology itself is promising and it would be quite helpful, in my opinion, to know how this thing works.

You can find plenty materials in the Internet about the blockchain and its history, so it is not my intent to give an explanation here and I assume that you know the basics. Rather I want experiment with one of the technically advanced implementation of a blockchain — Hyperledger Fabric.

Discover and review best Blockchain softwares

Hyperledger Fabric…

Or just Fabric is a flagship implementation of a Hyperledger blockhain framework and was a first project that changed the status from Incubation to Active. It is an open-source initiative, it is under active development and has a very good support. There is no secret that Hyperledger Fabric targets enterprises, so it actually started and contributed by such big player as IBM. I encourage you to check the Fabric architecture document — they provide really good overview.

Distributed ledger

Fabric lives under the umbrella of Hyperledger project, which support collaborative development of distributed ledgers.

Distributed ledger is a peer-to-peer network, where each node maintains a copy of a ledger state. Ledger state is a storage of all transaction that took place in the network. A transaction cannot be modified later, therefore we often talk about immutability of the distributed ledger.

For consistency support (each node in the network must store same transaction in the same order) we need a special mechanism called consensus. It keeps transactions synchronous in the network.

Fabric specialties

Hyperledeger Fabric is a private and permissioned blockchain and has no crypto-currency, so nobody pays for any transaction. In public blockchain everybody can join the network, in Fabric, in opposite, members enrolled through a Membership Service Provider.

Instead of using Proof-Of-Work to ensure consensus, Fabric offers a pluggable architecture, where you can define consensus algorithm yourself. Below we will use most simple implementation — SOLO, where we have only one consenter for a chain that receives transactions, orders them and forms blocks to write into the ledger.

You can have several channels in one blockchain network, allowing a group of participants creation of a separate ledger of transactions that are not visible to other members of the network.

For the updates of the ledger Hyperledger Fabric introduces Smart Contracts. They can be written, theoretically, in any language and allow keeping the ledger in a consistent state according to our needs. At the moment, only Go is well supported to program the contracts. Such program is called chaincode.

Note: Hypeledger association just announced an official release of Fabric version 1.0, which brings significant improvements.

Endorsement

One special thing about Fabric is the endorsement process. Any transaction, initiated by a client application, must be endorsed. A client application generates a transaction proposal and send it for validation to endorsement peer(s) of its choice.

The endorsing peers verify (1) that the transaction proposal is well formed, (2) it has not been submitted already in the past, (3) the signature is valid, and (4) that the submitter is properly authorized to perform the proposed operation on that channel (e.g. writing into the channel). The endorsing peers take the transaction proposal inputs as arguments to the invoked chaincode’s function. The chaincode is executed against the current ledger state to produce transaction results including a response value, read and write sets. No updates are made to the ledger at this point. The set of these values, along with the endorsing peer’s signature and a YES/NO endorsement statement is passed back as a “proposal response” to the client application.

The client application check whether the validation was successful, check the signature of endorsing peer(s) and only then a transaction goes for execution. Here is a graphical explanation (taken from IBM site) of the process:

You can find more details of a transaction flow here.

Components we need

So now we can go from a theory to a practice. For our practical experiment we need the following components of Fabric:

  • Membership Service Provider (or Certificate Authority)
  • Orderer
  • Peer
  • Organization

Membership Service Provider (MSP)

I encourage you to check the Fabric documentation about MSP. Long story short — we need MSP for issuing and validating certificates and user authentication.

The configuration of the MSP must be specified locally at each peer and orderer (to enable peer and orderer signing) and on the communication channel to enable participants identity validation and respective signature verification for the members. For MSP certificate generation we will use a special tool cryptogen, provided by Fabric.

Note: in the Fabric version 1.0 they renamed MSP into Certificate Authority (CA), so I’m using both terms interchangeably.

Orderer

Orderer (or ordering service) provides a shared communication channel to client applications and peers, offering a broadcast service for messages containing transactions. Orderer provides atomic delivery, means that communication channel outputs the same messages to all connected peers and in the same logical order. This atomic communication guarantee is also called consensus in the context of a distributed system. The communicated messages are candidate transactions for inclusion in the ledger state.

Peer

Peer receives ordered ledger state updates in the form of blocks from the orderer and maintains the state of the ledger. Peers can additionally take up a role of an endorsing peer (see the transaction workflow above).

Organization

Organizations logically separates members (peers) and the may or may not share the MSPs. It is recommended to have one MSP per organization and we follow that recommendation.

Deploy the Fabric blockchain network locally

Let’s begin the funny part :-) I ran everything under Ubuntu 16.04. We need:

Hint: after you install Go, set the environments variables properly. For Ubuntu I have:

export GOPATH=~/go
export GOROOT=/usr/local/go
export PATH=$PATH:/usr/local/go/bin
export PATH=$PATH:$(go env GOPATH)/bin

It must be done, otherwise Fabric could not run properly.

Get Hyperledger Fabric

First we have to clone the Fabric repository. Fabric is written on Go, so we need to follow Go conventions and clone repository under certain folder.

cd $GOPATH
mkdir src
cd src
mkdir github.com
cd github.com
mkdir hyperledger
cd hyperledger

Now we are ready to clone the repository:

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

Build Fabric and create Docker images

Fortunately Fabric team made a great job and prepared a lot of stuff. But first we must install dependencies:

sudo apt install libtool libltdl-dev

Now we are ready to build Hyperledger Fabric:

cd fabric
make release-all

… and wait ca. 5 minutes. Next we create Docker images for Hyperledger Fabric:

make docker

It takes another 5–10 minutes to download and build the stuff. If you check now the Docker with

docker images

you should see many hyperledger/fabric-… images tagged with x86_64–1.0.1-snapshot-… and, optionally, latest.

Build network configuration

Fabric provides pretty useful example, especially, for beginners.

cd examples

If you check, what is inside the folder, you will see a couple of sub-directories, 2 of them are a point of our interest: chaincode and e2e-cli.

chaincode contains examples of a chaincode, written on Go. I do not go into details in this article, I’m planning to do that in my next posts.

e2e-cli is our example of the blockchain network. First we need to generate network configuration (or network artifacts). Particularly we must:

  • Generate certificates for validation, signing and authentication of members. This will do the tool cryptogen
  • Generate channel configuration: genesis block, configuration transaction, anchor peers. This will do the tool configtxgen

Both tool we built earlier and you can find them under $GOPATH/src/github.com/hyperledger/fabric/release/<OS architecture>/bin. In my case <OS architecture> was linux-amd64.

Before running the script, insert following lines:

ARTIFACTS_DIR=”./channel-artifacts”
if [ ! -d “$ARTIFACTS_DIR” ]; then
mkdir “$ARTIFACTS_DIR”
fi

at the beginning of the

function generateChannelArtifacts()

configtxgen do not create output directory if it does not exist, so we must take care of it. Then run the scirpt:

cd e2e_cli
./generateArtifacts.sh <channel-ID>

where channel-ID is a name of the communication channel, i.e. testchannel.

Caution: I would recommend to use just character and numbers for the channel name. I’ve got errors when I named a channel my_channel (with _ in the name).

You find configuration for the certificate generation in crypto-config.yaml. It contains the network topology and allows generation of certificates for organizations and their components. You’ll find the output in crypto-config folder. Each organization is provisioned with unique root certificate (ca-cert), that binds specific components (peers and orderers) to it. Transactions and communications within Fabric are signed by an entity’s private key (keystore), and then verified by means of a public key (signcerts).

Channel artifacts are configured in configtx.yaml. Here you see headers for organizations and genesis block, anchor peers, orderer and location of the Member Service Provider directory for each member. It is worth to note that we use SOLO orderer, i.e. most simple ones. We pass header names as parameters for configtxgen tool. You will find the output in channel-artifacts folder.

And the last generated file is docker-compose-e2e.yaml — a Docker Compose file with orderer, peers and certificate authority. We do not need certificate authority yet, so we do not use this file in our experiment.

Start the blockchain network

The example provides all-in-one script network_setup.sh, which we use to run the network. We create a network consisting of one orderer, 2 organizations and 4 peers (2 for each organization). The peers will use CouchDB database to keep the ledger state. Additionally we create a CLI (Command Line Interface) container to “talk” to the network members. Now start the script:

./network_setup.sh up testchannel 10000 couchdb

First parameter is a channel name, second — is a timeout for CLI container (next 10000 seconds CLI container is alive and you can use it to operate on a blockchain) and third parameter instructs to use CouchDB as a storage of the ledger state on peers. The script runs Docker containers for orderer, peers, CouchDB and CLI.

When CLI container starts, it executes ./scripts/script.sh to setup a network. It is worth to note that CLI uses peer executable with appropriate arguments to execute operation on the network. The script is pretty straightforward:

  • Create orderer communication channel testchannel. Remember, we execute all operations on the communication channel where the orderer plays a central role.
  • Join all 4 peers to the channel — peer 0 and 1 belong to org. 1, peer 2 and 3 belong to org. 2
  • Sets anchor peers for both organizations (peer 0 for org. 1 and peer 2 for org 2)
  • Installs chaincode ../chaincode/go/chaincode_example02 on peer 0 and peer 2. The chaincode saves two variables in the ledger and update them decreasing a first variable and increasing the second ones by the same value
  • Instantiates chaincode on peer 2. Instantiation adds the chaincode to the channel, starts separate container for peer 2 and initializes the value pairs associated with the chaincode. Note that the transaction (chaincode instantiation) must be endorsed. I have marked relevant parameters. Here we see the endorsement policy, which means that any transaction must be endorsed by a peer tied to org. 1 or org. 2.
peer chaincode instantiate -o orderer.example.com:7050 --tls $CORE_PEER_TLS_ENABLED --cafile $ORDERER_CA -C $CHANNEL_NAME -n mycc -v 1.0 -c '{"Args":["init","a","100","b","200"]}' -P "OR    ('Org1MSP.member','Org2MSP.member')" >&log.txt
  • Queries chaincode for current values on peer 0. Query creates a separate Docker container for peer 0 to execute a chaincode
  • Changes values via invoking of a chaincode in the ledger state on peer 0
  • Installs chaincode ../chaincode/go/chaincode_example02 on peer 3
  • Queries chaincode for current values on peer 3. Query creates a separate Docker container for peer 3 to execute a chaincode

You follow the process with log information printed into the terminal. After start and configure you should have Docker containers for:

  • 1 Orderer
  • 4 Peers
  • 3 Chaincode executors
  • 4 CouchDb
  • 1 CLI

Check this with the command:

docker ps

You can see the chaincode output in the peer logs. Here is an example:

docker logs dev-peer1.org2.example.com-mycc-1.0ex02 Invoke
Query Response:{"Name":"a","Amount":"90"}

When you are finished, do not forget to shutdown the network (all containers will be stopped and removed):

./network_setup.sh down

Conclusion

We successfully created all necessary components of a blockchain network in Docker containers and configured the network properly. We also demonstrate that the network functions by deploying and operating a sample chaincode.

Now we have a basis for the application development on the Hyperledger Fabric blockchain:

  • Put more logic into the chaincode
  • Write simple web application to write the data to and read the data from the blockchain

Join Coinmonks Telegram Channel and Youtube Channel get daily Crypto News

Also, Read

--

--