I am writing a new smart contract for Hyperledger Fabric which will need few data points(kind of reference data) for calculation. These data points need to be shared across all the Orgs so that the outcome of the smart contract is same and can be verified.
Should I maintain even these data points on Fabric blockchain? If so, when an Org modifies(add/update) the data how the other Orgs accept or reject this transaction?
Posting an answer as I can't comment yet. I would recommend to keep the data on the ledger itself as the reference data is of small size and have to be synchronized across the organizations. One initialization function can be used in the chaincode to initialize the data(--isInit) before allowing regular transactions.
Related
What happens if the ledger is taken out and attached to a new fabric network? especially in the below case
1 Fabric is used for storing confidential data among 3 parties.(via chaincode abac, chaincode multi ownership among 3 parties so there are three ledgers synced)
2 One party(party A) takes out the ledger and setup a new hlf behind and attaches the ledger to the new hlf and changes the chaincode in order to see all the data.......
In this scenario what can be implemented to prevent the party A from seeing the data.....isn't it true that the ledger is taken out so the ledger is just a chuck of file(impossible to function as long as it is not in the original HLF setup(the orginal hlf network.......even ip change blow up all the ledger and setting......).....
Look forward to your replies
For any given peer or orderer that is part of a Fabric "network", some person or entity will inevitably have physical access to the platform on which it is hosted. They will be able to physically read the ledger file(s) as well as the state database(s). So if they are not supposed to have access to the data, then you either need to encrypt the payloads at the application layer or you can use private data collections.
I am currently designing an application to be used to conduct transactions of an entity (e.g. a corporation).
When should the application have multiple chaincodes? In other words, what is the purpose of multiple chaincodes?
Why should a chaincode have multiple smart contracts? Should I have multiple smart contract for one that is used to submit transactions (e.g. making changes to world state) and another for evaluating transactions (e.g. querying from world state)?
Thank you!
For running a business, some organizations have to come into a consensus and so they have to create a channel where only permissioned organizational properties have access.
Here within a channel every valid organizational peer hold a physical copy of business transactional records which is known as ledger where the ledger is identical which means every ledger that belongs to same channel must hold the same records.
A ledger consists of two distinct, though related, parts – a world state and a blockchain. The world state – a database that holds current values of a set of ledger states. The blockchain – a transaction log that records all the changes that have resulted in the current the world state.
A chaincode is the business logic that is used to read the records of ledger or to write new records into the ledger or to update existing records.
A chaincode is consist with multiple smart contracts.
So The convention is for each channel, you need an identical chaincode. If you have 2 channel, than it's the convention that you have two different chaincodes.
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.
I am working on a dapp project only using Hyperledger Fabric. The situation is, a bank transfers money from account A to account B. This transaction is recorded in the blockchain. The thing is there will be a role similar to a supervisor. I just want the supervisor to know there was such a transaction and know some detail while some other details are hidden to the supervisor. Can HL Fabric achieve this? Or how can I achieve this?
You can use Hyperledger Fabric 'private data collections’ when participants need to transact on the same blockchain, but keep data private to a subset of transactors (and potentially regulators/auditors). Private data is shared peer-to-peer, with hashes stored on the blockchain as evidence so that all peers can validate transactions.
With private data collections, you can keep the entire state private, or make part of the state public, and part of the state private.
See the Fabric private data documentation and a tutorial.
Here is our use-case:
Anna would like to sell her shares to Peter, and Olga needs to approve it (as an owner of the company).
How would that work on blockchain hyperledger fabric/composer with consensus?
In particular, what part of that is a transaction, what is a proposal (is a proposal requires a physical approval of a transaction by a living person?) and how is that handled on blockchain, what happens in the application and outside of the application.
Please be as specific as possible.
Thanks!
A few things first:
Composer uses whatever consensus algorithm the underlying blockchain is configured to use. So; Hyperledger Fabric at the moment offers SOLO or KAFKA.
KAFKA offers fault tolerance only, not byzantine fault tolerance.
So:
Endorsement Policies do exist which is what you are describing. It does not require approval by a living person, you can make everything programmatic, it could even be an IoT device. The approver must simulate the transaction and see if they agree with the output. Olga is the approver in your scenario.
It's important to make all chaincode (transactions in Composer) deterministic, so they can be simulated in that way.
There is a good description on transaction flow on Fabric's docs: http://hyperledger-fabric.readthedocs.io/en/latest/txflow.html
I'm releasing a paper in a month that has a section on consensus comparisons and Composer/Fabric specifically. I can send you a draft if you're interested further.
There are two aspects to your question, one is the approval aspect of a living person and second is the integrity of the ledger state (consensus).
I will explain in the reverse order.
Consensus Part
So Hyperledger Fabric is an enterprise solution that targets to maintain a consistent ledger on which all organization of the consortium needs to agree upon. This is achieved by combining the ledgers of multiple organization into one ledger and the transactions recorded in this one ledger will include transaction from each party.
These transactions are not random transactions but rather implementation of Smart Contract called chaincode in Fabric terminology. Whenever a chaincode is deployed on a Fabric channel(a private subnet associated with its own ledger) it initializes the World State i.e default assets and their values.
Next each organization agree upon an endorsement policy, for example 1 peer from each organization should endorse the transaction(called transaction proposal in this state), the endorsement is simply a read-write set of the transaction having read set(values of assets before transaction simulation), write set(values of assets after the transaction simulation). If the endorsement from all peers(all those peers that satisfy the endorsement policy) is same, which means the world state of assets is consistent across all the peers(atleast those that satisfy endorsement policy) and hence ledger data integrity is achieve.
The consensus further includes batching transactions into blocks and ordering of the transactions within the block by ordering service which validates the endorsers signatures again and the World State validation is done one final time when the block reaches peers for committing.
Approval part
When you have an approval process that requires a participant interaction, it is something that you will have to take care of in your chaincode. Composer is the best place to start.
From Composer examples look at the CarAuction example and you will understand the for each state transition you will have to have registery e.g a seller participant owns an asset Car but when the Car is auctioned for selling it has to be added to a listing registry using transaction where it will be visible to all bidder participants, this movement of state of Car asset is achieved by a transaction AuctionMyCardOrSomething invoked by authorized party here seller. Then when the Auctioneer(another participant with a different role) executes another transaction called closed bidding then the Car ownership can be transferred to the highest bidder if all conditions are satisfied. Node that placing a bid is also a transaction.
Pay attention the the Auctioneer and state transitions in this example and the same model can be applied to your case. Each time state transition is required you have to execute a transaction and update the ledger.
Hope this helps.