FinalityFlow behavior when a participant’s node is in Draining Mode

1
votes

Network:

  • PartyA, PartyB, PartyC, Notary

Scenario:

  • PartyB’s node is put into draining mode.

  • PartyA performs a transaction where PartyB and PartyC are participants (not signers)

Outcome:

  • PartyA completes the transaction, gets the notary’s signature and saves the state in its vault.
  • PartyB will not be informed of transaction (expected)
  • PartyC will not be informed of the transaction (surprise!)

Learning:

I assume because PartyC is listed after PartyB in getParticipants() it has to wait until PartyB is back online before it will receive the transaction. This is unfortunate because PartyC gets punished because PartyB’s node is down.

Question:

Is this just a limitation of the open source version of Corda? Would Corda Enterprise behave the same way?

Thoughts:

It may be necessary to clearly inform the users of your CorDapp about this phenomenon because it creates a condition of asymmetric information that is caused by some other node on the network.

1
corda

1 Answers

1
votes

It is a limitation of Corda Open Source. The FinalityFlow of Corda Enterprise (up until 4.x) sends the transaction - after notarisation - to all the peers and resolution is performed in parallel for increased performance. In Corda Open Source it is done in sequence.