Closed carlhammann closed 2 months ago
As this turns out to be hairier than expected, I decided to separate individually valuable contributions out to separate PRs #250 and #251.
Now that https://github.com/tweag/cooked-validators/pull/311 has been merged, you will have a hairy conflict with main
to resolve... Apart from that, what is the status of this PR? It hasn't moved in a month.
what is the status of this PR?
The status is that we decided to not have the (surprisingly hairy) Contract
instance as a part of the v2.0.0 release, and focus our energies on something else. I think this specific PR will never be merged, but I want to keep it around as reference for when we finally decide to bite the bullet an implement the instance.
In particular, the three (merged) PRs #252, #250, and #251 were all derived from work done here first. So, I think this has already served as a good exploration vessel.
I am closing this one because it is outdated, and it is very unlikely that we will need a Contract instance for MonadBlockChain
in the future. If we do for future reasons, we will take inspiration from this one.
This PR implements the
MonadBlockChain
instance for the plutus-appsContract
monad. As this necessitated an update to the plutus-apps version we depend on, it might be worthwhile to look at this PR in two diffs:Merging this PR will close #129 and close #78. Here are the main changes:
The same balancing for both monads
In order to close #129, I decided to factor out the common steps of balancing the
TxSkel
and generating a balancedTx BabbageEra
into a new moduleCooked.MockChain.Balancing
, which is used by both for theMonadBlockChain
instance of our own direct implementation and for theContract
monad. You will see that the size ofCooked.MockChain.Direct
decreased drastically as a consequence and that the implementation ofvalidateTxSkel
is now very concise (as it also is for theContract
monad).Changed primitives in
MonadBlockChain
In order to implement balancing for both monads, I decided to introduce another class below
MonadBlockChainWithoutValidation
, calledMonadBlockChainBalancing
that has a minimal set of primitives needed for balancing.I also decided to change the type of the primitives that return a
TxOut
so that they return aLedger.TxOut
, and not aTxInfo
-TxOut
. The latter can always be obtained from the former, but not vice versa. This means thatallUtxos
and friends are now not primitives any more, but defined in terms of primitives. See Issue #239 for some further improvements I think are necessary in this area.Open questions / What's left to do
Contract
monad? If yes, I'd like to pair on that.validateTxSkel
implementation of theContract
monad, which allow the application ofRawModTx
.RawModTx
at transaction generation time, because it is a genuine part of theTxSkel
, and not the task of either monad to explicitly remember applying it.MonadError
/MonadFail
situation.MonadBlockChain
being aMonadFail
quite heavily: Out usual style of writing offchain code is full of incomplete pattern matches that we know will never fail.MonadError
is also useful.MonadFail
andMonadError
instances for theContract
monad feel like hacks, and they are, becauseContract
is not aMonadFail
natively.Contract
monad has no facility to list all known UTxOs, as the functions aroundallUtxos
do. It's only possible to return all UTxOs belonging to a specific address. This is now a primitiveutxosAtLedger
. TheContract
instance throws an error if one tries to retrieve all UTxOs. Is this a good solution, or should we abandonallUtxos
or move it to a separate class?