Peer is a special kind of node responsible for endorsement, verification, and adding a new block into the ledger. Each peer can connect to one or more channels, and these channels are completely disjoint from each other. It means one channel’s information will not mix with another channel and has its own ledger and blockchain, and these are all kept separate.
A peer is associated with three channels in the below diagram, and each channel has a separate ledger and world state. This peer has two chain codes, and these chaincode runs as processes. However, it is safe to run inside Docker containers for security reasons or to contain the vulnerabilities associated with chaincode, if any.
It may be possible that all the channels require both chaincode A and B or only a specific chaincode. This chaincode will be initiated separately in both cases, and initialization output data will be stored as a transaction inside the ledger separately for each channel. However, for a single chaincode, a single process will run inside a docker container and serve all the channels as it does not keep state information or is a stateless process. So this way, we don’t need to run multiple processes for a single chaincode if it is associated with multiple channels.
- Chaincode runs inside a Docker container as a stateless process.
- Multiple channels initiated chaincode instances but used the same chaincode process runs inside the container.
- State information is stored inside the ledger of individual channels.
There is a communication between the peer and chaincode, and peer and ledger, and all these happens using google remote procedure call (GRPC). These components, such as peer, chaincode, and ledger, are pluggable and written in golang. However, it can be rewritten in any other language if it supports GRPC.
Individual peer has the identity (PKI), and the identity is managed by the local membership services provider (MSP) on the network. The individual peers use their identities when communicating with peers or with the ordering service or client application. The events submitted by the peer are signed by the certificate that the peer has.
References
- NPTEL lecture series on Blockchains Architecture, Design and Use Cases by Prof. Sandip Chakraborty, IIT Kharagpur.
166 total views, 1 views today
