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.
Related
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 am currently working in projects using Fabric 1.4 I am able to get a decent idea of how things seems to work out but I am quite confused with the way smart contracts and endorsement policies work together.
What i have understood is that endorsement policy is defined during chaincode instantiation where say two or three orgs will sign a transaction in order for it to be valid. This kind of an endorsement just verifies the transaction signatures right ? no data level checks.
Like say I have this kind of a scenario: I have three orgs(Org1,Org2,Org3) each with a peer. Now through a client web app each peer puts data into the blockchain. Now how do I verify if the data (the information that I submit in the blockchain) say for example the name and id are validated by another peer properly and only then added to the world state.
Example: If peer0 in org1 adds data, name and id and the ID is wrong. Org2 has a list of IDs and it should check if the ID that org1 added matches with it and validates it. If it validates then it is fine and data can be put it in the world state
How to define this kind of a transaction state level validation (more of a data level validation rather than just signature verification)? Can this be done in the Go smart contract.
Any help and suggestions would help.
Thanks
During the endorsement, each selected endorser executes (or simulates) the transaction and returns its response, read set and write set signed. The client checks signatures and that responses from different endorsers match (or at least it should do it, anyway this check is performed later again by committers), so there are data level checks (your premise is wrong). The client assembles all the endorsements into a transaction and broadcasts it so it reaches to the ordering service. The ordering service adds the transaction to a block and the block is send to every (committer) peer joined to the channel. The committers perform their checks again and commit the transaction into the state.
It is perfectly explained here: https://hyperledger-fabric.readthedocs.io/en/release-1.4/txflow.html.
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
Can someone explain how the immutability is implemented in Hyperledger Fabric? If we have private channel with little amount of peers, how it can be guaranteed, that one side hasn't changed data in it's ledger?
In order to guarantee that no party in the channel has tampered data in its own favor you need to present sophisticated endorsement policy to include all required parties and make sure they adequately represented within endorsement policy. Hence making it obligatory for client which issues new transaction to get endorsement from all interested parties, hence ensuring that all have same consistent state. For example if you have two organizations Org1 and Org2 and they do not trust each other, you would like to create endorsement policy:
AND(Org1.memmber, Org2.member)
Therefore client will have to collect endorsements from peers of both organization to consider the transaction valid those endorsement have to sign same bytes, which won't be the case if data was forged. You can read more about endorsements in official documentation. There is also a recent publication of Fabric architecture which explains it in more details.
With Ethereum, gas is an anti-denial of service measure. What is the equivalent in Hyperledger Fabric to avoid abuse of chaincode invocation transactions (INVOKE)? Is the NVP expected to check this abuse?
From what I understood, there is no need for such a gas system in Hyperledger Fabric.
The blockchain is supposed to work in a "private" mode, meaning that you know the other peers in the network. It would be easy to detect a malicious peer and revoke its access. Also, there is no "mining" process, only consensus rules triggered for each incoming transaction. This results in a lighter block generation process compared to Bitcoin or Ethereum for example.
However, you can still implement your own custom gas system with a chaincode that add some kind of "transaction fee" before validating any Invoke transaction, but I don't think it would be possible to "mine" gas in the current state of the project.