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
Related
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.
Must the chaincode creator be trusted by whole network? From my understanding chaincodes are installed and instantiated by some authorized user. And if my understanding is correct they are distributed in binary form.
Let's assume that we have OrgA and OrgB each of them having one peer and endorsing policy requires both of them to sign the transaction proposal.
Peer.OrgA
Peer.OrgB
Let's assume that OrgA is instantiating chaincode in the channel. Is there any way for OrgB to validate its logic?
I understand that due to endorsement process and read-write sets we are protected on blockchain level against double spending.
But what about business level? What if chaincode is doing some tricky manipulations?
For chaincode instantiation and installation you can stablish policies on who can do it. Also for a chaincode to be instantiated it is needed to create packages that in order to be instantiated and installed need to be signed by all the participants of the network, or whatever policy that you have. You can read more about it here.
https://hyperledger-fabric.readthedocs.io/en/release-1.4/chaincode4noah.html
This packages can be reviewed by the organizations.
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.
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.
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.