在Hyperledger Fabric V1.0中，在同一个通道内的对等体之间实现通道间安全性

Question

I have successfully create a Hyperledger Fabric v1.0 network locally by following the steps Building Your First Network and communicating to this network from my java application using fabric-sdk-java .
Here it created the certificates using cryptogen tools and is able to invoke/query chaincode through each of the peers which participating in the same channel.

My implementations is like:
I have four organisations Org1, Org2, Org3 and Org4 each having one peer. When Org1 creating an asset A1 with quantity 100 using the chaincode C1, it has to share this asset among the peers like

Org2.peer0 A1: with quantity 40
Org3.peer0 A1: with quantity 30
Org4.peer0 A1: with quatity 20
And remaining 10 only will be available for Org1.peer0

All these peers joined in the same channel channel1 . My requirement is

If Org1 try to query the data for Org2 : error
If Org1 try to query its own data: return the Asset with the corresponding quantity.

Currently it is allowing to query all the data from all peers in the channel. In order to keep it hide the asset of one organisation from other, what is the best possible way?

Answer 1

I think that the source of your confusion due to the fact that you mixing the application logic with the business contracts logic which is usually implemented in chaincode.

Say you would like to establish Fabric network among 4 different parties and you need to define a rule which defines how you will split/distributed the asset among those participants. Now, let's put aside the peers. In your chaincode you encode notion of the asset and probably the notion of the users to avoid confusion let's call them persons. So you have 4 persons: Alice, Bob, Charlie and John and business rule which says that once Alice submit an asset it has to be distributed according to 40%, 30%, 20% and 10% respectively.

Next, to continue with say Alice works at Org1, Bob at Org2, Charlie at Org3 and John from Org4. Now you can implement a chaincode which will apply business rule based on whoever submits the transaction. Moreover you can implement ACL based on the submitter identity, hence to prevent from Bob query for balance of the let's say John.

The legitimate question will be why do I need 4 peers to implement such simple logic. As you can have only one peer with chaincode deployed, channel which configured for all 4 orgs and all you need is to send transactions proposal to invoke the chaincode.

The caveat in this approach is pretty obvious you need to decide which org will host and run this peer and the chaincode, therefore as all 4 orgs doesn't really trust each other they would like to host they own peer and invoke chaincode against theirs own peers. And in order to prevent each org to trick each other and reduce the influence of adversarial/non-deterministic behavior they will agree on endorsement policies which actually will make sure that peers of other orgs also receives same results as you during the simulation.

Now back to your question, peers are used to simulate transaction against current state and sign on the results, send results back to the client which aggregates endorsements based on policies and submits results to the ordering service which cuts blocks and deliver them to the peers, which will validate correctness of transactions in the block and eventually commit them to the ledger updating state.

Therefore your chaincode should encode notion of clients/users/persons among which you will distribute assets, those users could be mapped back to the client application (real world users), which might be enrolled into different organizations, hence having different certificates signed by appropriate org CA. Finally you will be able to leverage GetCreator API of the chaincode to understand which client invoked the chaincode and apply business logic and access control based on business logic you defined.

Sorry for making my answer too long, but to summarize. Your application/service will be based on two tiers: first one is the application tier - mapped to the user of org, second tier is the peer which holds the ledger and deployed chaincode - to simulate and execute transactions. Hence you will have 4 peers and 4 clients which will submit transaction to the peers and your logic will be based on the client identities rather on the peers.

Hope my explanation will make sense to you ;)