what is Application's own signature in this context, and how can someone using hyperledger fabric node SDK can set the application's signature?
the application that you are talking about is simply a client app which talks to the ledger. The issue here is not the client app, the issue here is that you need a proper endorsement policy which establishes how anything goes onto the ledger.
Imagine this scenario ...
you have 2 orgs, Org1 and Org2, both owning one peer, P1 belongs to Org1, P2 belongs to Org2 and both peers joined on a channel, let's call it defaultchannel.
you deploy and instantiate your chaincode and set a basic endorsement policy which is 1-Of.
Each org has a client application, running against their own peer. When Org1 submits a transaction to the ledger, its validity is endorsed by itself, but not by the second org, because your policy requires only one to accomplish this. Basically in any network where you have more than one org, you really want a proper endorsement policy. 2-Of would work in the case of our example as any transaction would need to be validated by both orgs and that gives the ledger much better integrity.
Bottom line, your fabric network needs to be properly built and protected, especially in a production environment and this allows it to be protected by any client apps which have rights to interact with it. Your network being protected means that it doesn't matter how a client app is built and what it tries to do, it won't be able to bypass mechanisms such as the endorsement mechanisms.
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.
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.
I am new to the area of DLTs or "blockchain" and I am trying to create an application on top of Hyperledger Fabric. Before I describe my use case, I need to mention that due to my use case's nature I need a private & permissioned "blockchain" which justifies the choice of Fabric (I am aware of other platforms e.g. Corda, private Ethereum, but Fabric seems to match my use case better).
Use Case
My use case consists of two different types of participants. A number of organizations (which upload and share information about individuals on the distributed ledger) and a client who can query information about an individual.
The client should not be able to see the transactions uploaded by the organizations and will not have write rights on the DL. He has read-only rights. Moreover, the organizations trust each other and there is also a level of trust between them and the client.
Design thoughts
Based on what I've read, I was thinking of creating a DL network that includes all of these parties and use channels which, based on the documentation, can be used to create a grouping among a number of participants (the organizations in my case) thus "hiding" the transactions from the parties which are not included in this group (the client in my case).
However, later I read about chaincode (a.k.a. smart contracts) which:
can be invoked by an application external to the blockchain when that
application needs to interact with the ledger
which confused me since if the "blockchain" can be queried from an external entity, that probably means that the client should not be included in the trusted network.
Am I headed in the wrong direction (design-wise)?
Based on your description, Hyperledger Fabric channels sound like a good solution. You should also familiarise yourself with private data collections, as this is another way of hiding some of the data from some peers. Which option is best for your scenario will depend on how your datasets are structured, and whether you also need to keep the data private from the orderer.
Clients are not part of the network. They query the blockchain by connecting to a peer and then requesting data from that peer. They can then only access the data visible to that peer (which is stored locally by that peer). So, it is not possible for a client to access more data than is available to the peer the client is connected to.
In your example, you would have a "client" organisation, with at least one peer. This peer would be part of the network, and your client application would then connect to it for access to data on the ledger (typically using the Hyperledger Fabric Node SDK).
There are two types of chaincode in Hyperledger Fabric.
User Chaincode (often just referred to as "chaincode") is used to update the ledger for a channel, and is only installed on those peers which require it (i.e. endorsing peers). Since your "client" peer would not be an endorsing peer, it would not have access to the user chaincode for the channel.
System Chaincode which all peers have access to, provides (among other things) an interface to allow queries to be run against the ledger.
Following is given as part of hyperldedger fabric documentation for v1.1:
Switching between organizations to sign a config transaction (or to do anything else) is not reflective of a real-world Fabric operation. A single container would never be mounted with an entire network’s crypto material. Rather, the config update would need to be securely passed out-of-band to an Org2 Admin for inspection and approval.
Say we have 4 organizations Org1,Org2,Org3 and Org4 and we are in the process of creating Org5.
Let Org1 and Org2 belong to same cli whereas Org3 be in Org3cli and Org4 be in Org4cli
Let us say all initial steps to launch org5 into network has been done.
On coming to peer channel signconfigtx I first sign from cli using peers of Org1 and Org2.But I need one more signature as majority says 3.
I go to Org3cli as sign on behalf of org3 but since peer channel signconfigtx method is local cli (Containing Org1 and Org2) doesn't come to know about it.(result is not send to the orderer).
So given in a real world scenario that a single cli isn't expected to handle all configuration,How do u handle interaction between 2 different cli ?
As you have correctly interpreted, the documentation is telling you that setting up a multi-org network using a single control point which has access to the crypto material for multiple organizations is not reflective of how things work in the real world. We do this in the samples to make it easy to bootstrap a multi-org sandbox network.
In the real world, you would need to pass the serialized configuration (update) transaction out of band to all of the organizations who need to sign it based on the channel policy. Fabric currently does not provide any tools for handling the out of band communication ... this is left up to the members of the network to decide.
There are vendors out there that are providing governance and lifecycle management tools for Fabric as part of their offerings, but there are currently no Fabric-specific tools available in open source for this.
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.