Need of discovery interest with heterogeneous peers

[tskvivekmani]

For chaincode-to-chaincode calls, In heterogeneous peer setup (peers with different sets of chaincode installed) there has to be a way for client application to provide discovery interest.

Otherwise, it'll fail if it reaches to a peer without having that cc of interest available.

[andrew-coleman]

Hi @tskvivekmani, please could you give more details of you peer/chaincode config? The gateway internally builds the chaincode interest taking into account chaincode to chaincode calls and uses discovery to find the right peers. We have an integration test for that scenario: https://github.com/hyperledger/fabric/blob/main/integration/gateway/gateway_discovery_test.go#L534

[bviswana101]

Here is a scenario.

MSP: PeerOrg1 Peers: Peer1, Peer2, Peer3 Channel: mychannel Chaincode approved on channel: bts-chaincode, bts-ext-chaincode Chaincodes installed on peers Peer1: bts-chaincode, bts-ext-chaincode Peer2: bts-chaincode, bts-ext-chaincode Peer3: bts-chaincode

bts-chaincode calls bts-ext-chaincode for some transactions (TxA, B and D), but does not call bts-ext-chaincode for TxC and E.

The requirement is that when TxA, B and D are invoked then it can only be endorsed on Peer1 or Peer2 (but not on Peer3).

[andrew-coleman]

Which of those peers is your gateway peer? (i.e. which peer is your client app making the grpc connection to?). What error are you getting back when you submit the transaction?

[bviswana101]

@andrew-coleman we are migrating our existing code to gateway-apis. We do not have this setup in place yet, but our code handles it as our networks can be different. Earlier we were handling the scenario were peers had different chaincodes installed using discovery interest.

Now, with gateway apis, before we hit and reproduce the error, we would like to understand how Gateway server would be able to handle this and route the endorsement to the right peer (without hints).

We loadbalance among all existing peers, so any of peer1,2 or 3 can be the gateway peer.

[andrew-coleman]

Ah ok. The good news is that the new gateway service has a mechanism for determining the optimum set of endorsers for each transaction. The details of this are summarised in the docs here, and the implementation can be studied here. Basically it implements a two phase approach whereby the transaction is processed on one (preferable local) peer which builds a ChaincodeInterest structure based on the actual states that get updated by the chaincode. This is then used to build the full endorsement plan and get all necessary endorsements.

For your scenario, if the first endorser chosen happens to be Peer3 (if it has the highest block height), then it will fail and the gateway will retry on either Peer1 or Peer2, which should succeed.

[bviswana101]

Thanks @andrew-coleman. This is good to know.

So, in the case above, a first endorsement failure will be retried on a different peer and the state accessed from a successful 1st endorsement (simulation) will be used to construct the valid discovery interest for actual endorsement.

Do we expect a higher latency when using gateway apis, due to this multiple simulations? I am assuming that discovery results are cached and would be used even for 1st endorsement or is it always done locally.

In our production network, we have 10 peers (for a single MSP), a pair of peers joined to 1 distinct channel. For a total of 5 channels. When we select gateway peers to connect to, we connect to a random peer irrespective of which channel they have joined.

[bestbeforetoday]

Load testing I've seen has shown Gateway to give better performance than legacy SDKs, but I am pretty sure it didn't exercise the scenario you are suggesting where chaincodes have dependencies on other chaincodes that are not always co-located on the same peers. Only performance testing of your particular environment will tell you exactly what latency impact (if any) is introduced.

Where you know there are chaincode-to-chaincode dependencies, I would recommend deploying related chaincodes to the same peers to provide optimal performance.

[bestbeforetoday]

Based on the discussion above, I don't think there is a need for the client application to be able to declare a chaincode interest for a transaction invocation.

[bviswana101]

@bestbeforetoday if we have a scenario were C1 -> C2 -> C3, Then the 1st simulation (is likely to give only C1 and C2 states. Following which a 2nd simulation would get C1, C2 and C3. Only post it, can we get a endorsement. Worst case, would be N wasted simulations for a N depth call tree. Would it not make sense to take a hint in such cases?

[andrew-coleman]

Then the 1st simulation (is likely to give only C1 and C2 states

Why? Assuming the peer has all three chaincodes installed, then the first simulation with discover them all.