Canton VIP confirmation policy

Questions
1

Hi team,

I am looking for detailed documentation regarding the VIP confirmation policy in Canton. Can you please share me more info on how it works and can be config?

Also, would the VIP confirmation policy be the solution for below statement(from canton whitepaper)?

Domains can also appoint trusted
entities that users can selectively involve to help process their workflows even
if some of the involved parties are unresponsive.

thanks,
Dorrit

2

Hi Dorrit,

Yes, this is correct. Generally, there is a trust vs availability trade-off. Every distributed system has that and you can’t discuss it away. Everything that you can do is to make it configurable so it can be configured on a case by case basis. The VIP confirmation policy allows to move the trade off towards more trust instead of less availability.

A Canton ledger is a stakeholder based ledger, where normally the signatories of the contracts are asked to confirm the transactions. The confirmation itself is deterministic. The signatories must come to the same conclusion or some confirmer is broken or malicious.

The VIP confirmation policy now allows to change this such that either all signatories confirm the transaction, or at least one VIP participant confirms it. Once the confirmation is done, the transaction becomes final.

However, the equivalent behaviour can be obtained by pulling this trust question into the Daml workflows via signatory / observer:

template Foo
   ...
where 
  signatory vip
  observer others

This is then really explicit: The observers can observe the signatory vip progress the contract and they can call out if vip is cheating, however, they can not reject the transaction.

Therefore, in my opinion, it’s better to be explicit within a Daml model on what is really going on with respect to the Daml contracts and the relationships between the parties, rather than to declare everyone a signatory and then make them effectively observers on the synchronisation layer by marking a particular party as being a VIP.

Therefore, my opinion is: just keep the “TrustLevel” as Ordinary and really model the relationships between entities in your Daml model.

As a final example: assume you have a CSD that manages equity. If that CSD retains the right to revoke an asset unilaterally in order to correct holdings, then don’t make the owner of the asset a signatory. If a party must have the ability to unilaterally effect changes, then the other party is in fact only an observer of the contract, where the observer can still hold contractually agreed rights on that contract.

I hope this helps to shed some light on the design space. There is no simple answer.

Cheers,
Ratko

3

So, my comment here sparked a discussion with @bernhard which I’ll summarise here for reference.

The disadvantage of my suggestion is that it weakens the authorization logic and guarantees in Daml due to the fact that e.g. the signatory can just do bare creates of such contracts.

However, the core issue seems to be that signatory and observer are not well aligned with the guarantees and properties that can be provided within a Canton style synchronisation layer.

An alignment could be replacing signatory with explicit authorizers (for Daml semantics) and validators (for synchronisation …)

template Foo
  with
    bernhard : Party
    ratko : Party
  where
    authorizer [bernhard, ratko]
    validator ratko

But that’s something for later. Until then, I recommend:

  • Be considerate of the implication of making a party a signatory in a contract in terms of availability.
  • Use VIP participants in the few cases where you have a very asymmetric relationship between the parties and where you want to use the higher trust in one participant to get higher availability.
1 Like