-
Notifications
You must be signed in to change notification settings - Fork 724
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
CLI Alonzo script support #2774
Conversation
Instead of using a Map PolicyId (Witness WitCtxMint era) we instead use Map PolicyId (ScriptWitness WitCtxMint era) Whereas other uses of witnesses in the tx body allow either key or script witnesses, the minting only uses script witnesses, not key witnesses. Using the more specific type is logically the right thing to do, and will also make the job for the cli slightly easier.
Make it simpler and clearer. Check both for too few as well as too many witnesses being provided for minting. Alsoange it to use the existing createScriptWitness utility. This will mean we can extend it for Plutus scripts more easily, since we will only have to change that utility function, and not validateTxMintValue.
To be able to support plutus scripts for witnesses, we need to deal with script witnesses rather than just scripts. In the CLI this means dealing with the files needed to make a script witness, rather than just the single file needed to make a simple script witness. So we add a new ScriptWitnessFiles GADT that covers both the simple and the plutus witness case, that contains the various files: not just the script file but also files for the datum and redeemer, and also the exection units. This patch does not actually add in the cases to actually support the plutus case, it just switches the types over in preparation. Both the parser and the createScriptWitness helper will need to be extended for that.
ca82881
to
7d6e8a6
Compare
The remaining TODO here relies on the ScriptData JSON support.
This also relies on the JSON instance for ScriptData, which is not included yet.
And also as concrete data files in the repo. These scripts always succeed, or always fail, so are only useful for quick sanity tests.
It'll be getting larger once we add JSON serialisation.
Following the style of the TxMetadata
Relying on the new JSON support.
Supporting the simple schema-less JSON representation of script data.
6797995
to
738f311
Compare
Collateral inouts are needed for every tx that uses Plutus scripts.
It was inverted. Oops. Now we correctly reject txs that do not specify protocol params. Unfortunately, the cli for providing them is not wired up yet, so not yet possible to make a proper Alonzo tx.
Transaction that use Plutus scripts have to provide collateral inputs.
The current state here is that we cannot yet construct valid Alonzo era txs. The next bit to make that work is to be able to provide the current protocol parameters to the In the CLI code we have these TODOs:
It's the 3rd one there that's critical. That's the protocol params. The others are non-critical features. |
One of the necessary pieces for making valid Alonzo era txs. Not yet tested.
Ok, with any luck that'll now work. Needs to be tested. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't tested this as yet but it LGTM
@@ -1028,7 +1028,8 @@ data TxMintValue build era where | |||
|
|||
TxMintValue :: MultiAssetSupportedInEra era | |||
-> Value | |||
-> BuildTxWith build (Map PolicyId (Witness WitCtxMint era)) | |||
-> BuildTxWith build |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💯
-- | ||
-- It is era-independent, but witness context-dependent. | ||
-- | ||
data ScriptWitnessFiles witctx where |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thoughts on having this in the API in some kind of IO module?
-> ExceptT ShelleyTxCmdError IO (ScriptDatum witctx) | ||
readScriptDatumOrFile (ScriptDatumOrFileForTxIn df) = ScriptDatumForTxIn <$> | ||
readScriptDataOrFile df | ||
readScriptDatumOrFile NoScriptDatumOrFileForMint = pure NoScriptDatumForMint |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Technically, nothing is stopping us from supplying a Datum with a plutus script involved in minting or withdrawals right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The consistent use of the witctx type argument should ensure that we're using only the right one in the right context. So it should be impossible to supply a datum for minting or stake contexts. For starters, there's no cli flag for it: we only have the datum cli flag for the txin context.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant from the perspective of the ledger. The ledger doesn't care if we supply a datum when using a minting or stake script. IIRC Lars was utilizing tx datums in minting scrips in the plutus pioneers course.
{-# LANGUAGE ScopedTypeVariables #-} | ||
{-# LANGUAGE TypeFamilies #-} | ||
|
||
module Cardano.Api.ScriptData ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
The API's TxBody binary format is not an externally defined format. It does not appear on the chain. It is an intermediate format used by the cli and is not guaranteed to be stable or interoperable. External tools should not rely on this format. Nevertheless, for now since it's easy, we'll adjust the output to be the same as pre-Alonzo eras when not using any Alonzo-era features.
bors merge |
Build succeeded: |
No description provided.