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."
Related
In hyperledgerfabric 's transaction flow ,will the orderer send blocks to the peers in network?
yes , orderer recieves the endorsed transaction from the client , make it as a ordered block and sends that block to the peers (committing peers) in the organisation
The picture below shows ordering service sending endorsed transactions to the committing peers.
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 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
According to hyperledger fabric documentation, the chaincode should only be deployed in endorsing peers, and it says still the non endorsing peers can validate and update the ledger. Now I am bit confused if non endorsing peers don't have a chaincode, how can they generate R/W sets. How the non endorsing peers will be able to create new state for the asset, if they aren't aware of the logic (chaincode) behind it ?
If you look at https://hyperledger-fabric.readthedocs.io/en/release-1.1/txflow.html#, you'll find a section that states:
The blocks of transactions are “delivered” to all peers on the channel. The transactions within the block are validated to ensure endorsement policy is fulfilled and to ensure that there have been no changes to ledger state for read set variables since the read set was generated by the transaction execution. Transactions in the block are tagged as being valid or invalid.
A block is an ordered set of transactions and transactions include the state transitions in the form of read/write sets. The output of endorsement is actually the read/write set and these are what are ordered and delivered to all peers in the channel.
In order to validate a transaction, a peer needs to check the following:
Is the transaction well-formed
Was the endorsement policy met (the
endorsement policy is distributed to all peers in a channel when
chaincode is instantiated even if the peer does not have the
chaincode bytes)
MVCC check
In order to do the above, peers do not need to execute the chaincode itself.
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.