"Dynamic" role token distribution (aka "Open Role") through Plutus script

[paluh]

Until we have something like entry deposit as a part of the language we should probably provide a standard solution for dynamic role distribution.

I propose to add to the Runtime a really simple Plutus script which performs few checks:

• It's own UTxO Value should contain only minAda and a single "role token" - (currencySymbol, role, value)
• Spending transaction should have an input with Marlowe UTxO which contains a corresponding thread token (currencySymbol, "", 1) in the Value.
• Transaction should consume Marlowe UTxO and the inputs list in the redeemer provided to Marlowe validator should have as a first input: IDeposit _ (Role partyRole) _ _ and partyRole == role.
• Can we skip checking currencySymbol in Marlowe context?

In other words we want to release the role token only when a transaction performs a deposit for that given role which will implement part of the AnonymousDeposit semantics mentioned above.
f
The above script is constant so it can be used by reference on the chain and it could be included as part of the Runtime toolkit.

Regarding the thread token we can consider few points:

• In a preliminary off-chain step we should verify that a thread token is not released during Marlowe contract execution and that it is an safe NFT.
• Burning the token at the end could be possible extension of the schema but we can make it optional.
  • A simple schema for pseudo burning is assigning the token to some unspendable address account { "address": "000000...00" }).
  • A possible more sophisticated schema of burning could be a dedicated constant script (so we put the token under it's address in the Marlowe account map) which enforces burning.

[paluh]

A complementary implementation to this proposal can be found here: https://github.com/input-output-hk/marlowe-cardano/tree/PLT-6793-Open-Roles

[bwbush]

which contains a corresponding thread token (currencySymbol, "", 1) in the Value

I don't think it's essential to use a blank token name for that thread token. It could be any name that does not appear in the contract itself.

[paluh]

I wanted to achieve less friction in the validator (which is constant) and in the tooling around (minting policy, thread token locking check etc.) by using this convention. Can we leave it for now?

[bwbush]

Can we skip checking currencySymbol in Marlowe context?

The Plutus script's check for the presence of the thread token is sufficient for security. Parties to the contract (or Marlowe Runtime's safety checks) need to verify that that the token is an NFT residing in the Marlowe contract of interest.

[paluh]

Yeah, I'm not sure why but this full equality check (we check role token really equals the one from the contract) gives me warm feeling. But maybe that is actually the problem - it is misleading because the currencySymbol has no guarantees behind it on its own.

[bwbush]

Right, it provides redundancy, but on-chain security could only be guaranteed by integrating minting into the Marlowe validator. @nau implemented a proof of principle of such a validator in PR#117.

[paluh]

Side note (we don't want to dive into this here): The main problem with the universal validator from my perspective was inability to have constant hash of the validator itself (we expected minting policy and spending validator to has the same unique hash: https://github.com/input-output-hk/marlowe-cardano/pull/117/files#diff-e96ad0912b23a6a2a412ad1447699ac9986a492161ee9a00e1407c01aadbc616R315) meaning usage of reference scripts would not be possible.

[bwbush]

In a preliminary off-chain step we should verify that a thread token is not released during Marlowe contract execution

Technically, we only need to ensure this if there are no more "dynamic roles" in the contract after the thread token would be released.

[bwbush]

A simple schema for pseudo burning is assigning the token to some unspendable address account { "address": "000000...00" }).

This wastes ada. No security considerations remain after the contract closes, so the disposition of this thread token is immaterial from that point of view. Mostly, it would be convenient to unmint it an any other role tokens that the parties don't want to keep for reuse or as souvenirs.

[paluh]

This wastes ada.

We should compare the cost of burning before we can clearly state this ;-)

No security considerations remain after the contract closes, so the disposition of this thread token is immaterial from that point of view.

From open role point of view maybe there are no other security considerations but from broader perspective having really unique thread token with burning guarantees can ensure no phishing like schemas on the chain (for example creating a clone thread after contract was closed etc.).

Mostly, it would be convenient to unmint it (..)

If we don't want to use unspendable address then we have to ensure burning. If we output the token to the (constant) burning enforcing script there won't be any incentive to perform the burning but maybe that is cleaner solution because at least it gives a choice to the user.
Unfortunately we are not able to tight easily the burning script output to a particular user - we could in theory use user address hash as a token name and then the script could use this schema for spending authorization but then it introduces a bit of a friction regarding the thread token name. What do you think?

the parties don't want to keep for reuse.

I would not call that token thread token in such a case.

[paluh]

@bwbush should we explore also possible controlled burning in this round - meaning:

• We can encode as the token name the address of a burner.
• We can assign the token to a burnAllValidator.
• burnAllValidator will be constant script with following logic:
  • expect only a single token beside minAda in the Value
  • use the token name as burnerAddressHash
  • check if the spending transaction is signed by the burner corresponding to the burnerAddressHash
  • check if the token is really burned by the tx

This schema will influence a bit our Open Role valiator because we have to pass the thread token name (which is hard coded to '' currently) through the datum.

[paluh]

@bwbush Should we extend the token release logic so it validates any Marlowe inputs as long as they have shape:

INotify* (IChoice by role token party | IDeposit by role token party) Input*

Meaning that we ignore drop INotify prefix (this can be performed by anybody) and then check if the first party input is either IDeposit performed by the party or IChoice performed by the party?

[bwbush]

In the long term, yes. In the short term, only if it doesn't overly complicate the implementation.

[paluh]

Actually we probably can even go one step further and require at least one input dedicated to the role at hand (be it IChoice or IDeposit). All the other inputs in any order are no our concern I would say but rather a concern of the Marlowe validator.

[paluh]

@bwbush I started to think that actually the currency of the thread token could be different than currency for the roles. The benefit of having different currency symbol for thread token is that it can be useful to carry proof about preconditions (using constant minting policy) and validator could enforce it's burning at the end - related comment: #708 (comment)