How to accomplish a transaction level consensus/endorsement between two organizations?
Let's say if OrgA sends Rs.5 to OrgB, OrgB should validate it and approve/decline based on some predefined agreement.
If OrgB expects Rs.15 and not Rs.10 for this transaction, it should raise a concern.
Where do we specify these details? I could see that the chaincode instantiate can specify policy but that is very generic as to how many endorsers should be there but not at a deeper level.
To achieve that, you will need a mechanism to set separate policies for individual keys, rather than the general chaincode-level policy for all the keys in the chaincode. This feature is part of Fabric 1.3, which will have a release candidate version (rc1) out within next few days.
More details here:
https://jira.hyperledger.org/browse/FAB-8812
Related
I am trying to implement a smart contract where a member of an organization can submit a proposal document (this is a simple text that will be recorded in the state), other orgs can vote on it (approve/reject), and if the majority have approved, the proposal gets accepted.
The documentation about transaction flow and the accepted answer here suggest that endorsement of transactions should not encode "business logic", i.e. a transaction that "plays by the rules" should get endorsed.
Therefore, I want to implement this approval/rejection process on the smart contract level. In this model the proposal, as well as each vote is a separate transaction. Then, the proposer can submit another transaction to count the votes and finalize the proposal.
For this, I need to get the list of organizations that are member of the channel. How can this be done within a smart contract's functions?
You would need to be able the chaincode smart contract to retrieve the latest configuration block from the peer/orderer and then parse that block to get the list of organizations.
This means you'll need a way to send the private key of a client into the chaincode invocation.
To send the private key of a client, it's better to have a dedicated MSP only for that client, so the MSP will be not included in any endorsement policies, or other channel config policies for security reasons.
Then, to parse the config block you can follow the code here.
Note that you cannot use a QSCC query inside a chaincode, although it is tempting to do so, because chaincode-to-chaincode invocations with QSCC are fobidden.
I am actually new to Hyperldeger fabric framework. I am working on research project where I want to select specific Endorsers from my end. Can we really do that ?
As far as I know, the Endorsement policy will be always in the syntax of "AND(Org1MSP.peer,Org2MSP.peer)". But I want to select the individual peers of the organization and currently it seems impossible. Is there any other workaround ?
Please put some light on this.
From your client, you can choose to select whatever endorser peers you prefer for each transaction through Transaction.setEndorserPeers(peers). But it is a client decision, not a network restriction. Another client could choose any other endorser selection strategy (as long as it fulfills the endorsement policies of the chaincode). At endorsement policy level, you cannot require specific peers.
In Hyperledger Fabric, one asset has multiple transactions. These transactions update the state of the asset and maintain a trace as well.
Currently, if I want to have different transaction types for one asset, then I've written different functions in the chaincode which correspond to transaction types.
For example: If my assets are Cars, then each asset can have transactions of types sale, purchase, service, repair, etc. For each of these purchase, repair, service, etc., I've written a function in chaincode which gets invoked based on the type of transaction that is sent as input (type of transaction is sent as an argument in peer chaincode invoke command).
Do you think this is a good approach? What do you follow? What is recommended to achieve different transaction types?
Also, how can I enforce different endorsement policies for different transaction types?
Note: I'm aware of the asset based (or key based) endorsement policies (Fabric v1.4) that can be written in chaincode. But this does not allow me to configure endorsement policies based on transaction types.
The pattern you are using is fairly typical ... chaincode is after all really just a state machine. It's fairly common to have different chaincode representing different types of assets or asset classes. You'll typically have multiple functions which manage the lifecycle of the asset (which it seems you do). The typical pattern is that the first argument when invoking chaincode represents the function you wish to invoke but up to you if you want to modify that pattern.
In terms of having different endorsement policies for different actions taken on the same state, this is not supported as it's typically not needed. You need to take care not to confuse endorsement policies (agreement on the output of an invocation) with an agreement protocol (e.g. I agree to sell you my car). That type of logic is typically handled within the chaincode function(s) (for example you'd check that the creator of the invoke is actually the owner of the car).
Hope this helps.
P.S. If you did want to have different endorsement policies for different transaction types, you could probably use state-based endorsement ... the policies are set via chaincode anyway ... so you could attempt to set the endorsement policy for each state based on the transaction type.
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.
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.