1

Assume that there exist 2 different chaincodes, say chaincodeA and chaincodeB.

chaincodeA implements a function that, before it is completed (e.g. put something in the state), it invokes a function from chaincodeB that asks the Admins from the other organizations to approve this action.

For example:

  1. chaincodeA is called - A function starts and after some steps invokes the corresponding function at chaincodeB that asks the admins of the other orgs to consent
  2. The invoked function at chaincodeB starts and asks each and every Admin at the other organizations for their approval. While this happens, the function at chaincodeA awaits for the delivery of the signed approvals.
  3. Every admin has answered - The result is returned to chaincodeA's invoked function and is checked for majority consent.
  4. If the majority of the admins approved the action, then the function can continue, else returns an error.

Is something like this (or close to this) possible? If no, even without manual intervention, how something like this can be achieved?

Should I reach consensus before the invocation of the function at chaincodeA, and save to the state the answers of the admins, so I can check them when its needed?

GeorgePal
  • 85
  • 6

1 Answers1

1

Manual Intervention

I have considered something along these lines previously - getting human input as part of the Smart Contract. As part of this thought experiment, I found a few gotchas.

  • Timeout, a transaction has to complete eventually so there is a timeout configured on the peer. At some point it needs to timeout the transaction. Any input from a human would need to be quick enough to get in under this timeout, or at the very least have an acceptable default option.
  • How do you confirm who you are asking? How is their identity determined? Classic problems but also very relevant here

Alternatives

I think the best alternative would be to look at a more asynchronous model. For example, one transaction records the fact that a decision needs to be made. Each admin can record their 'vote'. And a final transaction can be used to give the go/no-go decision.

With appropriate use of access control, and events together with some off-chain code I can see how this could be made to work.

Cross-chaincode calls

I don't think that cross-chaincode calls would be required to fulfill the requirement, but to briefly clarify.

Within a Single Smart Contract, any transaction function can call any other function as per regular programming. It's actions just become part of the same transaction.

Calling across Chaincode containers on the same channel - likewise the actions are merged into the same transaction.

Calling into a different channel is possible but only in a read-only manner.

Definitions

I use the term Smart Contract to refer to the implementation, the functions and classes that make up your code.

Chaincode being the container that runs the Smart Contract, and is the unit of deployment as far as the Peer is concerned.

Calanais
  • 1,541
  • 9
  • 10
  • Thanks Calanais. At the first bullet, you say "a timeout configured on the peer". Shouldn't the timeout be configured at the chaincode itself? Also, what concerns me more is that: say that the chaincode broadcasts a message that it's like "hey, vote!". Everyone knows that in the system, only members with the role "admin" can vote (this solves bullet number 2, doesn't it?). So, every admin of every org comes and votes - but where is the vote sent? I mean, how can the SDK return the votes to the function that emitted that event (and awaits for an answer)? – GeorgePal Mar 11 '21 at 18:29