Hyperledger Fabric 中的读取（查询）交易流程
Read (query) transaction flow in Hyperledger Fabric
我正在尝试了解 Hyperledger Fabric 中的 "Query" 交易流程。我了解 Fabric 中的 "write" 流程，因为它有据可查。但是，当涉及到 read/query 笔交易时，事情就不那么清楚了。
目前我的理解是这样的：
- 使用 SDK 的客户端准备查询链码的交易提案。
- 提案通过提交节点传输到背书节点，后者最终验证并模拟交易。假设一切成功，背书同行 return 他们对该提案的背书。每个背书都包含世界状态的 readset。由于这只是一个查询事务，因此不会在每个 ensorsement 中添加一个 writeset。我的理解对吗？
- 一旦客户端收到所需数量的背书，它就会准备发送给订购者的交易。
我不太确定这之后的流程。写入交易是可以理解的：订单在执行一些检查后将创建一个块并将该块传播到连接到相应通道的所有对等点。在对区块中的所有交易进行验证后，所有节点都会将区块追加到账本中，这实际上更新了账本。
但是读取事务呢？订购者在收到读取交易后会 return 做什么？以后的流量是多少？
任何帮助或指点将不胜感激。
提前致谢。
你可能想看一下SDK提供的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，方便查询。
根据您在 post 中概述的流程，第 1 步和第 2 步是正确的。
此外，用于查询事务的链代码函数通常会使用 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.
没有必要将查询交易的响应发送给订购者，但只要您满足背书政策就可以。感谢 Dave Enyart 提供以下内容：
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.
这似乎与您在对这个问题的回复中发布的内容相矛盾：
您在此处描述的行为是有道理的，而上述答案中的行为似乎完全错误。然而，似乎不允许频道上的读者执行调用。
我正在尝试了解 Hyperledger Fabric 中的 "Query" 交易流程。我了解 Fabric 中的 "write" 流程，因为它有据可查。但是，当涉及到 read/query 笔交易时，事情就不那么清楚了。
目前我的理解是这样的：
- 使用 SDK 的客户端准备查询链码的交易提案。
- 提案通过提交节点传输到背书节点，后者最终验证并模拟交易。假设一切成功，背书同行 return 他们对该提案的背书。每个背书都包含世界状态的 readset。由于这只是一个查询事务，因此不会在每个 ensorsement 中添加一个 writeset。我的理解对吗？
- 一旦客户端收到所需数量的背书，它就会准备发送给订购者的交易。
我不太确定这之后的流程。写入交易是可以理解的：订单在执行一些检查后将创建一个块并将该块传播到连接到相应通道的所有对等点。在对区块中的所有交易进行验证后，所有节点都会将区块追加到账本中，这实际上更新了账本。
但是读取事务呢？订购者在收到读取交易后会 return 做什么？以后的流量是多少？
任何帮助或指点将不胜感激。
提前致谢。
你可能想看一下SDK提供的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，方便查询。
根据您在 post 中概述的流程，第 1 步和第 2 步是正确的。
此外，用于查询事务的链代码函数通常会使用 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.
没有必要将查询交易的响应发送给订购者，但只要您满足背书政策就可以。感谢 Dave Enyart 提供以下内容：
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.
这似乎与您在对这个问题的回复中发布的内容相矛盾：
您在此处描述的行为是有道理的，而上述答案中的行为似乎完全错误。然而，似乎不允许频道上的读者执行调用。