-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Contract instance #243
base: main
Are you sure you want to change the base?
Contract instance #243
Conversation
Now that #311 has been merged, you will have a hairy conflict with |
The status is that we decided to not have the (surprisingly hairy) |
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.validateTx
for the contract monad, making it more flexible #78. This amounts to adding one or two lines to thevalidateTxSkel
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?