In this note, we will understand how to systematically set up our own hyperledger fabric network at the component level rather than actually configuring the network. We will understand some of the things and steps to take up for the setup of the entire system.
Each organization set up a membership service provider (MSP) and associated certificate authority (CA) at the initial step. Then, creates administrator accounts, and these accounts will be associated with different entities, such as ordering nodes, peer nodes, etc., to manage each individual.
Step 1/6: Configure & Start Ordering Service
The first step is to set up an ordering service; this is the main component determining how transactions are ordered in the network. There could be a single solo ordering node hosted by an organization or a distributed set of nodes hosted by the different participating organizations. It may run any pluggable consensus algorithms, such as Kafka or Raft or PBFT, or any other, based on the requirements or availabilities.
Step 2/6: Configure and Start Peer Nodes
Once the ordering service is up, the next step is to configure and start peer nodes. Mostly, we have multiple organizations that are part of the blockchain network. Each of these organizations could run one or more peers. Each organization must have MSP and fabric CA or external CA to manage the identities of peers.
A peer can be configured as an endorser or committer in the network. However, both the peers have different roles but can also be set up in the same system and run as different services. These are done using the CLI commands once the required software is installed properly.
Step 3/6: Install Chaincode
Once the peer nodes are up within an organization or across the organizations by the system administrators, the next important task is to set up or install one or more chaincode on these endorsing peers.
The chaincode contains the business logic, and mostly these are runs independently inside the docker containers for many reasons. However, one of the reasons is that to contain the vulnerabilities, if any. Further, the chaincode only installs on the endorsing peers, which gives privacy that only a subset of peer nodes across the organizations have the business logic. Also, this can be easily managed rather than having the chaincode installed on all the peers.
These nodes are not connected until now, so the next step is to set up channels among the entities across the blockchain network.
Step 4-5/6: Create & join Channels
The ordering service is where these channels are configured. There could be individual ordering services for each channel or have the same ordering service for all the different channels. It totally depends on the requirements and purposes. We have considered only a single distributed ordering service across the network that serves multiple channels in our example.
After configuring these channels with the ordering service, the next task is to join the set of peers with the channels across the organizations. For example,
- E0 and E1 are part of the red channel.
- E0, E1, E2, and P3 are part of the blue channel.
- E2 and P3 are part of the yellow channel.
The subset of nodes joins different channels, and the channel provides a notion of privacy across the different transactions and the different states maintained in the network. So the same peer can be part of multiple channels. The uses applications get the identity from the fabric CA or external CA and join the channels.
Step 6/6: Instantiate Chaincode in Channel
The next step is to instantiate the chaincode with endorsement policy on the channel and map the chaincode to the channel. Each channel has there own ledger, and whenever the ordering service generates a new block, it goes to the appropriate ledger of the channel in the blockchain network.
What we have seen that there is a lot of flexibilities to configure the system. It starts with the configuration of the channel and then which peers or which organization will be part of that channel. Then define which chaincode will be the part of which channel and all these are segregated separately. Each chaincode state is separate from another in each channel, and all the chaincode states across the peers in a channel are consistent. All the states will be maintained consistently using the pluggable consensus algorithms. More of the entities are pluggable, which gives the flexibility to easy to customize and manage.
Endorsement Policies
An endorsement policy describes the conditions by which a transaction can be endorsed. A transaction can only be considered valid if it has been endorsed according to its policy.
We have seen that the endorsement policy governs a subset of peers executing the chaincode on each channel. The endorsement policy states which peers have to execute and endorse a transaction before being considered valid and added to the blockchain.
Each chaincode defines an endorsement policy, and this can be different for each channel that the chaincode belongs to. A few important system chain codes are implemented internally to the fabric itself and perform certain important functionalities. These are pluggable, which gives the flexibility to easy to manage. In this note, we discussed only two important chain codes, and these are as follows:
- Endorsement System ChainCode (ESCC)
- Validation System ChainCode (VSCC)
This chaincode runs within every endorsing peer. So, when a client submits a transaction to the endorsing peer. It is the ESCC that receives and validates the signature of the user. Then, the actual transaction invokes a particular function from the business logic chaincode. The output of the execution of the transaction, read-write set, will be captured by the ESCC, and it will sign the proposal response.
The client receives all the endorsements from different peers, consolidates the response, signs, and submits it to the ordering service. The orderer will include it in the block, signs it, and delivers it to peers.
All the committing peers validate endorsement operations with the help of VSCC. The VSCC looks up the policy for a particular chaincode, and if it satisfies, then commit it to the ledger.
References
- NPTEL lecture series on Blockchains Architecture, Design and Use Cases by Prof. Sandip Chakraborty, IIT Kharagpur.
244 total views, 1 views today
