Can each Corda DLT member have their own CorDapp to manage shared states?

Question

At my organization, we are exploring Corda deployments. One question came up was - Should we develop own custom CorDapp or is it something that should be common and identical across the parties that share the same state, atleast partially?

For example, in ethereum case, we knew that the smart contract code is an identical copy on each node. Is this true for Corda as well? If this is not true, which parts of the CorDapp (flows, states, contracts etc) need to be same across the members and which ones can be customized or developed by each member?

Answer 1

• Usually a CorDapp is split into 2 module:

  1. Contracts CorDapp which has the state and its contract
  2. Workflows CorDapp which has the flows
• All nodes that transact with a certain state, must have the contracts CorDapp installed.
• The contracts CorDapp is usually developed by one entity, which signs the CorDapp and distributes it to other nodes (read here why you need to sign your CorDapp).
• This way the contracts CorDapp is identical between all node, and that insures that all of them will run the same contract when they resolve or finalize a transaction that has that state.
• Contracts must be deterministic, meaning for the same transaction they should always return the same result (i.e. transaction passed verification or not) regardless on which node that contract runs; that's why you can't access external resources (e.g. node's database), use dates, or random number generators in your contract, because that will lead to different results on different nodes.
• Corda 4.4 now has a deterministic JVM that protects you from making the mistake of using non-deterministic code in your contract. See here.
• In summary for the above, contracts CorDapp should be identical between all nodes that use a certain state.
• As for workflows CorDapp, each node can have its own; specifically regarding the responder flow; implementing the responder flow is typically the responsibility of the responding node.
• For example, let's take the IOU CorDapp; you will see that to issue an IOU there's an initiator.
• The initiator will verify the transaction (i.e. run the contract) before signing it and sending it to other parties.
• Even if the initiator omitted verifying the transaction, when a responder receives a transaction to sign it or finalize it; it is implicitly verified, so the responder won't sign or finalize a transaction that doesn't meet the criteria that all nodes agreed on (i.e. the contract).
• You will notice that in the IOU example, the initiator sends the transaction to one party which inside the responder flow validates that transaction before signing it (see here). So if the initiator was sending the transaction to multiple parties; each party can implement its own responder (so one party might accept only IOU's that are less than 100, another will accept IOU's that are only less than 500, and so on).
• So to summarize, nodes can implement their own workflow CorDapps so they can have their own validation rules; but regardless of the workflows CorDapps, all nodes must have the same Contracts CorDapp.