Hyperledgerファブリックのトランザクションフローの読み取り（クエリ）

Question

Hyperledgerファブリックの「クエリ」トランザクションフローを理解しようとしています。私はFabricの「書き込み」フローが十分に文書化されていることを理解しています。しかし、読取り/照会のトランザクションが関係している場合、そのことはあまり明確ではありません。

これは私がこれまで理解しているものです：

1. SDKを使用してクライアントがchaincodeを照会するため、取引の提案を準備します。
2. プロポーザルはコミッティングピアを介してEndorsingピアに送信され、エンドでトランザクションを検証し、シミュレートします。すべてが成功したと仮定すると、支持している同僚は、その提案に対する支持を返す。各裏書には、とりわけ、のリードセットが含まれています。これは単なるクエリトランザクションなので、書き込みセットは、それぞれの預託の内側に追加されません。私の理解はここで正しいのですか？
3. クライアントは必要な裏書を受け取ると、注文者に送信されるトランザクションを準備します。

これ以降のフローはわかりません。書き込みトランザクションが理解できます：いくつかのチェックを実行した後の注文はブロックを作成し、ブロックを対応するチャネルに接続されているすべてのピアに伝播します。すべての同僚は、ブロック内のすべてのトランザクションの検証を実行した後に元帳にブロックを追加します。これは本質的に元帳を更新します。

しかし、読み取りトランザクションはどうですか？発注者は、読取り取引を受けて何を返すのですか？これからの流れは？

何か助けや指針が高く評価されます。

ありがとうございます。

Answer 1

https://github.com/hyperledger/fabric-samples/blob/release/fabcar/query.jsで、Node SDKを使用してクエリを実行する方法について説明しています。クエリを容易にするために、SDKが提供する便利なメソッドhttps://fabric-sdk-node.github.io/Channel.html#queryByChaincode__anchorが使用されています。

あなたの投稿に記載されているフローの点では、手順1と2は正しいです。
さらに、クエリトランザクション用のチェーンコード関数は通常、クエリの結果を実際に返すためにヘルパー関数https://godoc.org/github.com/hyperledger/fabric/core/chaincode/shim#Successを使用します。上に掲げたサンプルでは、​​https://github.com/hyperledger/fabric-samples/blob/release/fabcar/query.js#L51はhttps://github.com/hyperledger/fabric-samples/blob/release/chaincode/fabcar/fabcar.go#L135を呼び出します。

保証取引の方針を満たしていれば、照会トランザクションからの応答を発注者に送る必要はありません。 Dave Enyeartさんに感謝します。

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.