I am trying to understand the transaction flow in a multi-org setup in a Fabric network. I was going through the official document.
Basically, it explains that a client creates a transaction proposal and sends it to the endorsing peers. And endorsing peers validate, simulate and endorse this transaction. During the validation phase, the endorsing peer validates the signature of the client using the MSP.
So, in the case of a single org, I understand that there will be a single MSP through which all the endorsing peers validates the signature. Also, in this case, the identity of the client is issued from the same MSP.
However, in a multi-org setup, each org maintains its own MSP. Say, we have Org1 that has endorser peers (EP1, EP2) and MSP1. In Org2, we have endorser peers(EP3, EP4) and MSP2. The endorsing policy is such that all the EPs should endorse the transaction.
In this case, the identity of the client is issued from MSP1 of Org1. So when this client submits the transaction proposal to all the endorsing peers, how will the EP3 and EP4 validate the signature of this client with their MSP2?
How these MSPs of different orgs communicate with each other for signature validations?
Information about the Consortium and the MSP identities are encoded in the genesis.block (file used to bootstrap the orderer) of the blockchain.
When a peer joins a channel, the request is first made to the orderer to get the information about the genesis block. With the help of this genesis block, the peer gets to know about the consortium, channel and the participants (and its MSPs)
Check this reference: https://github.com/hyperledger/fabric-samples/blob/release-1.2/balance-transfer/app/join-channel.js#L48
Related
I have a Hyperledger-Fabric network with two organisations: Org1 and Org2. Discovery is enabled.
When I run a Gateway client and submit a transaction, it always be endorsed by peer0.peer.org1.com.
In particular scenario, I may want to select particular peer to endorse the transaction.
Noticed that there is a function in Go SDK, called channel.WithTargetEndpoints(), I thought that i could use this function to append RequestOption. When I used any target peers from org1, the transaction could be processed successfully, however, when I tried to specify peers from org2, it didnt work.
Guess my user certificate was signed by org1. NetworkPeerConfig can fetch the peer configuration based on a key (name or URL). However, user within org1 cannot fetch the peer configuration for org2's peers.
How to select endorsing peers when submitting transaction in GO SDK?
If you're using the gateway package to submit the transaction, then you should use WithEndorsingPeers as the optional argument.
Below is my understanding of a Hyperledger Fabric system. Do let me know if any of it is incorrect.
1) So we have peers (endorser, anchor, general (who has the ledger), orderer). Also when we setup the fabric, let's say we registered two organizations. let's call them Company A and Company B. Now what I should do is use cryptogen to generate their certificates which go to specific folder.(in crypto folder, what I'll have at this stage is keystore and signcerts for Company A and Company B).
Now for these companies, A and B, I also make the peers for them. Let's say I give peer0 (anchor) to Company A and peer1 (anchor) to Company B and also
I give peer2 (general) to Company A and peer3 (general) to Company B and also I give peer4 (endorser) to Company A and peer5 (endorser) to Company B. As my understanding each organization must have at least 1 endorser peer (who receives requests from client), at least 1 general peer (who has the ledger) and at least 1 anchor peer who gets blocks from orderer to give it to general peers in the same organization.
So this is the setup. Let's say I give these peers to company A and B and I also setup orderer peer (let's leave it as SOLO). before I run the network, I also need to have genesis block and channel. Let's create global channel and call it EveryoneChannel and put all peers in it.
I will go on. Now when I want to have chaincode, which node should have this written chaincode? My understanding is that chaincode must be owned by endorser, because as I read it's the one who executes chaincode to simulate proposal to return it to user. So endorsers have chaincodes? General peers have ledgers. anchors get blocks and give it to general peers in the same organization. I know what orderer does.
Who are the clients? I have read many times that clients make transaction requests to network. So my guess is in each organization, for example Company A, Company A can register employees that will be binded to Company A's Organization. Let's say Company A has registered three employees, employee1, employee2,employee3. so what will happen is 3 certificates will be created for these employees and they will also be saved in crypto folder.
Now what can happen is employe1 can make a transaction request to the endorser peer that is in the same organization as is employee1. employee1 already has the certificate as I mentioned so request and response and transaction will be valid. Company A's endorser will take care of it.
Now I also have read about endorsement policy. so it means transaction will be valid if it will be validated by n-th times of number peers from organizations and it's said that this endorsement policy is written
in chaincode. if we have Company A and Company B, and their endorsers have chaincodes, should I put endorsement policy in both of them? I guess when client makes transaction request, he can only make this request to his only organization, not other organizations. so Company A's endorser will have this chaincode and endorsement policy. so what will happen? Company'As endorser also throws this request to Company B's endorser and waits its response and returns two responses to client?
First, I would refer you to the answer for this question. It explains the different peer types, as well as linking to the relevant Hyperledger Fabric documentation. The documentation explains everything much better than I could, with some nice diagrams :)
You have the right general idea about how the network is configured and operates, but to pick up on a couple of points in your question:
Anchor peers do not have any special responsibility for distributing blocks, they merely act as initial connection endpoints to allow other organizations to discover all other peers in the network. See here for more details on how this works.
The endorsement policy is defined when the chaincode is instantiated. If an endorsement policy requires endorsement from multiple organisations, the client initiating the transaction must send the transaction proposal to an endorsing peer for each organisation required by the endorsement policy. Once all necessary peers have returned a properly signed transaction response, these are then sent to the orderer for packaging into a block, and transmission to all peers. On receipt of a block from the orderer, each peer then performs it's own validation against the endorsement policy, before committing the block to its copy of the ledger.
I have simple question about Hyperledger Fabric. so here is my question:
I know that for committing peers (ordinary peers) it's not 100% necessary to have chaincode installed, but every peer should have ledger and that's 100% necessary.
so suppose I am committing peer and I have not chaincode installed, but I have ledger of course. Now new block arrives from ordering peer.
1) I should check blocks validity, so I need to query ledger
2) I should add this block, so I need to update ledger.
So how can I do this two above without chaincode? Isn't chaincode necessary for above operations? (query and update)
To check the transaction/block's validity, the peer does not need to have the chaincode, the readwrite set available in the transaction is compared against the ledger (available in all peer) to decide the validity.
And adding the block to the ledger is not dependent upon the validity check. If it was found invalid, it will still be added to the ledger but with an invalid tag.
You cannot query a peer without having a chaincode. Must need chaincode installed in the peer in order to query | invoke.
Hyperledger Fabric has two types of peers
1) Endorsing peers
2) Committing Peers
Endorsing peers must need a chaincode which means you need to install chaincode on endorsing peers because its duty is to make sure the transaction owner has sufficient rights and it simulates that transaction against the ledger for that it needs a chaincode interface in order to complete simulation.
Once the simulation is done it sends back the R/W sets and simulation result to client and client will send this to the orderer
Orderer then distributes to committing peers ( No need to install chaincode)
Whole: Applications generate a transaction proposal which they send to each of the required set of peers for endorsement. Each of these endorsing peers then independently executes a chaincode using the transaction proposal to generate a transaction proposal response. It does not apply this update to the ledger, but rather simply signs it and returns it to the application.
I am quit confused with these two peers since I am new to Fabric. If any body help me with this.
Endorsing peers are basically approvers.
A transaction has to be proposed and then endorsed before it can be submitted successfully to the blockchain.
Endorsing peer is the peer that will "endorse"/provide the seal of approval to a transaction when it is proposed. After the transaction is endorsed, the transaction(plus the endorsement) will be submitted to blockchain.
Once the Transaction is submitted, it will make way to the peers that are supposed to get that transaction. These peers will then "commit"/save the transaction in their Ledger, and these are the committer peers.
The committing peers and endorsing peers can be the same peers sometimes.
To understand the difference among those Peers, I thinks that it is important to know where takes part its Peer in the flow of a transaction of Hyperledger Fabric.
A proposal is send to the Endorser Peers. These Peers verify the proposal, execute it and send the reply signed to the client.
The client inspect those replies. If they result is succesfull, it generates a new transaction with the replies of the Endorser Peers and sends it to the Ordering Service.
The Ordering Service executes its operations and sends the block to the corresponding Peers, i.e. the Commiters.
The Commiters append each block to the corresponding ledger.
As #adnan.c said:
"The committing peers and endorsing peers can be the same peers
sometimes."
I am curious how does Fabric choose among one of selected Organizations in an "OR"-type Endorsement Policy. Is it a random choice or does it follow a predetermined logic?
For instance, let's say that I have a following policy :
OR('Org1.member', 'Org2.member', 'Org3.member')
Now, let's say that the Endorsing Peer which is supposed to process an incoming transaction proposal belongs to Org1.
Because of uncertainty about network connectivity and availability of other organizations, Org1 would be a preferred entity elected for endorsement (because it happens locally on that very same peer).
However, is this the case in Hyperledger Fabric?
Any help understanding the above will be greatly appreciated.
Fabric clients should be aware of the endorsement policies and it's up to them to decide on endorsing peers. So in your example with:
OR('Org1.member', 'Org2.member', 'Org3.member')
client should know that in order to get valid transaction it has to be endorsed by either someone from org1 or org2 or org3. So client could send transaction proposal to some peer into org1 and wait until get response. An alternative strategy would be to send transaction proposal to 3 peers one from each organization.
Once client collects enough endorsement it will submit transaction to the ordering service and prior to commit peer will ensure that endorsement policy being satisfied. Now please note that endorsement policy doesn't specifies exact endorsement peers, but just saying that it has to be someone from that org with certificate approved by org root CA.
So right now client has to know endorsement policies and being aware of the membership to being able sent transaction proposals, however there work in progress FAB-5451, to provide service discovery based capabilities so client will be able to dynamically learn policies and will be able to query for set of endorsing peers.
wouldn't it be better to step back from talking directly to peers and orderers? use channel instead. always speaking only to specific elements is SO fragile.