Hyperledger Fabric SDK Design Role of the application

Question

When using an application which utilizes a hyperledger fabric network the application has an identity, e.g. a user identity. When invoking functions, it has to be send to and singed by all endorsing peers. The application needs to handle this whole process, so it has to have knowledge about the blockchain network/logic.

I think that this might not be a good design for an sdk. It would be better that the application connects to a peer and sends it invocation request to the connected peer. The peer then handles all the blockchain logic, including the endorsement and the sending to the orderer peer.

E.g. Tendermint does it like this. The interface between application and blockchain then becomes thin and easy to work with.

Is this also possible with hyperledger fabric sdk? E.g. assume there is an endorsement policy which states that two peers have to endorse a transaction. It is possible to communicate just whith one peer and let it automatically handle the whole transaction flow?

Answer 1

When invoking functions, it has to be send to and singed by all endorsing peers. The application needs to handle this whole process, so it has to have knowledge about the blockchain network/logic.

Yep, unfortunately, right now - the application needs to code the endorsement policy logic inside of it. Another problematic aspect is that it needs to be preconfigured with the endpoints of the peers.

However, not for long! hopefully in v1.2 or v1.3 Fabric will have a service discoverymechanism in which the Fabric SDK would query peers for network metadata information, like where are the other peers running, and also for information like "given chaincode foo in channel bar, which peers should I ask endorsements from?" And the application won't have to deal with all that infrastructure-level knowledge, and would focus only on business logic.