I have deployed a blockchain network with the Hyperledger Fabric framework. My chaincode works fine. When invoking a method on the peer node cli of an anization (let's call it 1), I need to pass the ca.crt for this peer node as well as the ca.crt for an endorsing peer node in another anization (let's call this 2).

I manually copy the ca.cart from the endorsing peer node anization into the cli of the transacting peer node anization at the path /tmp/example2-net-ca.crt. I invoke the contract with this command:

peer chaincode invoke -o orderer1.example1-net:7050 --tls --cafile /opt/gopath/src/github/hyperledger/fabric/orderer/tls/orderer.crt --channelID example1-channel --name example-chaincode -c '{"Function":"ExampleMethod", "Args":["example_param_1", "example_param_2"]}' --peerAddresses peer0.example1-net:7051 --tlsRootCertFiles /opt/gopath/src/github/hyperledger/fabric/crypto/admin/msp/cacerts/ca.crt --peerAddresses peer0.example2-net:7051 --tlsRootCertFiles /tmp/example2-net-ca.crt

This invocation works, and it is understood that the secret of the endorsing peer is needed for the transaction to go through.

However, when I use the Hyperledger Fabric Application v2.5 Gateway, I only specify secrets for the transacting peer node in 1. These secrets include the ca.crt of the peer node and the keystore and signcerts of the user. Nowhere in my code, do I specify secrets for the endorsing peer node of 2, yet the transaction still works. Where and how exactly is the application gateway fetching these secrets or does the application not need them and why? On the other hand, how would I use the peer invoke command to mimic how the application invokes a transaction?

Thank you.

I have deployed a blockchain network with the Hyperledger Fabric framework. My chaincode works fine. When invoking a method on the peer node cli of an anization (let's call it 1), I need to pass the ca.crt for this peer node as well as the ca.crt for an endorsing peer node in another anization (let's call this 2).

I manually copy the ca.cart from the endorsing peer node anization into the cli of the transacting peer node anization at the path /tmp/example2-net-ca.crt. I invoke the contract with this command:

peer chaincode invoke -o orderer1.example1-net:7050 --tls --cafile /opt/gopath/src/github/hyperledger/fabric/orderer/tls/orderer.crt --channelID example1-channel --name example-chaincode -c '{"Function":"ExampleMethod", "Args":["example_param_1", "example_param_2"]}' --peerAddresses peer0.example1-net:7051 --tlsRootCertFiles /opt/gopath/src/github/hyperledger/fabric/crypto/admin/msp/cacerts/ca.crt --peerAddresses peer0.example2-net:7051 --tlsRootCertFiles /tmp/example2-net-ca.crt

This invocation works, and it is understood that the secret of the endorsing peer is needed for the transaction to go through.

However, when I use the Hyperledger Fabric Application v2.5 Gateway, I only specify secrets for the transacting peer node in 1. These secrets include the ca.crt of the peer node and the keystore and signcerts of the user. Nowhere in my code, do I specify secrets for the endorsing peer node of 2, yet the transaction still works. Where and how exactly is the application gateway fetching these secrets or does the application not need them and why? On the other hand, how would I use the peer invoke command to mimic how the application invokes a transaction?

Thank you.

• blockchain
• hyperledger-fabric

1 Answer 1

The difference in how the transaction flow is executed between Legacy client SDKs and the Fabric Gateway client API described on this page might help to explain the difference in behaviour. The Fabric peer CLI command behaves in the same way as the Legacy client SDKs — it makes direct connection to each endorsing peer, whereas applications using the Fabric Gateway client API connect only to the Gateway peer, and the Gateway peer then connects to the endorsing peers on behalf of the client.

Connections to peers use HTTPS / TLS so the CA certificate for the authority that signed each anisation peers TLS certificate is required to verify that the connection is secure. The Gateway peer has all of the CA certificates available from its local ledger since they are recorded in the channel configuration.