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:
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.
transaction flow in Fabric follows three phases: execution, ordering and validation.
Checking that the proposed transaction is valid.
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.
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With