What is the importance of orderer genesis block in Hyperledger Fabric?

Question

In the build your first network documentation.
TwoOrgsOrdererGenesis: generates the genesis block for a Solo ordering service.
TwoOrgsChannel: generates the genesis block for our channel, mychannel.

The mychannel.tx is the genesis block in the channel and any peer who want to join the channel require this.

In the complete tutorial once the orderer genesis block is created it never used. And also Is there any other blockchain also present other than the channel ledger?

Does this orderer genesis block require for system channel?

Answer 1

In the build your first network documentation.

Let me start from pointing to official documentation here

TwoOrgsOrdererGenesis: generates the genesis block for a Solo ordering service. TwoOrgsChannel: generates the genesis block for our channel, mychannel.

Here is the source of the confusion, in fact TwoOrgsChannel profile generates configuration transaction which is submitted to the system channel and it includes configuration required for formation of the new channel. Such as channel policies and members of the channel consortium which by the way have to be a subset of the consortium defined within genesis block of the system channel.

The mychannel.tx is the genesis block in the channel and any peer who want to join the channel require this.

This is config transaction to be submitted to the ordering service such that it will create a new channel and return genesis block for new channel so peers could use it to join it.

In the complete tutorial once the orderer genesis block is created it never used. And also Is there any other blockchain also present other than the channel ledger?

It's always used to bootstrap your ordering service nodes for example after shutdowns or restarts.

Does this orderer genesis block require for system channel?

In fact, system channel bootstrapped using this genesis block. Now to complete on @Narendranath Reddy answer, genesis block contains consortium information which he called a network definition, basically it contains all certificates of organizations root CAs. Therefore allowing to initialize channels MSPs and use those root CAs certificates to validate ACLs, endorsements and clients signatures.

Answer 2

Most importantly, the ordering system channel contains the crypto material that defines an organizations in a consortium: the root certificates and the admin certificates. They allow organizations to join new channels without supplying new crypto material each time.

Answer 3

Good Questions thanks @Shubham Chadokar

Channel.tx is needed which contain channel policy information

while joining we will need the latest block which contains network configuration which is needed in order to join peers to channel.

SEE below detailed information

Statement1:

The mychannel.tx is the genesis block in the channel and any peer who want to join the channel require this.

Answer

Note: mychannel.tx is not the genesis block

I would like to highlight the difference between genesis.block mychannel.tx

• genesis.block is a configuration of an HLF network (contains network definition)

• mychannel.tx >>> initial binary configuration definition (contains sign-able channel definition)

ordering system channel: orderers maintain the long list of all organizations that are allowed to create channels. This list of organizations is known as the “consortium”, and the list itself is kept in the configuration of the “orderer system channel”.

Now the interesting part what is present inside mychannel.tx

• mychannel.tx is a binary file
• One can decode this file using protolator Commands:

Step1: GOTO fabricsamples/bin ./configtxlator start

Step2: GOTO mychannel.tx file location then issue below command

curl -X POST --data-binary @mychannel.tx http://127.0.0.1:7059/protolator/decode/common.Envelope > mychannel.json

The results of decoding the file mychannel.tx which is a common.Envelope produced by the configtxgen tool contains a common.ConfigUpdate object. This object has the name "config_update" within the "payload.data" JSON object.

This is the object that is needed as the source of the template to be used for creating new channels. The common.ConfigUpdate is the object that will be signed by all organizations and submitted to the orderer to create a new channel.

mychannel.tx contains read/write set of mychannel

Result:

{ "channel_id": "mychannel", "read_set": { "groups": { "Application": { "groups": { "Org1MSP": {} } } }, "values": { "Consortium": { "value": { "name": "SampleConsortium" } } } }, "write_set": { "groups": { "Application": { "groups": { "Org1MSP": {} }, "mod_policy": "Admins", "policies": { "Admins": { "policy": { "type": 3, "value": { "rule": "MAJORITY", "sub_policy": "Admins" } } }, "Readers": { "policy": { "type": 3, "value": { "sub_policy": "Readers" } } }, "Writers": { "policy": { "type": 3, "value": { "sub_policy": "Writers" } } } }, "version": "1" } }, "values": { "Consortium": { "value": { "name": "SampleConsortium" } } } } }

---

I have done the same for the genesis.block check this http://ideone.com/L1hcRX which contain genesis.block as json format which contain all network information.

---

Statement 2: the complete tutorial once the orderer genesis block is created it never used. And also Is there any other blockchain also present other than the channel ledger?

Answer

I hope now you have got sufficient information. genesis block main purpose is network configuration, once network is up and running we will not use again except you onboard new organization which contain orderer you can use old genesis.block later it will fetch latest configuration from other orderers.

---

Does this orderer genesis block require for system channel?

---

YES

Answer 4

Orderer genesis block is the genesis block for the system channel as it is the basic configuration block for the network. It a special channel managed by the orderer admins which includes a list of the organizations permitted to create channels.

The genesis block of the orderer system channel is special: it must be created and included in the configuration of the node before the node can be started.