The same set of peer nodes such as endorsers and committers can be part of multiple blockchain ledgers, and this is achieved using the channels. The channels provide transaction privacy among the different ledgers. Multiple parallel blockchain services can be executed and managed for better utilization of hardware resources and scalability of the entire network through the channels.
This can easily relate and understand from the TCP/IP stack. Multiple applications share the same network stack. However, each application maintains sessions based on the port numbers. So the communication channels are created and segregated based on the port at the transport layer.
We can run the multiple blockchain services using the same set of peer nodes or selected peer nodes set for a blockchain service and another set of peer nodes for another blockchain service. So, the Hyperledger fabric platform provides flexibility to host multiple blockchain services using different mix and matches of peer nodes.
It means the same set of peer nodes can part of multiple blockchain ledgers. In the above example: E0, & E1 are part of one blockchain service whereas, E0 is also a part of another blockchain service. These blockchain services may have the same or different ordering services, but each service maintains a different ledger.
The ledgers exist in the scope of a channel. These channels can be shared across an entire network of peers or can be permissioned for a specific set of participants such that a subset of peers can form a channel among themselves to execute private transactions.
- Chaincode is installed on peers that provide access to the world state, and these are instantiated on specific channels.
- Peers can participate in multiple channels, and the state maintained by the chaincode is part of the ledger and separate for each channel. It means the chaincode state of one channel is different compare to another channel. So these are kept private and separate.
- When the same peers can be part of multiple channels, the concurrent execution provides higher performance and scalability and better utilization of hardware resources.
Single Channel Network
All the peers are part of the same system channel in the single-channel network, having the same chaincode and maintaining the same shared distributed ledger.
In this setup, the client is connected to the endorsing peer E0, and E0, E1, E2 & E3 are the endorsing peers in the network, and there is an ordering service and exactly one channel in the network. All the peers connect to the same system channel and maintain a sequence of blocks of transactions, i.e., shared ledger. There are chain codes deployed at each peer in the network and instantiated on a particular channel.
When a transaction, consisting of function calls of the chaincode or smart contract with input parameters, is submitted by the client application to the network. Then all peers execute the same function across the network, and the client receives endorsements from all the peers asynchronously. The client submits a transaction to the ordering service, and the service achieves consensus and then final validation by peer nodes across the network. So this is an example of a single-channel network.
Multi-Channel Network
Multiple parallel blockchain services can be executed in the multi-channel network to access the entire network, and the services will be completely disjoint.
There are two different applications in this setup: one application is transacting on the red channel, and another is on the blue channel. These applications may not even know the existence of the other channel. There are two sets of peers that are part of two different channels. However, having a common ordering service is quite possible to set up a completely separate ordering service across the channels. If a common ordering service is used, then the ordering for the two channels is kept separate along with a separate or the same endorsement policy depends on the requirements. The ordering service configuration is stored in the genesis block of each ledger of the channel.
References
- NPTEL lecture series on Blockchains Architecture, Design and Use Cases by Prof. Sandip Chakraborty, IIT Kharagpur.
438 total views, 1 views today
