Teach yourself - Hyperledger Fabric : Hour 05:00 — Network Setup — Part 1

Hello, thanks for taking the time to read this series. I believe you have started from Hour 00:00, if not please do that before you proceed further.

In this article, we will set up the network from scratch, to do that, we need to understand few files & it’s configuration.

So when you set up “Build your first network(BYFN)” from fabric-samples, you would see these binary files in the bin folder

• cryptogen,
• configtxgen,
• configtxlator,
• peer
• orderer and
• fabric-ca-client

What each binary does is special in fabric server. When you develop your own network, you must declare or define who is going to do what?. for example, let’s take a real time example. A typical supermarket story here, sales boy/girl to help the customer in finding the products, housekeeping person will ensure the environment is clean, the person at billing section does only the billing job. So similarly, while deploying network you must define who is going to do what?. ( Read this transaction flow in Hyperledger official document to get a better understanding: Click here of what’s happening when a transaction is invoked). So in a network, we have 4 components(Orderer, Peer, CouchDB, CA) and who is going to perform these roles, will be decided and respective identity/access will be generated.

For instance, when a new employee is joining the organization(company), we provide him/her access card/identity card right?, similarly in fabric network, we must define identity, which will be provided by MSP(membership service provider). To do that job, we use the binary file CRYPTOGEN.

Now, let’s talk about CONFIGTXGEN .. again a real-time example of a supermarket, the moment the day starts they create one dummy billing ID in order to ensure billing application runs fine & also for goodwill. This dummy billing ID doesn’t add any value in fact, but they start the day with dummy billing ID to start the billing number for the day. Similarly, in the blockchain, we have something called “Genesis” block(The configuration block that initializes a blockchain network or channel and also serves as the first block on a chain). I will not say this as Dummy, but a very crucial block in a chain, which actually indicates the “Starting” point of blockchain. CONFIGTXGEN actually does this job, it creates genesis block for the network.

Now it’s time for CONFIGTXLATOR (Read this Click here) , I can relate this with “Optimizer or Upgrader”. For instance, you have the network setup with channels, when you want to modify the channels or update genesis block, then you need to edit the same, CONFIGTXLATOR file helps you to first convert the block into human readable form & once you make necessary changes, it commits & upgrades the same.

CONFIGTXLATOR: standard usage is expected to be:

1. SDK retrieves latest config
2. configtxlator produces human-readable version of config
3. User or application edits the config
4. configtxlator used to compute config update representation of changes to the config
5. SDK submits signs and submits config

Peer (straight forward), it helps to perform a set of actions. For instance, using Peer Channel subcommand, you can add the peer to a specific channel, Peer Chaincode helps you to deploy chain code to the peer & so on.

The fabric-ca-client command allows you to manage identities (including attribute management) and certificates (including renewal and revocation).

Orderer using this binary, we can start the orderer. It will use the generated “Genesis block”. If it’s not available, it generates a new genesis block using SOLO orderer profile.

Having all these six binaries covered, it is very important to understand in which situation we use each. Let’s begin with a fresh network, absolutely fresh network & we are going to setup using above binaries..and define those 4 components.

Let’s set up the network now.

First, we need to define who will do what role!, as I mentioned before. Go ahead & download the fabric-sample using below command.

Here 1.4.0 -> indicates fabric.. If you want to download a specific version, you can.

curl -sSL http://bit.ly/2ysbOFE | bash -s 1.4.0

Step 1: Go to “Fabric-Samples” folder, find binary files in the Bin folder. Copy all those in your new folder(I name it as mynetwork)

Step 2: Go to “Fabric-samples/first-network” folder, copy down crypto-config.yaml file into your mynetwork folder

it’s time to deep dive this file & make the necessary changes..

This file basically has few components, first one is ORDERER (very important) component in fabric network, there are two types of Orderer. First one is “SOLO” & another one is “Kafka” based. SOLO is single orderer and using this in a development environment is fine, but in production STRICTLY NO!.. you will end up losing your data when the network is down.

Here, most of the names given are “User Defined”, so your identity(CA) will be created basis this names, so while mapping this orderer with respective fabric-images, you should use the same names/ca files. Best practice is that, use proper naming standards, so that it will be easy to identify which container belongs to which components.

In the above image, “Name of the Orderer is “Orderer” & the domain is example.com (do not use any special characters). So the final name for this Orderer will be “{{.Hostname}}.{{.Domain}}” and in our example, it is “orderer.example.com”

Above image shows, that we have two Organization & peers for each org respectively. Let’s go one by one.

PeerOrgs -> indicates this section belongs to defining peers

Name -> Organization name, here it is Org1

EnableNodeOUS : true? indicates the ability to classify identities as either a “client” or a “peer”. This allows you to create policies such as Org.peer andOrg.client in addition to the existing Org.memberand Org.admin. If you enable this feature, CRYPTOGEN will generate MSPs accordingly.

Template: count 2, Indicates 2 peers will be created under this organization (org1), so the peer name will be like peer0.org1.example.com, peer1.org1.example.com

Users: count 1, indicates one user identity will be created. In reality, or in production Fabric-CA does the job for us. It creates an identity for new users. But in development, we will use CRYPTOGEN(Binary file)

Similarly for the next peer(Org2).

In this file, we have seen how to setup Orderer, Peers, Organization & User. While defining your network, you will end up spending a good amount of time in this file, since generating the right identity & certificates matters the most.

Ok, it’s all set, now it’s time to generate our certificates. Go to terminal & execute this command, you will see Org1.example.com & Org2.example.com as results

./cryptogen generate --config=./crypto-config.yaml

Congratulations, you have created the certificates for those components successfully, now go to your directory & navigate through each folder & check how many folders/files it has created.

It is very important to understand, what each folder is & what it does, spend some good time to navigate through and understand the folder structure.

Now, we need to generate the “Genesis Block”, the first block of the blockchain. It determines the structure of a network, so it is very critical and should understand it end to end.

Go to fabrics-sample/first-network folder & copy configtx.yaml file, this has the configuration details to generate “Genesis Block”. Let’s understand each section.

In this section, you provide the following information..

i) OrdererOrg MSP Path

ii) PeerOrg MSP Path

iii) Declare which peer does “Anchor” role and corresponding Port Number.

The “Name’, “ID” is user defined, but keep it meaningful, this will help you to configure the rest of the network easily.

MSPDir -> is the path where the MSP file resides for orderer & the peer organization. Remember that, our first step to generate the certificates? those are the path has all these files. So go & explore once again if you want to.

AnchorPeers from Org1 can able to communicate with AnchorPeers from Org2. Basically, these communications happen through gossip protocol, We call it as GRPC(Gossip Remote Procedure Call)

Here, we will declare the orderer details. Note that, the first parameter is ordererType which is “Solo”. As I mentioned earlier, for a development environment you can go with “Solo”.

Addresses: -> Indicates the orderer domain name, so orderer.example.com:7050 (Port number)

BatchTimeout, BatchSizes -> these two parameters are important for block creation. For example, Orderer job is to form a bunch of transaction and form it as batch & transmit to “Committing Peer” for validation before it commits. So batch sizes determine the same, in the above file MaxMessageCount — 10 indicates 10 transactions are allowed to form a batch or block.

So when does a block commits? — Using the above configuration network determines that, so batch timeout or batch size determines when to commit a block. For every 2seconds a block gets committed or when transaction count reaches 10 it commits. So whichever comes first, 2seconds or message count reaches determines the block commit scenario.

Kafka Parameter is to provide the domain & port number when you use Kafka orderer type since we are into development you can ignore it.

Profile section is the main part, where it reads whatever we declared in first few sections of the configtx.yaml file. In this file, we are declaring this genesis file as “TwoOrgsOrdererGenesis” for orderer details & “TwoOrgsChannel” for channel details.

Consortium: indicates more organization work together or form a network, here we name it as “SampleConsortium” & indicating that both Org1 & Org2 is participating.

Similarly, in “TwoOrgsChannel” — Two organization can communicate via this channel, can read the data, can write the data, can share the data via this channel.

Now it’s time to generate Genesis Block & Channel.. Go-ahead & execute the following command from your terminal

./configtxgen -profile TwoOrgsOrdererGenesis -outputBlock ./genesis.block

This command should create a file called genesis.block in your current folder.

Next, let’s create a channel file by executing below command…

./configtxgen -profile TwoOrgsChannel -outputCreateChannelTx ./mychannel.tx -channelID mychannel

this command generates the file called mychannel.tx with the channelID mychannel. Now, org1 & org2 can communicate via mychannel.

So, we have covered a lot in this article, let’s summarize…

i) We covered the binary files & it’s usage

ii) We executed curl command to download the fabric-samples for specific version

iii) We covered how to read the cryptoconfig.yaml file & set of parameters

iv) We covered how to read the configtx.yaml file & it’s parameters

v) We covered, how the blocks are getting created

So, if you are able to execute all the above instructions without any issues, you are doing great!.. Just wait, few miles to go, let’s meet in next series(will be available shortly).