0

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

Skadoosh
  • 699
  • 2
  • 11
  • 27

1 Answers1

1

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.

kekomal
  • 2,179
  • 11
  • 12
  • i am aware of the transaction flow. But what it does is only do signature level checks right ? Like how does it address the example scenario I have given in the question above. Or is the only way to do it is by defining methods within the smart contract itself ? – Skadoosh Apr 07 '20 at 16:59
  • Both the client and the committers perform data level checks. You can try it. Write a chaincode with a single operation that generates and writes some **random** number. Instantiate it with an endorsement policy that requires more than an endorsement. And invoke the operation. The client is going to detect that data does not match. If your client is dumb or malicious, the committers will detect it, as all the endorsements are included in the transactions. The response, the read set and the write set are checked. Or maybe I don't understand you when you say "data level checks". – kekomal Apr 07 '20 at 21:24
  • And committers even check if the read set of the transaction is the expected one. That causes the classical `MVCC_READ` error when trying to update the same document twice on the same block. – kekomal Apr 07 '20 at 21:31
  • 1
    And finally (although you are already aware of the transaction flow) remember that the endorsement is only a simulation of the transaction. The endorser reads the state from the DB as updated from last block (not from last endorsement) and returns the expected update in the write set. But it writes nothing to the DB. Is in the step 6 when the DB (and so the state) is written according to the transactions assembled in the block (if correct). And yes, data is checked. – kekomal Apr 07 '20 at 21:50
  • nice i get the idea now. – Skadoosh Apr 08 '20 at 15:36