Reference inputs and reference scripts

[carlhammann]

This PR brings

A separation of output type interfaces

This was discussed in this thread. We now have a class IsAbstractOutput, and a constraint type IsOnchainOutput, which imposes restrictions on the type families in the IsAbstractOutput. I think it'd be worthwhile to (on one of the clean-up PRs to come in the next few days):

• Rethink the name of IsOnchainOutput, as it is more accurately described as capturing outputs that have a representation in terms of what scripts see on the TxInfo
• Maybe write a few more constraint types like IsOnChainOutput with useful names, for example:
  • For transaction outputs. This would clean up the constraint mess on TxSkelOut and would give us a nice place to write a comment on what is needed for transaction outputs and why (which I know now, but will not know in two weeks...).
  • ...

Reference inputs

There's now a field txSkelInsReference :: TxSkel -> Set Pl.TxOutRef on the TxSkel which behaves in the expected way.

Reference scripts

Reference scripts are used as demonstrated in their test module, but I'll still summarise how to use them here, because the subject is relatively subtle.

To use a script s as a reference script, you must

1. Create an output that contains the s. It's possible in principle for this output to belong to a script or a private key (there are tests for both), but I'm not sure what the difference in meaning is. For the latter case, here's a smart constructor for TxSkelOut. In any case, the output at which the script resides will have a TxOutRef, which we'll call o.
2. Spend an output belonging to s, while using TxSkelRedeemerForReferencedScript to provide the redeemer, and include o in the txSkelInsReference.
   • If you forget to include o on the transaction, you will get this error from transaction generation.
   • If you include o on the transaction and use TxSkelRedeemerForScript, you will get a phase 1 error from the ledger complaining that the script is included twice on the transaction.

Edit: What I think still needs to be done before merging

• [ ] I adapted the pretty printer to show reference scripts on transaction outputs and inputs. They're still missing on the UtxoState, though.
• [x] Is the design for reference scripts really what it should be? For example, if we had TxSkelRedeemerForReferencedScript :: TxOutRef -> a -> TxSkelRedeemer, where the TxOutRef is where the script sits, there's no option to forget it.
  • Edit: After dsicussing this idea with @florentc, I'm now of the opinion that, while it would be nice to have this safety built-in, it would also mean that there are two ways to specify reference inputs: In order to know what the transaction references, it would not be enough to just look at the txSkelInsReference. That would be against the design goal for the TxSkel to be as clear and non-redundant as possible. Also, since the error message about missing reference script inputs is written by us, it also mentions the likely fix ("...did you forget to reference the script...?").
• [x] The examples still need to be adapted. (done in afbbca6)
• [x] Outputs that contain reference scripts have to contain a certain minimum amount of Ada dependig on the size of the script. We should have the information to automatically set this value in the MockChain. Currently, I'm just guessing a big value.
  • Edit: Done in f03edb5. It turns out that outputs with reference scripts are not special in regard to their Ada requirement, as outlined by CIP 55; every output's minimum required Ada grows linearly with its size. I also wrote a test that the value we compute is in fact minimal.

[mmontin]

Before I dive a bit more into details, I have a few questions/remarks

• There should probably be a smart constructor for paying to scripts with a reference script
• I would rename txSkelInsReference into txSkelReferenceIns
• I'm concerned with the two types of redeemers with the same signature (depending if you attach a script as reference or not). Naively, I would have expected reference scripts to be declared when consuming utxos from script instead of providing the actual script as we used to. Something along the lines of Either TypedValidator a | ReferenceTo o. If I understand properly, the reference script should be part of one of the reference inputs instead, and a lookup into those occurs depending on which of these two redeemers is used. Couldn't we make reference to this output directly in our data types (in addition to it being part of the reference inputs which, I assume, is required later on in the validation process).
• What if the reference script is part of the inputs that are actually consumed?

[carlhammann]

I think this is in a mergeable state now. The one point that's missing about the pretty-printing business will come on a separate PR.