Observer/controller behaviour in Canton

Questions
1

Hi team,

I’d like to explore the behaviour of observer/controller in a canton setup. Say two participant nodes (p1 and p2), and Alice is allocated on p1, and Bob on p2.

In this sample template,

type AssetId = ContractId Asset

template Asset
  with
    issuer : Party
    owner  : Party
    name   : Text
  where
    ensure name /= ""
    signatory issuer
    controller owner can
      Give : AssetId
        with
          newOwner : Party
        do
          create this with
            owner = newOwner

(1) When Alice creates Asset and Bob is the owner, my understanding is that this contract creation does not require p2’s confirmation before an active contract is created in p1. I tested this by turning down p2 and the active contract is still created in p1. After p2 resumes, the active contract is now seen in p2. Please confirm if that is the case.

(2) When p2 is back to service, is the domain (sequencer) the component sending back the commit? Will it keep this commit until p2 is back, or any mechanism that this commit to p2 will finally drop in the sequencer?

Many thanks.

2

(1) Yes, that’s correct. Observers of a contract don’t have to confirm the creation (unless they are also signatories of the contract).

(2) The domain will retain commits for offline participants until the domain operator prunes the domain state, using the enterprise version of the Canton domain. Thereafter the participant will not be able to see the commit (and should refuse to connect to the domain in the first place).

1 Like
3

Thanks @Andreas_Lochbihler for your prompt reply!

cheers,
kc

4

Apologies for adding to a solved question (for the sake of preserving the context).

The docs) state that “[…]based on the check’s result, a subset of recipients, called confirmers then prepares a (positive or negative) confirmation response for each view separately. A confirmation policy associated with the request specifies which participants are confirmers, given the transaction’s informees. [… ] the mediator derives which (positive) confirmation responses are necessary in order to decide the confirmation request as approved”. Basically, the mediator may have not received any response from p2, but given that it received the list of informees from the sequencer beforehand it can decide which view needs confirmation and which doesn’t. But in order to do that it would need to know which informee recipients are signatories and which are not for each view - so I guess the conclusion is that domains know more that just the flat list of recipients/informees, but also which informee is a “confirmer” (that seems to be implied by the “Flexible confirmation policies” paragraph). Does it mean the mediator can infer signatories / actors (which are the likely confirmers) of a view? Thank you!