Using the standard confirmation policy an exercise on a contract must be confirmed by the signatories and the actors and only those. In particular, an observer does not need to confirm the transaction (unless they’re also the actor).
However, for the transaction to go through afaik all informees which includes the observers must have vetted that package.
Now that is a very reasonable constraint initially, I cannot make a party an observer if they have not vetted the package. The part I’m unsure about is package unvetting.
If an observer (forcefully) unvets a package and there are already existing contracts that use that package, does that make the contract unusable so even observers can block transactions? Or is there some mechanism I am missing that would prevent that from being a problem?
1 Like
To the best of my knowledge, Canton does not let you unvet a package that is in use - ie for which there are active contracts.
But I don’t know at what level that is currently enforced. Ie I don’t know to what extent you could manipulate your node to circumvent that check.
1 Like
The docs specifically contain a section on force unvetting so you don’t even have to manipulate your node to do that afaict. And that seems somewhat unavoidable. Vetting is a topology transaction, I don’t see how you could make that fail depending on whether there are active contracts or not. Of course you can have a local check but that does not help against an observer that wants to block me deliberately.
1 Like
Yes, this is correct. If a participant forcefully unvets a package, the contract is blocked. Same happens if a participant removes a party. In such a case, the contract is blocked too. You also get into similar problems if you turn off a signatory participant that then just refuses to participate in the transaction confirmation process. Similarly, by just revoking the participants signing or encryption keys, you can block contracts too.
On the administrative level, the commands prevent you from doing that. However, principally, this is possible.
However, contracts are generally a “bilateral thing”. Therefore the impact is that one side can unilaterally refuse to continue business with the other side. This is exactly what can happen in the real world too where one company just refuses to accept your orders after you misbehaved.
You can avoid this by centralising the authority over the topology state of the domain such that not the participants individually decide on what packages they vet or which parties they host, but they subordinate themselves to that central authority.
It’s again the classic trade-off between trust, privacy and availability. Canton is flexible in that respect (topology management / confirmation policies). The standard setups / deployments are leaning more towards decentrialization & privacy.
1 Like