What if one peer is down - hyperledger-fabric

Let's say we have a 6 peer in Hyperledger Fabric network and 3 organization. Each organization has 2 peers. All 6 peers belongs to one single channel.
What if one of the peer is down? Is the network still validate transaction and creates block?

This depends on the way your chaincode is set up. On a channel you have chaincode deployed, this chaincode has a specific version number. When you instantiate the chaincode or when you upgrade it, you can specify which endorsement policy to use.
This endorsement policy dictates what rules a transaction must satisfy in order to be validated. To be more specific, it specifies the organisations who must endorse it, via their endorsing peers, of course.
You can read more about it here: https://hyperledger-fabric.readthedocs.io/en/release-1.3/endorsement-policies.html
If one of your orgs has 2 endorsing peers and the endorsement policy requires one peer, then if one goes down, you're still fine.

Related

How does Hyperledger Fabric perform endorsement, and who are clients in Hyperledger Fabric

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.

Can I query Hyperledger Fabric ledger or update ledger without chaincode in peer?

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.

Chaincode should only be installed on endorsing peer nodes?

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.

Endorsement - when only 1 org and multiple peers

I am using composer (running on fabric network) with one org and two peers. I would like to know how endorsement works in this scenario?
I understood from docs and rocket chat, that endorsement policy cannot be defined my case since there is only one org. Therefore, if peers in this org produce different results then how will endorsement works? will there be error?
Chaincode is installed on all the peers in this org. Do they automatically become endorsing peers?
Please explain :)
see the first explanation of a similar endorsement policy (ie peers in the same Org) -> Endorsement policy doesn't work
On 2nd question - ordinarily if you install chaincode on them they would be - but depends on how you set up your network see http://hyperledger-fabric.readthedocs.io/en/release-1.1/peers/peers.html http://hyperledger-fabric.readthedocs.io/en/release-1.1/chaincode4noah.html and http://hyperledger-fabric.readthedocs.io/en/release-1.1/arch-deep-dive.html

Deterministic choices of endorsing peers

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.

Resources