Can Canton Coin committed allocations settlements be blocked by misbehaving owners?

Continuing the discussion from Impact of package unvetting by observers on usability of existing contracts:

Hi, I found this while looking at Canton Coin allocations.

From my understanding, committed allocations on Token Standard V2 are not safe against the case described here: “if you turn off a signatory participant that then just refuses to participate in the transaction confirmation process”. The owner can’t withdraw a committed allocation, but settlement still archives or creates contracts the owner signs (the allocation, the `LockedAmulet` and the payout `Amulet`), so the owner’s node can block settlement just by staying silent until the deadline.

Could a model where the owner is only an observer of these contracts, since the DSO is already trusted for the custody of the asset, fix it, or would it conflict with something else ?

There is also this problem: “If a participant forcefully unvets a package, the contract is blocked. Same happens if a participant removes a party.”

From my understanding, the protocol checks, at the moment a transaction is submitted, if the participant node of the observer party has vetted that package. I’m assuming the main reason for this check is that an observer’s node needs the package to process the transaction, and, besides being a security measure, vetting informs other nodes that this node has this package. Otherwise, the observer party can’t correctly perform the “role” of observer, maybe there is another reason I’m not aware of.

The protocol gets this guarantee but allows the observers to block transactions that do not require their confirmation.

I suspect we could get the same guarantee if instead of requiring the participant nodes of the observers to have vetted the package at the time the transaction is submitted, require only that they vetted it when the contract was created, and not require the observer to still be hosted somewhere. This protects against an observer that later unvets the package or removes its party to block transactions that don’t need its confirmation. Since it vetted it when the contract was created, the participant node has shown that it can process the transaction. Contracts created by a choice that archives a contract the observer already sees, with the same package (like the payout created when the allocation is settled), would be treated the same way. Unvetting would still stop the observer from being added to new contracts.

Could something like this work ?

@Nunobrazzz : your observations are correct. The dependency on observer package vetting is a known problem, and I expect it will be removed in the future. One of the big obstacles for doing so is actively being worked on: making it safe (wrt resource consumption) for a participant node to execute arbitrary Daml code. If we combine that with shipping packages on-ledger, then participant nodes can in principle always execute the Daml code required to process an observed contract.

Combining that then with some adjustments to the underlying Daml code should allow closing the gap you pointed out.

Independently, I recommend app authors that use committed allocations to defend against such misbehavior using economic incentives: for example, organizing the apps workflows such that misbehaving users (vetting or hosted on a non-confirming node) are quickly excluded from the workflows of the apps. This way the user carries the damage: their CC remains locked; and the app stalls only for a short period of time when it encounters a misbehaving user.

If you combine this exclusion with a minimum amount for an allocation to even be considered in the apps workflows, then I’d expect the incentive for users to do this kind of protocol-level-blocking to vanish.

@Simon_Meier
Thank you for the answer.

So the plan is to remove the need for observers to vet packages entirely, by making execution always safe? I see the advantage over what I proposed, it protects against a node that regretted vetting a package. Is there a timeline, or some resource I could follow on this ?

Do you have thoughts on making the owner an observer instead of a signatory on holdings, so that the owner isn’t a confirmer during settlement ?

Nunobrazzz:

So the plan is to remove the need for observers to vet packages entirely, by making execution always safe? I see the advantage over what I proposed, it protects against a node that regretted vetting a package. Is there a timeline, or some resource I could follow on this ?

Once the Canton repo is fully open-source (~ Q1 next year) you should be able to follow the active work on tracking the interpretation cost of Daml code execution in the Daml engine.

I also expect to publish a proposal for a north star design for how package vetting could work in a similar time frame in the forum here and on https://lists.sync.global/g/cip-discuss/topics

Nunobrazzz:

Do you have thoughts on making the owner an observer instead of a signatory on holdings, so that the owner isn’t a confirmer during settlement ?

That very much depends on the trust model; and on the perception of this design choice by token holders. I don’t think there’s a generic answer to it.