CODEWITHSUNDEEP
hyperledger-fabrichyperledger
Ajay
Ajay

Reputation: 781

Hyperledger fabric - Single Org vs Multi Org and When to setup Multi Org environment?

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?

Upvotes: 2

Views: 579

Answers (1)

Paul Russell
Paul Russell

Reputation: 544

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.

Upvotes: 2

Related Questions