Closed carlhammann closed 1 year ago
Before I dive a bit more into details, I have a few questions/remarks
txSkelInsReference
into txSkelReferenceIns
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).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.
This PR brings
A separation of output type interfaces
This was discussed in this thread. We now have a class
IsAbstractOutput
, and a constraint typeIsOnchainOutput
, which imposes restrictions on the type families in theIsAbstractOutput
. I think it'd be worthwhile to (on one of the clean-up PRs to come in the next few days):IsOnchainOutput
, as it is more accurately described as capturing outputs that have a representation in terms of what scripts see on theTxInfo
IsOnChainOutput
with useful names, for example: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 theTxSkel
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 musts
. 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 forTxSkelOut
. In any case, the output at which the script resides will have aTxOutRef
, which we'll callo
.s
, while usingTxSkelRedeemerForReferencedScript
to provide the redeemer, and includeo
in thetxSkelInsReference
.o
on the transaction, you will get this error from transaction generation.o
on the transaction and useTxSkelRedeemerForScript
, 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
UtxoState
, though.TxSkelRedeemerForReferencedScript :: TxOutRef -> a -> TxSkelRedeemer
, where theTxOutRef
is where the script sits, there's no option to forget it.txSkelInsReference
. That would be against the design goal for theTxSkel
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...?").