Closed carlhammann closed 1 year ago
A straightforward low-effort solution to distinguish at the type level "resolved" vs "unresolved (but maybe resolvable)" would be to introduce a CookedSpOut
, counterpart of SpendableOut
type that mirrors Pl.ChainIndexTxOut
apart from the Either datumHah datum
which would be datum
.
The current functions that resolve the datum in a BlockChain
would have types like spOutResolveDatum :: MonadBlockChain m => SpendableOut -> m CookedSpOut
, or spOutsFromCardanoTx :: MonadBlockChain m => Pl.CardanoTx -> m [CookedSpOut]
. The SpendsScript
constraint would require a CookedSpOut
. This would bring some more type safety although this does not answer all the items.
I like that idea, but I'd like something like TypedSpOut a
. Are there any cases where, with normal use of cooked, we know that there is a datum, but don't know its type?
When validating a transaction that issues new outputs, the returned transactions CardanoTx
from which we can later get the corresponding SpendableOut
s do not contain type information anymore about the datum.
It should be possible to retrieve the info if we know which PaysScript
led to these different outputs.
I wonder how such an API could look like. But I think there would be a lot of actually unsafe stuff inside the black box if we were to implement it.
A 'SpendableOut' contains a 'ScriptChainIndexTxOut' which can either contain a
Left datumhash
or aRight datum
. In many cases, thedatumHash
will be resolvable into adatum
if, we're in the context of aMonadMockChain
. The question is how/if we should distinguish 'SpendableOut's thatdatum
of a known type,datum
of unknown type,datumHash
, ordatumHash
on the type level, and how we should make these distinctions in a systematic way.