Hyperledger 패브릭의 트랜잭션 흐름 읽기 (쿼리)

Question

Hyperledger 패브릭의 "쿼리"트랜잭션 흐름을 이해하려고합니다. Fabric의 "쓰기"흐름이 잘 설명되어 있으므로 이해합니다. 그러나 읽기/쿼리 트랜잭션이 포함될 때 명확하지 않습니다.

이것은 내가 지금까지 이해 한 것입니다 :

1. SDK를를 사용하는 클라이언트는 chaincode 쿼리에 대한 거래 제안을 준비합니다.
2. 제안서는 커밋 피어 (peer)를 통해 엔드 포인트 피어 (endorsing peer)에게 전송되며 최종 피어는 해당 트랜잭션을 검증하고 시뮬레이트합니다. 모든 것이 성공했다고 가정하면, 보증하는 동료는 제안서에 대한 보증을 반환합니다. 각 보증서에는 무엇보다도 readset이 포함되어 있습니다. 이것은 쿼리 트랜잭션 일 뿐이므로 쓰레드 세트은 각 안의 내부에 추가되지 않습니다. 내 이해가 정확합니까?
3. 클라이언트가 필요한 금액의 보증을 받으면 Orderer로 전송되는 트랜잭션을 준비합니다.

이 이후의 흐름에 대해서는 잘 모릅니다. 쓰기 거래는 이해할 수 있습니다. 일부 수표를 수행 한 후 주문이 블록을 만들고 해당 채널에 연결된 모든 피어에게 블록을 전파합니다. 모든 동료는 블록에서 모든 거래의 유효성 검사를 수행 한 후 원장에 블록을 추가합니다. 이는 본질적으로 원장을 업데이트합니다.

하지만 읽기 거래는 어떻게됩니까? 읽기 거래가있을 때 주문자는 무엇을 반환합니까? 앞으로의 흐름은 무엇입니까?

도움이나 조언을 주시면 감사하겠습니다.

미리 감사드립니다.

Answer 1

노드 SDK를 사용하여 쿼리하는 방법을 보여주는 https://github.com/hyperledger/fabric-samples/blob/release/fabcar/query.js을 살펴볼 수 있습니다. 쿼리를 용이하게하기 위해 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.