Marlowe proof token for preconditions

[paluh]

Note:

This proposal differs from #638 because we propose a Validator level only token with richer semantics. On the other hand it replaces the other proposal.

Objectives:

• We would like to avoid precondition checking at every step through the Marlowe execution.

• We would like to reject the tx on the validator level if preconditions are invalid.

Proof minting policy

• Minting policy would be constant and its hash would be known to the Marlowe validator.

• Minting policy is not able to know the Marlowe validator hash because then we have circular dependency between hashes.

• Minting policy would accepts as a redeemer hash of the Marlowe validator.

• Proof tokens will be minted only for starting Marlowe threads - outputs without corresponding Marlowe input. We identify Marlowe thread by thread token of that exact policy.

• Minting policy would check the state invariants (no duplicates, possitive accounts etc.) in a given Marlowe output (or maybe even role minting: Simple minting policy which introduces secure thread token #638 (comment))

Naming the token

• Minting policy is "open" - meaning we are not able to control it's usage to only "proper" marlowe - a malicious actor can provide "forged" marlowe validator which leaks the token.

• Because of the above we are not able to trust the tokens of the policy in general - some of them could be "stolen" by the above and be proofs for some external unrelated marlowe state.

• On the other hand we can trust ourselves meaning we know that Marlowe validator will never leak the proof token.

• If the policy set's the name for the token to the hash of the Marlowe validator for which the preconditions were minted then we can be sure that token with a name of the Marlowe validator hash would never leak and is always part of the correct Marlowe execution.

• Unfortunately such a token name won't be unique and will be shared by many Marlowe threads with the same validator.

• We have to embed uniqueness into the token name by for example using sha_256((Marlowe txOutRef, Marlowe validator hash).

• To verify the proof Marlowe has to receive or keep in the datum its own initial txOutRef (in the Runtime we call it ContractId). Then to verify the preconditions it has to check if token of known currency with token name of sha_256(Marlowe txOutRef, ownHash) is part of the Value.

Implementation

• Let's keep thread token outside of the accounts and remove it from the check against totalBalance of the accounts.

• We should add check for the presence of the token.

• We should add check for the preservation of the token.

• We have to add additional check which enforces burning at the end of the contract.

[paluh]

This proposal is more generic and closely related to the validator itself and not to the Runtime per se. @bwbush could you please tell me if I move this under MIPs repo?