Mismatch between `SpendsScript` and `PaysScript` constraints and the data we store in `MockChainSt`

[carlhammann]

The SpendsScript and PaysScript constraints both have as their first argument a TypedValidator. There are different reason for the presence of that argument in the two cases:

• On the SpendsScript constraint, we need to know the spending script, because it is involved in the validation of the transaction.
• For the PaysScript constraint, the recipient script itself is not involved in transaction validation. The address would suffice. However, the constraint still takes a TypedValidator argument, for reasons of type safety: It makes sure that we'll always create outputs with the correct datum type for the given script.

On the other side, the information we store in MockChainSt only contains a mappings between addresses to the UTxOs they own (which we can access using functions like utxosSuchThisAndThat, for example). This means that the information we can extract from the current state of the MockChain is not enough to construct a PaysScript or SpendsScript constraint; any application (say, when formulating a double satisfaction attack) that wants to look at the state of the MockChain and generate a transaction involving such constraints will need extra information, which might be hard to come by.

There are two obvious solutions:

• Add a mechanism to retreive a script from its address to the MockChain. We already have similar solutions for resolving datums and their prettty-printed representations from their hashes.
• Make the MockChainSt store a direct mapping from scripts to their UTxOs. The current design relies on the UtxoIndex type from plutus-apps to provide the mapping from addresses to UTxOs. This would probably make the MockChainSt conceptually easier, but require a lot of "translation" functions in the direct implementation using the API provided by plutus-apps.

[carlhammann]

Concerning the first option I proposed above: The Contract monad already has functionalities like this, which means that we could even make them a feature of MonadBlockChain.