0

In Hyperledger Fabric, one asset has multiple transactions. These transactions update the state of the asset and maintain a trace as well.

Currently, if I want to have different transaction types for one asset, then I've written different functions in the chaincode which correspond to transaction types.

For example: If my assets are Cars, then each asset can have transactions of types sale, purchase, service, repair, etc. For each of these purchase, repair, service, etc., I've written a function in chaincode which gets invoked based on the type of transaction that is sent as input (type of transaction is sent as an argument in peer chaincode invoke command).

Do you think this is a good approach? What do you follow? What is recommended to achieve different transaction types? Also, how can I enforce different endorsement policies for different transaction types?

Note: I'm aware of the asset based (or key based) endorsement policies (Fabric v1.4) that can be written in chaincode. But this does not allow me to configure endorsement policies based on transaction types.

Raman Kishore
  • 542
  • 2
  • 12

1 Answers1

3

The pattern you are using is fairly typical ... chaincode is after all really just a state machine. It's fairly common to have different chaincode representing different types of assets or asset classes. You'll typically have multiple functions which manage the lifecycle of the asset (which it seems you do). The typical pattern is that the first argument when invoking chaincode represents the function you wish to invoke but up to you if you want to modify that pattern.

In terms of having different endorsement policies for different actions taken on the same state, this is not supported as it's typically not needed. You need to take care not to confuse endorsement policies (agreement on the output of an invocation) with an agreement protocol (e.g. I agree to sell you my car). That type of logic is typically handled within the chaincode function(s) (for example you'd check that the creator of the invoke is actually the owner of the car).

Hope this helps.

P.S. If you did want to have different endorsement policies for different transaction types, you could probably use state-based endorsement ... the policies are set via chaincode anyway ... so you could attempt to set the endorsement policy for each state based on the transaction type.

Gari Singh
  • 11,418
  • 2
  • 18
  • 41
  • I understand the difference between endorsement policies and agreement protocol. In a practical scenario, lets say I have 3 Orgs - Org A, B and C as a part of a Channel. For few specific transactions, I want to have endorsements from Orgs A and B because these transactions are of high interest to A and B. But for few other transactions, I might want endorsements from Orgs A and C because these transactions are of high interest to A and C. Does this scenario make sense? If so, what would be a good approach to have transaction type specific endorsement policies? Thanks for your time. – Raman Kishore Jun 04 '19 at 09:45
  • I have 2 questions: 1) I can set endorsement policies for a key through the state based endorsement. But, this would end up being the endorsement policy for that key for all the transactions related to that key. I will not be able to achieve different endorsement policy for each transaction type for a single key. 2) If I start setting endorsement policies differently for each key, say, I have 10000 keys, I would have to set endorsement policy for each one of them. Simpler way would be to set endorsement policy based on transaction type, if that's possible. – Raman Kishore Jun 06 '19 at 09:19
  • Also it's not possible. What about question 1 that I've asked above? Let me know if I'm missing something in understanding what you've said. – Raman Kishore Jun 06 '19 at 13:17
  • For question1, it might work if there is a defined lifecycle across the transaction types ... for example if typically call DoA(), then DoB(), then DoC(), the output of each step could set the endorsement policy that would be appropriate for the next step. Other than that, you are stuck with channel/chaincode-scoped endorsement policy – Gari Singh Jun 06 '19 at 13:31