Teach Yourself — Hyperledger in 24 hours — Hour 03:00 Components Deep Dive

Source: Google

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.

This article covers little deep on the following binary files & also few components (ORDERER,CA(CERTIFICATE AUTHORITY),PEERS & COUCHDB).

Let’s get started..

So when we set up “Build your first network(byfn)” from fabric-samples, we 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 we develop our own network, we 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 we 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 new joinee 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.

Cryptogen:

Cryptogen is an utility for generating Hyperledger Fabric key material. It is mainly meant to be used for testing environment. It has following sub-commands

cryptogen generate
cryptogen showtemplate
cryptogen version
cryptogen extend
cryptogen help
cryptogen

Now, let’s talk about Configtxgen .. again a real-time example of 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 the blockchain. Configtxgen actually does this job, it creates genesis block for the network.

Configtxgen:

The configtxgen command allows users to create and inspect channel config related artifacts. The content of the generated artifacts is dictated by the contents of configtx.yaml.

configtxgen -outputBlock genesis_block.pb -profile SampleSingleMSPSoloV1_1 -channelID orderer-system-channel

Configtxlator:

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

configtxlator: standard usage is expected to be:

1. SDK retrieves the latest config
2. configtxlator produces a human-readable version of a 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 :

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

Fabric-ca-client

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

Orderer:

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

Couch-DB — as a state database

State database options include LevelDB and CouchDB. LevelDB is the default key-value state database embedded in the peer process. CouchDB is an optional alternative external state database. Like the LevelDB key-value store, CouchDB can store any binary data that is modeled in chaincode (CouchDB attachment functionality is used internally for non-JSON binary data). But as a JSON document store, CouchDB additionally enables rich query against the chaincode data, when chaincode values (e.g. assets) are modeled as JSON data.

So most of the time, we end-up using Couch-DB as our state database, in order to perform complex query execution.

Finally, understanding these components are very important, these binary files will allow us to generate necessary tx, config, crypto files that are needed for blockchain network to function. So it is better to get deep insights before you move further.

Note: Like this article?, give Logeswaran a thumbs-up(Claps) & follow him on Linkedin / Twitter

Check this: Teach Yourself: Hyperledger in 24 hours