I have a web app with multiple clients.
I want to record some data of client (employee education record) on blockchain.
Clients do not wish to share this data with any other entity or organisation. No data will be shared between clients themselves. The sole purpose to use blockchain is: to have a immutable copy of records.
I have two options:
Multiple Orgs Single Channel:
1 Org per client and 1 Org for my application.
All Orgs on single channel.
I write my business network in composer in such a way that 1 client cannot READ, WRITE, DELETE the data of other client. (via ACL definition).
So, although the ledger is same for all clients, there are rules defined to prevent invalid access.
Multiple Orgs Multiple Channel:
1 Org per client and 1 Org for my application.
Different channels for each client. (Client + My App Org join the channel).
This way ledger will be different for each client.
Con: I need to instantiate the same composer network(bna) on all channels (management task increases).
Which approach is good for my scenario?
If there is no common data between different clients/orgs, there is no point of having a shared channel between them. Taking care of permissions overs data will complicate your network setup. It would be better to abstract out that detail from network design.
You should have one org corresponding to each client. In each org there will be a single channel which all the peers in that org will use to communicate.
I think you could encrypt every client's data by passing the transient key to chaincode,and just manage the keys, this may be light weight and fesible for your scenery.
Related
Is it possible to have application level data privacy in Hyperlegder Fabric v2.2
We have the first network (as referenced in the fabric-samples) in place (Org1 and Org2 with peer0 and peer1 each). I am aware that data privacy can be ensured between 2 organizations using Private Data Collections. Looking at the case where peers in the network can run multiple user applications, consider that, there is app1 and app2 connected to the network via peer0 belonging to Org1. The cause for concern is that despite using private data collections, app1 could access the private data logged by app2 in Org1 private data collection. Is there a way in hyperledger fabric to ensure privacy between apps connected to the network via the same peer.
No, there is not.
You can develop your own authorization routines at smart contract level so that read related operations only return data to authorized users. This way you prevent other clients from accessing data through read operations, but the data is not protected from the peers themselves.
You can also encrypt your data in your client before sending it in a transaction. You can use your own Fabric certificate to encrypt data via ECIES or ECDH encryption schemas (or use any other encryption schema you want). But this way the contract is not going to be able to interpret your data. It will be only able to store it and return it...
In other cases, you may be interested in storing your data in your own private storage system outside Fabric and save only a hash of the data in the channel state as a proof that can be used later if necessary for whatever it is intended to.
These are things you can do to preserve privacy at user level. You can think of other solutions. But Fabric does not provide specific ways to do it. From a blockchain point of view, it is difficult to preserve data privacy at user-level while peers try to reach consensus over that data.
I have isolated two organizations into two different channels. Organizations one and two are part of channel1, and organizations three and four are part of channel two. I would like to ask if it is possible that one peer on channel2 access queries the ledger of channel1 and vice-versa. If it is possible how can I do it?
I very much appreciate your help.
It is not possible in your current setup because the peers who have joined the channel can only access that channel. Peers that are not part of the channel can not access the ledger data.
What you can do is, bring the peers on the common channel and can use PDC (Private Data Collection) to make the transaction private to the organization/Organizations.
Hyperledger Fabric is a private and permissioned blockchain.
A channel is a private blockchain overlay which allows for data isolation and confidentiality. A channel-specific ledger is shared across the peers in the channel, and transacting parties must be authenticated to a channel in order to interact with it. Channels are defined by a Configuration-Block.
At channel creation time, all organizations added to the channel must be part of a consortium. However, an organization that is not defined in a consortium may be added to an existing channel like by adding an new organization into that channel with fulfilling endorsement policy.
So to be a part of a channel, your organizational peer must need access according to the consortium. A peer can be a part of multiple channel and the ledger/database of every peer within a channel is identical/same, to invoke/query the ledger we need smart contact which is also identical among every peer of that channel. So if my peer server is a part of two channel, I need two ledgers/databases. To access the data of a ledger for invoke/query, you need corresponding smart contract.
According to your current setup, it's not possible and this is the nature of private-permissioned blockchain and to make it possible, you have to change the consortium with appropriate endorcement.
Only way to make peer on channel2 to access ledger of channel1 is to join the peer into channel1. Otherwise it is not possible to access the data.
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.
I have a web-based application for HR Employee management.
This application has many clients that login into the web app and uses the features.
I want to integrate this app into the blockchain. I want some of the data (compliance related, sensitive) to be recorded in the blockchain.
Data will be written to blockchain by my application only. My clients will only view the data.
What approach should I use?
a) Single Org (my app) with multiple peers (1 peer per client).
b) Multi-Org: Org1 = My app, Org 2 = Client 1, Org 3 = Client 2 .... n.
If any other approach please suggest.
Note: Individual Clients won't be sharing any data among themselves.
I want to use the hyper ledger fabric blockchain for only storing the information because it is immutable and tamper proof.
Even If I go with multi-org scenario, Both orgs will be added by me on servers managed by us. Will this cause trust issues in courts legally? Can I prove that data has not been tampered although all servers hosting blockchain are mine?
Based on your statement "Individual Clients won't be sharing any data among themselves", I would suggest 2 options based on the native capabilities of HLF, depending on whether all data in the transaction is private, or only a subset of the data.
No data is shared - one channel per peer, one peer/org per client OR one peer with multiple channels. In the multi-peer case, transaction data is only stored on the one peer which is a member of the channel. No other peers receive the data.
Some data is shared - one channel for all peers, one peer/org per client. In this case, a private data collection can be used to store private data. Transactions are stored on the ledgers of all peers, containing all the data in the case of the initiating peer, and only the public data plus the hash of the private data on all other peers.
Neither of these options provides data redundancy across peers, but since you didn´t state this as a requirement, I'm assuming this isn't a problem.
Since you state that you will be in control of all peers, the immutability guarantee doesn't count for much, as there is nothing to prevent you from rewriting the entire blockchain at any time. Despite this, such a solution would still be superior to a traditional database, since it would be immune to changes at an individual transaction level.
Hyperledger enables you to create participants (via chaincode) as well as Organisations (via fabric setup). In a supply chain or any process, how do you decide which one is an Organisation and which one is a participant.
From my understanding, all participants of same category should fall under one organisation.
But then I have another issue, will buyers also gonna have their own organizations?
Organizations on Hyperledger works like a Board of Directors, they vote in consensus inside your network, if you are the only one org then everything is auto approved by you, Ex. An upgrade in chaincode with new model.
Use case: Think about if we build a blockchain network for Banks, every institution will be an org and the participants are their respective clients.
It all depends on security and privacy factors.
let consider Maersk, If the network is setup within Maersk what's the purpose of hiding data within themselves ? untill and unless there is no trust within.
So if Data Availabilty > Data privacy, i'd go on creating Maersk as one Organization and all sub entity under them are Peers and one channel so that they can share data within and between them.
Now, what if someone other than Maersk entity needs to be involved? like fleet, shipping, delivery, Manufacturer etc, they are the separate Orgs as these Organizations don't need to share every data flowing in and out, they only require what they want to serve for Maersk.
There might be a case where each entity works separate and has their own rules and interaction with multiple other parties under a main entity. Then again you need to decide based on the data sharing ,Transparency, Availability between parties. if data is just available between one or two entity where does DLT concept comes in ? and how/where does consensus fit in ?!!
You need to keep all these factors over use case and decide upon creation of Org and Peer.
Correct me if i'm wrong