Would you tell me, if fabric does manual transaction validation?
i.e: Before a transaction could be archived in the ledger, it must be signed by the organization which evolved in the endorsement policies. This process of validation, by signing the transaction, could it be done manually by a decision of the user ( Clicking button )?
Thanks.
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.
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.
I am building a hyperledger fabric blockchain application where several users interact. It seems to be working. Using hyperledger explorer I can also view the blocks and transactions in the blockchain.
However, it is not clear to me how to see get the transaction history for 1 user (based on his / her identity key)?
Basically, like for a customer of a bank, I would like to get only the transactions relevant to a particular user to provide him/her with a transaction overview.
Is there a tool for this? Is it integrated into Fabric?
There are several different ways to go about this.
On-chain: You'd write a chaincode function to return the corresponding transactions. To do this you need to keep track of each user's submitted transactions by storing the transaction UUIDs in the chaincode state (stub.PutState). With stub.getState you can later retrieve the state and return the transaction list. (inspired by this StackOverflow answer)
Peer SDK: As far as chaincode-independent transaction history goes I'm not aware of any API calls that support this. You can only get a transaction by its UUID.
Off-chain: Since you're already using Hyperledger Explorer, you should have a Postgres database containing indexed transaction data. You can query the transactions table from your application by filtering for the creator_id_bytes. Since Hyperledger Explorer needs to fetch new transactions from the peer first, there is some additional latency with this approach compared to 1/2.
NB: I am seeking to understand how endorsements works in general. This will help me determine how to design applications when using Hyperledger Composer.
When I read the links here and here, I came across this statement: "Transactions have to be “endorsed” and only endorsed transactions may be committed and have an effect on the state". The statement is clear. However, let's consider the composer developer tutorial here. We have a commodity that is currently owned by an owner(Trader1) who could sell it to somebody else(Trader 2). Currently, how many endorsements are needed for the transaction to be put on the blockchain? Because, when running the application, I only submit a transaction Trade and I get results. I only deal with one function, and I get results. The following things are transparent to me as a programmer:
Creation of a transaction proposal,
When the transaction proposal is endorsed and by whom,
Whether an endorsement is performed explicitly by a human on the other end or it's programmatically done by code
That there is a proposal response from the endorser and how many they are,
When the application verifies the endorsing peer signatures
When the application creates a transaction message from the transaction proposal and response
etc.
All I do is submit one transaction and get a result.
So it becomes hard for me to assess the value of endorsement policies besides the theory in the text. And thus, the difficulty in designing a program to utilize the same. For example, consider two scenarios which we could use to handle a Trade:
We need 2 endorsements from the seller and the buyer before a transaction is commited. This would effectively be one transaction (This is what is transparent to me)
We need 2 authorizations from seller and the buyer before a transaction is commited. These authorizations could update states in the commodity such that we capture the approval from both the seller and the buyer. This could be 2 transactions i.e. sellerTradeRequest, buyerTradeApproval. The sellerTradeRequest could update commodity.sellerApproval=true while the buyerTradeApproval could update commodity.buyerApproval=true. Then, a final trade transaction that checks that the states on the commodity are OK i.e. commodity.sellerApproval=true and commodity.buyerApproval=true before commiting the transaction.
If I get a clear distinction between 1 and 2, especially how composer enables 1 above. Then maybe I will start understanding how to use endorsements.
Could anyone help?
The endorsement process is described in the docs. That said, in simple terms, the process of endorsement involves an endorsing peer signing the read/write set of a transaction proposal with its certificate. This basically says: the peer identified by the signing certificate asserts that these are the read/write sets of the proposed transaction simulation.
A client that invokes a proposed transaction will need knowledge of the endorsement policy for that channel/chaincode so that it can transmit the proposed transaction to each of the endorsing peers (or to a sufficient subset of endorsing peers to satisfy the policy). When it has received the responses from each endorsing peer, it will check that the transaction is valid and then broadcast the endorsed transaction to the ordering service, which will add it to a block and broadcast to the validating peers for that channel.
Validating peers will then validate the endorsement policy of the channel/chaincode against the transactions in a block to ensure that:
all endorsements are valid (i.e. they are valid signatures from valid certificates over the expected message)
there are an appropriate number of endorsements
endorsements come from the expected source(s)
If the endorsement policy is satisfied, then the transaction is committed and the world state updated with the read/write set.
At present, Composer cannot manage the endorsement policy, but this is definitely on the development roadmap.
The endorsement policy enables you the chance to add an extra verification layer to your Blockchain. You define it when you create the channel.
When a (Initial) Peer sends a proposal, firts of all the proposal is send to all of the Peers that you have defined in your Endorsement policy.
Then, each Endorser Peer executes the proposal against its ledger. The Endorser Peer will send the result signed to the Initial Peer.
The Initial Peer will receive more than one respone. Then, the Initial Peer will verify all the signatures and will compare the result of each response. The result sent by each Endorse Peer have to be the same.
In that case, the Initial Peer will send the transaction to the Orderers. That transaction will wraper all the responses all of the Endorses Peers.
So, you should define your Endorsement policy according to your requirements