Question about exercising a choice with parties on different nodes

Questions
,
1

G-d willing

Hello,
Let’s say I have a contract with 2 parties on it acting as signatories.
Each party is from a different participant node.
When a consuming choice on that contract is exercised, is the calculation of exercising the choice being done on both of the nodes? Or does it happen only on the party’s node that is exercising the choice?

Thanks,

2

The transaction is first interpreted by the participant node, where the transaction was submitted. If it is rejected by this Participant Node, that’s the end of the story. If the transaction passes interpretation, then it is sent to the Sequencer that forwards the transaction to all Participant Nodes hosting the parties that must verify the transaction (or a subtransaction they’re privy to) and to the Participant Nodes hosting the parties witnessing the transaction (or a subtransaction they’re privy to). The Participant Nodes hosting the parties that need to verify the transaction will interpret it separately for each verifying party.
In your example, unless the transaction is rejected by the Participant Node where the transaction was submitted, it will be interpreted by at least two Participant Nodes that host the signatories, and maybe by another Participant Node hosting the controller of the choice, if the choice controller is not one of the signatories.

1 Like
3

G-d willing

Thanks, @a_putkov for your answer.
So, I have another question… is everything that happens on all participant nodes considered one big atomic transaction?
If not, what happens if the result on one participant node is not the same as the first one?

4

is everything that happens on all participant nodes considered one big atomic transaction?

Correct. The transaction is only committed once it has been validated by all confirming participant nodes.
For the sake of completeness I should mention that Canton has configurable transaction confirmation policy. The default policy requires that a transaction is confirmed by all signatories and actors. Another option is that a transaction only needs to be confirmed by a trusted VIP party. And finally there’s an option, where transaction needs to be confirmed by all informees.
For more details see Transaction Processing in Canton.

2 Likes
5

G-d willing

Again, thank you @a_putkov for your answer.
I have 2 questions for you about this:

  1. If I configure the transaction confirmation policy to use only a trusted VIP party, how does that affect the performance of completing the transaction? For the sake of this question, let’s say that the contract has 5 participants (mixed by signatories & observers), and I exercised a consuming choice.
    Does it mean that the transaction will get validated on only the VIP’s participant node, and then the consequences of the exercise will get copied to the other nodes?
  2. What is the difference between the first option to the third option? What is the difference between the signatories and actors to informees?

Thanks,

6
  1. Correct. After the transaction has been interpreted by the submitting participant node, it will only need to be confirmed by the VIP participant. Note that VIP confirmation policy is only applicable to the transactions, where the VIP party is an informee on every action.
  2. Informees are the parties that are informed of an action. For a choice exercise informees include choice observers and in case of a consuming choice also contract observers in addition to signatories and actors.
7

Hey!
Small note related to the VIP confirmation policy: it will be removed in the next major version of Daml.
Best,
Rafael

8

@Rafael_Guglielmetti thank you for your answer.
Why is it being removed? It could be a good way to improve performance?

9

Hi @cohen.avraham , especially in a multi-domain environment, we would like the trust, security, and availability properties of a contract to depend largely on the smart contract design, not on sync domain parameters like the confirmation policy. Writing signatory alice, bob in Daml is misleading if the sync domain happens to have alice as a VIP.

There are legitimate use-cases where you really do want all trust and availability guarantees to be anchored in an application provider. But in those cases, I’d recommend making that explicit in the smart contracts by setting the application provider as the only signatory everywhere, and other parties only as observers and controllers.

An additional property that was possible to achieve with with the VIP confirmation policy was that a contract was available as long as at least one of several VIPs was available. We’ll bring that ability back with “consortium parties” in Daml 3 where you’ll be able to create a Daml party with a “n of m” confirmation policy amongst multiple participants. Setting such a party with a 1-of-m policy as the only signatory of a contract then gets you back to a VIP-like model in a cleaner way.

2 Likes