Unaudited Marlowe Validator - mainly optimization focused changes

[paluh]

Let's discuss here all possible changes to the validator which verifiably increase the performance. We should also discuss here possible removal of unnecessary checks which we have in the validator code as well here.
The final result of this discussion could be an extra version of the validator which we can include as a part of the official Runtime which is more flexible and performant but only internally and community audited. Every change/difference in this non audited validator should be clearly motivated and documented.
Guys do you think that we can create accompanying wiki page which we edit as we go?

[paluh]

AssocMap optimizations

I spotted that PlutusTx.AssocMap.insert is implemented really inefficiently - changing it to a trivial custom insertIntoMap in our semantics part of the validator increased performance in a few my test scenarios by 2-3% of max mem limit.
We can also think about replacing PlutusTx.AssocMap with some SortedMap. I know that @bwbush experimented with that and Ord was pretty costly - maybe we should check hand written Ord instances or even avoiding type class and passing the compare for a given type manually.

[paluh]

Refactoring of state checking

In the current version of the validator we perform somewhat costly checks of the state - checkState.

I have few observations and proposals which I would like to discuss:

• We assume that our semantics is correct.

• Given correct input state semantics should produce correct output state (no duplicates etc).

• Given the two points above we can skip post condition checking of the state.

• We could skip the precondition checking which is performed at every step if we can be sure that the initial state was correct - by implication all the folloing should be correct.

• We could perform initial state checking during the contract creation with constant "proof minting" policy - more details can be found here: Marlowe proof token for preconditions #714

[paluh]

Whitelisting allowed scripts

In the context of OpenRole work it would be good to have a way to provide whitelist of scripts which are allowed to run together with Marlowe without any restriction. The whitelist could be part of the datum. This would allow us in the context of open roles to deposit and payout at the same time (to achieve efficient swap scenario).

[paluh]

Role based withdrawal in Marlowe Validator

This actually would impact the validator negatively but it could be nice to measure the impact. When validators checks payouts and a given payout to role is missing we could perform extra checking:

• Check if role token is present.

• Check if there is UTxO with datum containing usual payout datum (role, currencySymbol) but dedicated to other address.

We use datum encoding to simplify the identification of the payout.

This change would help to reduce number of transactions in many simple scenarios (like swap ;-)).

[bwbush]

Also, we can incorporate IntersectMBO/plutus#5509 and IntersectMBO/plutus#5512 into the production version of the validator.

[paluh]

Optimization of the payout validator

The Marlowe Runtime gives us ability to perform withdrawal across multiple contracts so maybe we should try to optimize the payout validator. We can minimize decoding of the ScriptContext overhead because we need a small part of it (we can even decode inputs as we "go") - we can follow the approach from OpenRole script: https://github.com/input-output-hk/marlowe-plutus/blob/main/marlowe-plutus/src/Language/Marlowe/Plutus.hs#L506
The script is so simple that we can also do an Aiken experiment ;-)