Using endorsements in Hyperledger Composer to design a process

Question

NB: I am seeking to understand how endorsements works in general. This will help me determine how to design applications when using Hyperledger Composer.

When I read the links here and here, I came across this statement: "Transactions have to be “endorsed” and only endorsed transactions may be committed and have an effect on the state". The statement is clear. However, let's consider the composer developer tutorial here. We have a commodity that is currently owned by an owner(Trader1) who could sell it to somebody else(Trader 2). Currently, how many endorsements are needed for the transaction to be put on the blockchain? Because, when running the application, I only submit a transaction Trade and I get results. I only deal with one function, and I get results. The following things are transparent to me as a programmer:

Creation of a transaction proposal, When the transaction proposal is endorsed and by whom, Whether an endorsement is performed explicitly by a human on the other end or it's programmatically done by code That there is a proposal response from the endorser and how many they are, When the application verifies the endorsing peer signatures When the application creates a transaction message from the transaction proposal and response etc.

All I do is submit one transaction and get a result.

So it becomes hard for me to assess the value of endorsement policies besides the theory in the text. And thus, the difficulty in designing a program to utilize the same. For example, consider two scenarios which we could use to handle a Trade:

1. We need 2 endorsements from the seller and the buyer before a transaction is commited. This would effectively be one transaction (This is what is transparent to me)
2. We need 2 authorizations from seller and the buyer before a transaction is commited. These authorizations could update states in the commodity such that we capture the approval from both the seller and the buyer. This could be 2 transactions i.e. sellerTradeRequest, buyerTradeApproval. The sellerTradeRequest could update commodity.sellerApproval=true while the buyerTradeApproval could update commodity.buyerApproval=true. Then, a final trade transaction that checks that the states on the commodity are OK i.e. commodity.sellerApproval=true and commodity.buyerApproval=true before commiting the transaction.

If I get a clear distinction between 1 and 2, especially how composer enables 1 above. Then maybe I will start understanding how to use endorsements.

Could anyone help?

Answer 1

The endorsement process is described in the docs. That said, in simple terms, the process of endorsement involves an endorsing peer signing the read/write set of a transaction proposal with its certificate. This basically says: the peer identified by the signing certificate asserts that these are the read/write sets of the proposed transaction simulation.

A client that invokes a proposed transaction will need knowledge of the endorsement policy for that channel/chaincode so that it can transmit the proposed transaction to each of the endorsing peers (or to a sufficient subset of endorsing peers to satisfy the policy). When it has received the responses from each endorsing peer, it will check that the transaction is valid and then broadcast the endorsed transaction to the ordering service, which will add it to a block and broadcast to the validating peers for that channel.

Validating peers will then validate the endorsement policy of the channel/chaincode against the transactions in a block to ensure that:

1. all endorsements are valid (i.e. they are valid signatures from valid certificates over the expected message)
2. there are an appropriate number of endorsements
3. endorsements come from the expected source(s)

If the endorsement policy is satisfied, then the transaction is committed and the world state updated with the read/write set.

At present, Composer cannot manage the endorsement policy, but this is definitely on the development roadmap.

Answer 2

The endorsement policy enables you the chance to add an extra verification layer to your Blockchain. You define it when you create the channel.

• When a (Initial) Peer sends a proposal, firts of all the proposal is send to all of the Peers that you have defined in your Endorsement policy.
• Then, each Endorser Peer executes the proposal against its ledger. The Endorser Peer will send the result signed to the Initial Peer.
• The Initial Peer will receive more than one respone. Then, the Initial Peer will verify all the signatures and will compare the result of each response. The result sent by each Endorse Peer have to be the same.
• In that case, the Initial Peer will send the transaction to the Orderers. That transaction will wraper all the responses all of the Endorses Peers.

So, you should define your Endorsement policy according to your requirements