Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Read (query) transaction flow in Hyperledger Fabric

I am trying to understand the "Query" transaction flow in Hyperledger Fabric. I understand the "write" flow in Fabric as it is well documented. However, things are not so clear when a read/query transaction is involved.

This is what I have understood so far:

  1. A client using an SDK prepares a transaction proposal for querying a chaincode.
  2. The proposal is transmitted via a committing peer to the Endorsing peers which validate as well as simulate the transaction in their end. Assuming everything is successful, the endorsing peers return their endorsements for the proposal. Each endorsement contains, among other things, a readset of the world state. Since this is just a query transaction, a writeset is not added inside each ensorsement. Is my understanding correct here?
  3. Once the client receives the required amount of endorsement, it prepares a transaction which is sent to the Orderer.

I am not so sure of the flow after this. A write transaction is understandable: the order, after carrying out some checks, will create a block and propagate the block to all peers connected to the corresponding channel. All peers will append the block in the ledger after carrying out the validation of all transactions in the block, this essentially updates the ledger.

But what about a read transaction? What does the orderer will return upon receiving a read transaction? What will be the flow hereafter?

Any help or pointers will be highly appreciated.

Thanks in advance.

like image 775
Ripul Avatar asked Sep 16 '17 12:09

Ripul


People also ask

How is the transaction flow in Fabric?

transaction flow in Fabric follows three phases: execution, ordering and validation.

What does the check transaction () method do in the agree flow?

Checking that the proposed transaction is valid.

How a Blockchain transaction is executed in Hyperledger Fabric?

Within a Hyperledger Fabric network, transactions carried out by a client application, sending transaction proposal, or, in other words, proposing a transaction to endorsing peers. Before sending the transaction to endorsing peer, client SDK needs to know the list of all Endorsing peers in the network.

What is read/write set in Hyperledger Fabric?

The read set contains a list of unique keys and their committed version numbers (but not values) that the transaction reads during simulation. The write set contains a list of unique keys (though there can be overlap with the keys present in the read set) and their new values that the transaction writes.


1 Answers

You might want to take a look at https://github.com/hyperledger/fabric-samples/blob/release/fabcar/query.js which demonstrates how to query using the Node SDK. You'll notice that it uses the convenience method https://fabric-sdk-node.github.io/Channel.html#queryByChaincode__anchor provided by the SDK to help facilitate queries.

In terms of the flow you outlined in your post, steps 1 and 2 are correct.
Additionally, chaincode functions which are intended for query transactions will typically use the https://godoc.org/github.com/hyperledger/fabric/core/chaincode/shim#Success helper function to actually return the result of the query. In the sample I posted above, https://github.com/hyperledger/fabric-samples/blob/release/fabcar/query.js#L51 invokes https://github.com/hyperledger/fabric-samples/blob/release/chaincode/fabcar/fabcar.go#L135.

There is no need to send the responses from a query transaction to the orderer although you can as long as you meet the endorsement policy. Thanks to Dave Enyeart for the following:

A query is a chaincode invocation which reads the ledger current state but does not write to the ledger. The chaincode function may query certain keys on the ledger, or may query for a set of keys on the ledger. Since queries do not change ledger state, the client application will typically not submit these read-only transactions for ordering, validation, and committal. Although not typical, the client application can choose to submit the read-only transaction for ordering, validation, and commit, for example if the client wants auditable proof on the ledger chain that it had knowledge of specific ledger state at a certain point in time. Peers will validate and add the read-only transaction to the ledger chain, but there will be no updates to ledger current state.

like image 141
Gari Singh Avatar answered Nov 02 '22 06:11

Gari Singh