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.
Related
In Hyperledger ledger, how could I list endorsing peers of a specific chaincode?
I have a channel with 5 peers but I need that only three of them endorse a transaction while the other two need only to access to same ledger.
You can use the discovery service to get the endorsing peer. Here you can find some information:
https://hyperledger-fabric.readthedocs.io/en/latest/discovery-overview.html
Hyperledger fabric has a CLI tool to query the discovery service:
https://hyperledger-fabric.readthedocs.io/en/latest/discovery-cli.html
For node.js applications, you can follow the tutorial here:
https://hyperledger.github.io/fabric-sdk-node/release-1.4/tutorial-discovery.html
With the latest Fabric Client SDKs (personally using GO client), you don't need to deal with endorsement policies. Client SDK already does this dirty work for you. It extracts:
Which organizations' endorsements are required for this chaincode, key (key level endorsement policy can be defined as well), etc.
Which peers currently exist in the system and what are their MSPs (from discovery service).
According to these information, client SDK builds a set of necessary peers then sends your transaction request to all. It waits response from requested endorsers. Once it collects all responses, it sends to orderer and so on.
If you have a special case which you need to manually set endorsing peers of your choice (I had one use case about private collections so I had to use this approach) check out discovery service API of your client SDK.
I want to check from my Node SDK if peers and orderers are active before send transactions to them.
Essentially I want to implement a sort of Healthcheck for my server.
If a peer is down, I don't even want to make a transaction proposal and contact other peers.
I could create on the chaincode an healthcheck endpoint but I don't want to invoke the chaincode.
I would just want to connect to the peer and check if the connection succeed.
If succeed, it means the peer is alive, otherwise not.
How to do this from fabric SDK?
Of course I would do this for peer but would be helpful for orderers too.
For peers and orderers, you can poll the nodes via the operations /healthz REST endpoint.
If a peer is down, I don't even want to make a transaction proposal
and contact other peers.
Keep in mind that if you use service discovery then you only need to monitor your peers used for discovery, and you can ask these peers for endorsers and they will not send back endpoints of peers that are offline.
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 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 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.