CODEWITHSUNDEEP
architecturehyperledger-fabrichyperledger
Pandit
Pandit

Reputation: 748

Hyperledger Fabric architecture explanation

We have the orderers, peers and users. But how they will work in a real case?

For example, if we have three companies A,B and C, who want their data be transferred in Hyperledger Fabric, how should the orderers, peers and users will distribute between companies?

Every company will have their own orderer? How many peers does each company require?

Do users, using SDK, initiate transaction proposal to peers? If yes, do they need to send the proposal to peers in another organization? Also how will domains work in this case?

Where are the certificates of each company stored? Is the centralized system and how network is distributed among various nodes.

Do we have just one crypto-config.yaml and configtx.yaml for all the peer and orderer nodes in the system and where to keep this file ?

I am looking for answers to these questions though they are all not my but I am looking for answers.

Upvotes: 2

Views: 755

Answers (2)

Braj
Braj

Reputation: 626

Quite big question to answer in one single post. Will answer the first one for now- For example, if we have three companies A,B and C, who want their data be transferred in Hyperledger Fabric, how should the orderers, peers and users will distribute between companies? Now A B C suppose are going to be part of single network and in one channel. Each of them will have a set of peers. One peer from each set will be anchor peer. Now anchor peers can be used to talk with each other and share data from their ledger. This is used to update each others ledger. If a user wants certain information they can run a chaincode query to get the same information.

Upvotes: 0

christo4ferris
christo4ferris

Reputation: 4037

Hyperledger Fabric (for v1.1) would typically be deployed with the orderer hosted by some trusted authority or member of the network. In subsequent releases, we will be enabling the orderer service to be fully decentralized, but for now, it would be a centralized service shared by the members of the network.

Each organization would typically run at least one peer node - two or more for resilience. Each org would also likely run at least one instance of the Membership Service Provider (e.g. fabric-ca) - again, a cluster of 2 or more for resilience.

Users initiate transaction proposals via one of the SDKs, and they would send proposals to as many nodes as required to satisfy the endorsement policy. e.g. if the endorsement policy required that a proposal be signed by at least two of your three orgs, then the proposal needs to be sent to a peer for org A and B, or org B and C or org A and C before it can be sent to the orderer for inclusion in a block.

The certificates for each company are made available via the MSP. The crypto-config.yaml can be for the whole network, or for an individual org. Cryptoconfig is provided as a utility, but certificates can be generated using the fabric-ca client as well.

The best way to learn about Fabric is to take the various tutorials in the documentation.

Upvotes: 4

Related Questions