In my example, there are 3 participants orgs - Org1, Org2 and Org3
Endorsement policy states - Endorsement is required from all 3 orgs.
What if org3 is down due to unavoidable circumstances and assuming it will take a day for them to be booted back again. In the meantime, all the transactions won't go through because of endorsement policies.
Can we tackle this kind of scenario ? (say) modifying the endorsement policy or some kind of threshold mechanism ?
Modifying the endorsement policy in this case would not be possible by Fabric---for many valid reasons, including security and contractual concerns. You can either begin with a less stringent endorsement policy, or simply, have 2 or more peers per org and the set the end. policy to ANY peer from EACH org. That way, if one peer of an org is down, the other peer can keep the operation going.
Related
I am trying to develop a Dapp which would have only one channel between all the organisations. In a use case, there will be 1000 organisations, all connected to the same channel.
Now in the endorsement policy, all the endorsement peers in the organisations would need to give endorsement for the transaction. If my use case, if only 20 endorsers endorse the transaction it would be fine. There is no point to get endorsement from all the organisations.
Is it possible to make a endorsement policy which would randomly select these 20 endorsers and proceed with the transaction flow.
In addition to this, though only 20 organisations endorsed it, eventually all the committers and endorsers should get the block from orderer and commit it to thier blockchain.
I am aware of outOf(20, org1, org2,......org1000) can be used so that only 20 will be considered but such a long comand would become impractical and why to ping all the organisations if only 20 are required(considering some down time maybe 40-50 to be sure). Cant just the requirednumber of organisations be pinged randomly?
I think you might have already answered your own question.
An endorsement policy of OutOf(20, org1, org2, ..., org1000) would require endorsement from any 20 of the listed organisations. Once endorsements are obtained from peers of 20 organisations, no other organisations need to be contacted, and the endorsed transaction can be submitted to the orderer and distributed to all peers in the network. Note that only one peer from each of the 20 organisations needs to endorse.
Given a network with 1000 organisations (and provided there are sufficient orderers available), you should be able to have up to 980 organisations down or otherwise uncontactable, and still successfully submit transactions.
Sorry for the long question but Hyperledger is a fairly complex system.
Reading the Blockchain network In the section Generating and accepting transactions
In contrast to peer nodes, which always host a copy of the ledger, we
see that there are two different kinds of peer nodes; those which host
smart contracts and those which do not. In our network, every peer
hosts a copy of the smart contract, but in larger networks, there will
be many more peer nodes that do not host a copy of the smart contract
How to design the blockchain network and to decide how many peers should have smart contracts and how many should not?, Is there any design rules or patterns ?
When we have multiple organizations, should every organization has an endorsing peer, or they all can have only one within one organization and all other can call it ?
How to design the blockchain network and to decide how many peers
should have smart contracts and how many should not?, Is there any
design rules or patterns ?
My rule of thumb is - you first think about the endorsement policy, and then you install the chaincode on peers that belong to organizations that are in the endorsement policy.
Then, you can also optionally install the chaincode for query-only transactions (that don't get into the Blockchain) on peers of organizations regardless of their involvements in the endorsement policy or not, because it makes sense that a client would want to query its own organization (since it trusts it the most).
The only corner case is that sometimes the code of the chaincode is not known and the organizations of the endorsement policy, do not want to share it.
When we have multiple organizations, should every organization have an
endorsing peer, or they all can have only one within one organization
and all other can call it ?
It depends on the use case. Some organizations have clients only, and some organizations have peers only, or only orderers.
Whether an organization is an endorser for a chaincode, usually depends on the endorsement policy.
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.
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
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.