CIP-0069 | add Datum to ScriptContext

[zliu41]

Closes #769

cc @michaelpj @lehins @MicroProofs @rphair @KtorZ @zygomeb @L-as

[rphair]

@zliu41 we're reviewing some related & alternative proposals at the next CIP meeting (https://hackmd.io/@cip-editors/84) and expect good Plutus representation there, so I've added this to the agenda. Would be nice if you could make it to that meeting. 🤓

[MicroProofs]

I am in support of this alternative over my own PR.

[MicroProofs]

Should this be Maybe Datum instead of Datum? Or is this a Datum field containing
Datum Hash, InlineDatum, No Datum?

[michaelpj]

I was thinking of a different variant, something like this:

• All scripts have the signature EvaluationInfo -> TxInfo -> ()
• ScriptPurpose as used elsewhere is left untouched (the ledger uses the "purpose" terminology so I think we should keep it)
• The type EvaluationInfo is defined similarly to ScriptPurpose, as follows:

data EvaluationInfo
  = Minting CurrencySymbol Redeemer
  | Spending TxOutRef Redeemer Datum
  | Rewarding Credential Redeemer
  | Certifying Integer TxCert Redeemer
  | Voting Voter Redeemer
  | Proposing Integer ProposalProcedure Redeemer

("Evaluation" info since it contains information about the specific evaluation of a script that is occurring, since a given script can be evaluated multiple times in multiple ways. Could have a better name)

[zliu41]

All scripts have the signature EvaluationInfo -> TxInfo -> ()

The problem with this naming is that TxInfo is also the info you need for evaluating a script, i.e., "evaluation info". I think I like "redeemer" and "script context" better.

ScriptPurpose as used elsewhere is left untouched (the ledger uses the "purpose" terminology so I think we should keep it)

Could be true, but I thought it'd be just as easy for the ledger if we add Datum to ScriptPurpose. I believe when constructing ScriptPurpose, the ledger does have access to the Datum, so it can simply stuff it in. But I could be wrong. @lehins @WhatisRT let me know whether you prefer ScriptContext/ScriptIdentifier, or ScriptInfo/ScriptContext (in both cases, the former contains the additional datum).

[MicroProofs]

All scripts have the signature EvaluationInfo -> TxInfo -> ()

The problem with this naming is that TxInfo is also the info you need for evaluating a script, i.e., "evaluation info". I think I like "redeemer" and "script context" better.

ScriptPurpose as used elsewhere is left untouched (the ledger uses the "purpose" terminology so I think we should keep it)

Could be true, but I thought it'd be just as easy for the ledger if we add Datum to ScriptPurpose. I believe when constructing ScriptPurpose, the ledger does have access to the Datum, so it can simply stuff it in. But I could be wrong. @lehins @WhatisRT let me know whether you prefer ScriptContext/ScriptIdentifier, or ScriptInfo/ScriptContext (in both cases, the former contains the additional datum).

What would the case be for no datum btw?

[zliu41]

What would the case be for no datum btw?

I thought allowing datum to be optional is the subject of another CIP, but Maybe Datum seems sensible to me.

[zliu41]

Updated; datum is now optional

[rphair]

@zygomeb this was reviewed at the CIP editor's meeting today & the response was favourable, indicating that the IOG Plutus team would prefer to do it this way (cc @michaelpj) ... i.e. they would prefer to implement your original proposal with this change.

I'm marking it Last Check with the hope we can merge this in 2 weeks' time (cc @Ryun1) so please post here if you have any objections before then... also it would help to have your affirmation if you can provide it, or to settle any reservations in discussion here in the meantime.

[WhatisRT]

I think I don't mind adding the Datum to ScriptPurpose, it seems like it might actually simplify some code a little bit. It also makes sense philosophically since we sometimes treat the Datum as part of the Credential.

[MicroProofs]

@lehins

Is it possible to make this or a simplified version of just Maybe Datum instead of Datum make it into the Chang hardfork?
I think the importance of having no datum spend execution will greatly enhance the Dev experience and UX.

I believe the feature is worth delaying the Chang hard fork if we can get even a more simplified version of this CIP.

[rphair]

re: #784 (comment) @MicroProofs I've added this question to tonight's CIP meeting agenda in the hope you can make it. If not done already in the PR thread in the meantime, we can clarify your request and maybe get feedback from other developers about how much their experience might be affected with & without it.

[MicroProofs]

Ok I'll make it to the meeting today.

[leo42]

I have said it many time at every opportunity I get basically, but this functionality is game-changing for smart-wallets and will enable an entire new class of users for the ecosystem.

for my work the lack of this functionality has been a blocking issue for a very long time.

[MicroProofs]

@lehins

Is it possible to make this or a simplified version of just Maybe Datum instead of Datum make it into the Chang hardfork? I think the importance of having no datum spend execution will greatly enhance the Dev experience and UX.

I believe the feature is worth delaying the Chang hard fork if we can get even a more simplified version of this CIP.

If the ledger team is not feature frozen, I am wondering if it's possible to change the ledger to pass in a Maybe Datum instead of Datum.

Here is the code that would change in master
eras/alonzo/impl/src/Cardano/Ledger/Alonzo/Plutus/Evaluate.hs

I think I got the right area, but my LSP for Haskell isn't working at the moment so I might be off the location by a little bit. Apologies.

 Right scriptContext ->
          let spendingDatum = getSpendingDatum utxo tx $ hoistPlutusPurpose toAsItem plutusPurpose
              datums = maybe id (:) spendingDatum [d, scriptContext]
           in Right $
                withPlutusScript plutusScript $ \plutus ->
                  PlutusWithContext
                    { pwcProtocolVersion = protVerMajor
                    , pwcScript = Left plutus
                    , pwcScriptHash = plutusScriptHash
                    , pwcDatums = PlutusDatums (getPlutusData <$> datums)
                    , pwcExUnits = exUnits
                    , pwcCostModel = costModel
                    }

I believe here you would change how spendingDatum returns to differentiate between NoDatum vs other script purposes.

This would enable a wide variety of features here

Use cases include

Smart wallets, wallets that can do 2fa, vault features
(prevent wallet drainers), and intention based transactions (single transactions swaps with dexes and free limit order placements).

Datumless utxos accidentally sent to a Dapp could be recovered for the user.

Easier subscription services that don't require you to send funds to a contract
@zliu41 @lehins @WhatisRT @michaelpj

[lehins]

Sorry guys, I was on PTO for a while and was catching up with all of the other important Conway related issues.

Unfortunately proposed solution requires quite a bit of work on the ledger side and we just don't have enough time to get it done, considering how close we are to the Chang hardfork deadline.

I believe the feature is worth delaying the Chang hard fork ...

Such decision is definitely above my pay grade. 🥲 So if we were to postpone the deadline this would have to come from the upper management, not from the developers.

With respect to the CIP. To be honest with you I am not very fond of the proposed solution and I think we can do better if we are not gonna rush it. That being said we might be able to do an interim solution for PlutusV3 that resembles the original suggestion quite easily, if there is interest in it. Solution I am talking about is what @MicroProofs suggested:

If the ledger team is not feature frozen, I am wondering if it's possible to change the ledger to pass in a Maybe Datum instead of Datum.

In my opinion this is a safer solution, albeit less type safe, than the one proposed in this CIP. In particular my worry is that plutus evaluator is essentially a variadic function that will always succeed if it is not fully saturated. Which means that if we reduce number of arguments to 2 for spending scripts then older scripts blindly ported to PlutusV3 would always succeed, because they would not have enough arguments.

What I personally would suggest instead, since everyone is in favor of having the same number of arguments for all type of scripts, is to stop accepting a list of Data arguments to plutus evaluator altogether and completely switch to accepting a single argument. That argument could be even called ScriptContext and it would contain all of the required information:

data ScriptContext
  = Minting TxInfo Redeemer CurrencySymbol
  | Spending TxInfo Redeemer Datum TxOutRef
  | Rewarding TxInfo Redeemer Credential
  | Certifying TxInfo Redeemer Integer TxCert 
  | Voting TxInfo Redeemer Voter
  | Proposing TxInfo Redeemer Integer ProposalProcedure

In other words changing the type signature of this function to:

https://github.com/IntersectMBO/plutus/blob/16a986fd800e044773e27718fc78c0c2885854e6/plutus-ledger-api/src/PlutusLedgerApi/V3.hs#L207-L221

evaluateScriptRestricting ::
  -- | Which protocol version to run the operation in
  MajorProtocolVersion ->
  -- | Whether to produce log output
  VerboseMode ->
  -- | Includes the cost model to use for tallying up the execution costs
  EvaluationContext ->
  -- | The resource budget which must not be exceeded during evaluation
  ExBudget ->
  -- | The script to evaluate
  ScriptForEvaluation ->
  -- | The arguments to the script
  PLC.Data -> -- <-------- This is the change we should aim for.
  (LogOutput, Either EvaluationError ExBudget)

I honestly don't understand what was the reason for evaluator to accept a list of Data arguments if Data can already represent a list Data.

Of course, this is just my opinion and maybe it either needs to be polished a bit more or maybe it has some serious downsides that I am not aware. In either case neither this solution nor the one proposed in the CIP can make it into Conway due to the time constraints.

Back to the potential interim solution for PlutusV3 proposed in #784 (comment). Please, let me know if it would be a sufficient interim solution for Plutus script writers and if it would at least unblock all those use cases mentioned in this discussion. If there would be no objections from all the parties interested in this we could potentially squeeze it in for Conway, because it is simple and requires no changes on the Plutus side and very minimal changes on the Ledger side. Here is a proof of concept implemented in ledger: IntersectMBO/cardano-ledger#4271

Couple of notes about the interim solution:

• There is no Maybe type in plutus Data, so Maybe Data has to be represented as a singleton list with an optional element List [Data]. Feel free to suggest a different representation.
• This extra new argument will not be optional for Spending scripts, that is because Spending datum is enforced by the ledger rules, which we are not going to change on such a short notice. It is a lot more complicated than it sounds. So this CIP-0069 | add Datum to ScriptContext #784 (comment) is not part of this interim solution.

[MicroProofs]

Sorry guys, I was on PTO for a while and was catching up with all of the other important Conway related issues.

Unfortunately proposed solution requires quite a bit of work on the ledger side and we just don't have enough time to get it done, considering how close we are to the Chang hardfork deadline.

I believe the feature is worth delaying the Chang hard fork ...

Such decision is definitely above my pay grade. 🥲 So if we were to postpone the deadline this would have to come from the upper management, not from the developers.

With respect to the CIP. To be honest with you I am not very fond of the proposed solution and I think we can do better if we are not gonna rush it. That being said we might be able to do an interim solution for PlutusV3 that resembles the original suggestion quite easily, if there is interest in it. Solution I am talking about is what @MicroProofs suggested:

If the ledger team is not feature frozen, I am wondering if it's possible to change the ledger to pass in a Maybe Datum instead of Datum.

In my opinion this is a safer solution, albeit less type safe, than the one proposed in this CIP. In particular my worry is that plutus evaluator is essentially a variadic function that will always succeed if it is not fully saturated. Which means that if we reduce number of arguments to 2 for spending scripts then older scripts blindly ported to PlutusV3 would always succeed, because they would not have enough arguments.

What I personally would suggest instead, since everyone is in favor of having the same number of arguments for all type of scripts, is to stop accepting a list of Data arguments to plutus evaluator altogether and completely switch to accepting a single argument. That argument could be even called ScriptContext and it would contain all of the required information:

data ScriptContext
  = Minting TxInfo Redeemer CurrencySymbol
  | Spending TxInfo Redeemer Datum TxOutRef
  | Rewarding TxInfo Redeemer Credential
  | Certifying TxInfo Redeemer Integer TxCert 
  | Voting TxInfo Redeemer Voter
  | Proposing TxInfo Redeemer Integer ProposalProcedure

In other words changing the type signature of this function to:

https://github.com/IntersectMBO/plutus/blob/16a986fd800e044773e27718fc78c0c2885854e6/plutus-ledger-api/src/PlutusLedgerApi/V3.hs#L207-L221

evaluateScriptRestricting ::
  -- | Which protocol version to run the operation in
  MajorProtocolVersion ->
  -- | Whether to produce log output
  VerboseMode ->
  -- | Includes the cost model to use for tallying up the execution costs
  EvaluationContext ->
  -- | The resource budget which must not be exceeded during evaluation
  ExBudget ->
  -- | The script to evaluate
  ScriptForEvaluation ->
  -- | The arguments to the script
  PLC.Data -> -- <-------- This is the change we should aim for.
  (LogOutput, Either EvaluationError ExBudget)

I honestly don't understand what was the reason for evaluator to accept a list of Data arguments if Data can already represent a list Data.

Of course, this is just my opinion and maybe it either needs to be polished a bit more or maybe it has some serious downsides that I am not aware. In either case neither this solution nor the one proposed in the CIP can make it into Conway due to the time constraints.

Back to the potential interim solution for PlutusV3 proposed in #784 (comment). Please, let me know if it would be a sufficient interim solution for Plutus script writers and if it would at least unblock all those use cases mentioned in this discussion. If there would be no objections from all the parties interested in this we could potentially squeeze it in for Conway, because it is simple and requires no changes on the Plutus side and very minimal changes on the Ledger side. Here is a proof of concept implemented in ledger: IntersectMBO/cardano-ledger#4271

Couple of notes about the interim solution:

• There is no Maybe type in plutus Data, so Maybe Data has to be represented as a singleton list with an optional element List [Data]. Feel free to suggest a different representation.
• This extra new argument will not be optional for Spending scripts, that is because Spending datum is enforced by the ledger rules, which we are not going to change on such a short notice. It is a lot more complicated than it sounds. So this CIP-0069 | add Datum to ScriptContext #784 (comment) is not part of this interim solution.

My apologies on suggesting the delayed hard fork. The better option is to rally community support to put it at the forefront of the next HF or possibly an early mini one (depending on community feedback and testing and scope of changes of course)

[MicroProofs]

Back to the potential interim solution for PlutusV3 proposed in #784 (comment). Please, let me know if it would be a sufficient interim solution for Plutus script writers and if it would at least unblock all those use cases mentioned in this discussion. If there would be no objections from all the parties interested in this we could potentially squeeze it in for Conway, because it is simple and requires no changes on the Plutus side and very minimal changes on the Ledger side. Here is a proof of concept implemented in ledger: IntersectMBO/cardano-ledger#4271

Couple of notes about the interim solution:

• There is no Maybe type in plutus Data, so Maybe Data has to be represented as a singleton list with an optional element List [Data]. Feel free to suggest a different representation.
• This extra new argument will not be optional for Spending scripts, that is because Spending datum is enforced by the ledger rules, which we are not going to change on such a short notice. It is a lot more complicated than it sounds. So this CIP-0069 | add Datum to ScriptContext #784 (comment) is not part of this interim solution.

The interim solution with both enforcing that Spend still takes in 3 arguments as well as it being a List [Data] is a fine solution for PlutusV3. This would work for the use cases mentioned and unblocks a lot for wallet maker to move forward with smart contract wallets. Since this change requires buy in from the active Language developers, I will tag them here. If you need a new CIP as well I can create one. This is in my opinion a good improvement over status quo. I'll tag the other language creators.

@nielstron @nau @michele-nuzzi @christianschmitz @michaelpj
I have not tagged Plutarch creator because I believe that is not in development for PlutusV3 support.

[MicroProofs]

The interim solution with both enforcing that Spend still takes in 3 arguments as well as it being a List [Data] is a fine solution for PlutusV3.

An alternative solution is constr 0 {[Datum]} to represent Some(Datum) and constr 1 {[]} to represent None in Plutus Data
I'll let others way in to which decision is preferable.

[nielstron]

I would prefer the constr0/constr1 distinction (which is essentially PlutusData maybe).

A list gives the illusion of the possibility of multiple parameters to the script.

That said my opinion on this is not very strong except for "it would be really nice to have any solution ASAP" :)

[lehins]

Please thumbs up 👍 who is in favor of or thumbs down 👎 who is against this representation for Maybe Datum:

Going for the best correspondence for the Haskell's data Maybe a = Just a | Nothing definition:

• Constr 0 [Data] for Just Data
• Constr 1 [] for Nothing

[lehins]

Same as above, but constructors swapped as in proposed solution by @MicroProofs:

alternative solution is constr 0 {[Datum]} to represent Some(Datum) and constr 1 {[]} to represent None in Plutus Data

• Constr 0 [] for Nothing
• Constr 1 [Data] for Just Data

[lehins]

Just for completeness sake. Same as above 👍 and 👎, for the less popular solution of using List:

• List [] for Nothing
• List [Data] for Just Data

[KtorZ]

Please thumbs up 👍 who is in favor of or thumbs down 👎 who is against this representation for Maybe Datum:

Going for the best correspondence for the Haskell's data Maybe a = Just a | Nothing definition:

* `Constr 0 [Data]` for `Just Data`

* `Constr 1 []` for `Nothing`

It seems to me that this is the most (and only?) viable choice given that it's already the encoding used for Maybe a in Haskell and Option<a> in Aiken & Helios. I assume it's the same for OpShin, Plu-ts and Scalus. Going for the opposite (Constr 0 [] for Nothing) would be utterly confusing without also changing this in the serialization of all ABIs.

I believe @MicroProofs just mixed up the constructor indices in his comment 😅, but the essence of the suggestion was about suggesting to "use Constr instead of a List".

@nau @nielstron any reason for preferring Constr 0 [] for Nothing 🤔?

[michele-nuzzi]

the "Haskell Maybe" (Just contsr 0 and Nothing constr 1) representation is already used anyway in V1 TxOuts for datum hashes and V2 TxOuts for ref scripts; I don't see why we should go for something else

[MicroProofs]

Sorry guys, I was on PTO for a while and was catching up with all of the other important Conway related issues.

Unfortunately proposed solution requires quite a bit of work on the ledger side and we just don't have enough time to get it done, considering how close we are to the Chang hardfork deadline.

I believe the feature is worth delaying the Chang hard fork ...

Such decision is definitely above my pay grade. 🥲 So if we were to postpone the deadline this would have to come from the upper management, not from the developers.

With respect to the CIP. To be honest with you I am not very fond of the proposed solution and I think we can do better if we are not gonna rush it. That being said we might be able to do an interim solution for PlutusV3 that resembles the original suggestion quite easily, if there is interest in it. Solution I am talking about is what @MicroProofs suggested:

If the ledger team is not feature frozen, I am wondering if it's possible to change the ledger to pass in a Maybe Datum instead of Datum.

In my opinion this is a safer solution, albeit less type safe, than the one proposed in this CIP. In particular my worry is that plutus evaluator is essentially a variadic function that will always succeed if it is not fully saturated. Which means that if we reduce number of arguments to 2 for spending scripts then older scripts blindly ported to PlutusV3 would always succeed, because they would not have enough arguments.

What I personally would suggest instead, since everyone is in favor of having the same number of arguments for all type of scripts, is to stop accepting a list of Data arguments to plutus evaluator altogether and completely switch to accepting a single argument. That argument could be even called ScriptContext and it would contain all of the required information:

data ScriptContext
  = Minting TxInfo Redeemer CurrencySymbol
  | Spending TxInfo Redeemer Datum TxOutRef
  | Rewarding TxInfo Redeemer Credential
  | Certifying TxInfo Redeemer Integer TxCert 
  | Voting TxInfo Redeemer Voter
  | Proposing TxInfo Redeemer Integer ProposalProcedure

In other words changing the type signature of this function to:

https://github.com/IntersectMBO/plutus/blob/16a986fd800e044773e27718fc78c0c2885854e6/plutus-ledger-api/src/PlutusLedgerApi/V3.hs#L207-L221

evaluateScriptRestricting ::
  -- | Which protocol version to run the operation in
  MajorProtocolVersion ->
  -- | Whether to produce log output
  VerboseMode ->
  -- | Includes the cost model to use for tallying up the execution costs
  EvaluationContext ->
  -- | The resource budget which must not be exceeded during evaluation
  ExBudget ->
  -- | The script to evaluate
  ScriptForEvaluation ->
  -- | The arguments to the script
  PLC.Data -> -- <-------- This is the change we should aim for.
  (LogOutput, Either EvaluationError ExBudget)

I honestly don't understand what was the reason for evaluator to accept a list of Data arguments if Data can already represent a list Data.

Of course, this is just my opinion and maybe it either needs to be polished a bit more or maybe it has some serious downsides that I am not aware. In either case neither this solution nor the one proposed in the CIP can make it into Conway due to the time constraints.

Back to the potential interim solution for PlutusV3 proposed in #784 (comment). Please, let me know if it would be a sufficient interim solution for Plutus script writers and if it would at least unblock all those use cases mentioned in this discussion. If there would be no objections from all the parties interested in this we could potentially squeeze it in for Conway, because it is simple and requires no changes on the Plutus side and very minimal changes on the Ledger side. Here is a proof of concept implemented in ledger: IntersectMBO/cardano-ledger#4271

Couple of notes about the interim solution:

• There is no Maybe type in plutus Data, so Maybe Data has to be represented as a singleton list with an optional element List [Data]. Feel free to suggest a different representation.
• This extra new argument will not be optional for Spending scripts, that is because Spending datum is enforced by the ledger rules, which we are not going to change on such a short notice. It is a lot more complicated than it sounds. So this CIP-0069 | add Datum to ScriptContext #784 (comment) is not part of this interim solution.

@michaelpj

To my knowledge the PR linked should allow utxos without datums to be spent by scripts since there will always be 3 arguments. Could you let me know what else is blocking the spending of datumless utxos?

[lehins]

I don't think the ledger right now prevents you from making a utxo at an address that is a plutus script without a datum.

Yes it does so inderectly. It prevents you from spending it, if it is locked by a Plutus script and datum is not supplied

[lehins]

@MicroProofs See the very last thing in my comment:

This extra new argument will not be optional for Spending scripts, that is because Spending datum is enforced by the ledger rules, which we are not going to change on such a short notice. It is a lot more complicated than it sounds. So this #784 (comment) is not part of this interim solution.

[MicroProofs]

I don't think the ledger right now prevents you from making a utxo at an address that is a plutus script without a datum.

Yes it does so inderectly. It prevents you from spending it, if it is locked by a Plutus script and datum is not supplied

@MicroProofs See the very last thing in my comment:

This extra new argument will not be optional for Spending scripts, that is because Spending datum is enforced by the ledger rules, which we are not going to change on such a short notice. It is a lot more complicated than it sounds. So this #784 (comment) is not part of this interim solution.

Doesn't your proposed solution allow no datums to resolve to Nothing based on the lookup function I copied over. Is there some other error in the ledger that prevents no datum utxo spends?

[MicroProofs]

The interim solution was an attempt to bypass where the check for the Datum happens by replacing it with a Data instead. But I see it is in a separate file where the utxo itself is checked. Is there a solution we can do for this before Conway. This is the main blocker in this thread for various solutions.

[lehins]

Is there some other error in the ledger that prevents no datum utxo spends?

Yes, that is exactly what I am saying. There is a predicate check that fails validation when the TxOut is locked by a Plutus script and does not have a datum associated with it.

[lehins]

The interim solution was an attempt to bypass where the check for the Datum happens by replacing it with a Data instead. ... Is there a solution we can do for this before Conway.

Sorry to be a bearer of bad news, but not without moving the Conway deadline.

Note that the goal of this CIP was to change the number of arguments that all scripts get. At least that was my understanding of the CIP. Making Datum optional was just a minor addition to the CIP. That is why I suggested to go with the interim solution that would solve the main problem.

Looks like we all got too happy too soon. 😞

[MicroProofs]

datums <-
        case toSpendingPurpose plutusPurpose of
          Just (AsIxItem _ txIn) -> do
            txOut <- note (UnknownTxIn txIn) $ Map.lookup txIn (unUTxO utxo)
            datum <-
              case txOut ^. datumTxOutF of
                Datum binaryData -> pure $ binaryDataToData binaryData
                DatumHash dh -> note (MissingDatum dh) $ Map.lookup dh dats
                NoDatum -> Left (InvalidTxIn txIn)
            pure [datum, rdmr, scriptContext]
          Nothing -> pure [rdmr, scriptContext]

Is this code in libs/cardano-ledger-api/src/Cardano/Ledger/Api/Scripts/ExUnits.hs
also an issue too?

[lehins]

Is this code in ... also an issue too?

Yes, but it is a minor issue. This is just a helper function for the cardano-api/cli It is not used by the ledger

[lehins]

Looks great. Couple suggestions from me

[lehins]

I suggest we also specify somewhere here maybe that we need enforce a single argumet to plutus evaluating function, which at the very least means changing type signatures for these two functions for PlutusV3 in a way that they will accept a single PLC.Data agument, instead of [PLC.Data]:

• evaluateScriptCounting
• evaluateScriptRestricting

[rphair]

@lehins @zliu41 @MicroProofs @michaelpj @KtorZ @colll78 should #769 be updated with any of these deliberations? Does what's being agreed upon here settle that issue?

[rphair]

Because this has been technically at Last Check status here for 5+ weeks, I've put it for Last Check status on the next CIP Editors Meeting agenda (https://hackmd.io/@cip-editors/87) where either we can merge it... if @MicroProofs @lehins agree it now reflects currently agreed upon changes for the immediate next stage of this CIP's implementation... or remove the Last Check flag if in abeyance for whatever reason.

[zliu41]

After some discussion here's the current proposal: All scripts have the signature of ScriptContext -> a. A new ScriptInfo type is to be created to replace the ScriptPurpose field in ScriptContext. ScriptInfo is similar to ScriptPurpose, except that each constructor contains a Redeemer argument, and the Spending constructor contains a Maybe Datum argument. The ScriptPurpose type is unchanged and continues to be used as the key of the txInfoRedeemers map.

data ScriptContext = ScriptContext
  { scriptContextTxInfo  :: TxInfo
  , scriptContextScriptInfo :: ScriptInfo
  -- ^ Previously this was `ScriptPurpose`
  }

data ScrintInfo
  = MintingScript V2.CurrencySymbol Redeemer
  | SpendingScript V3.TxOutRef (Maybe Datum) Redeemer
  | RewardingScript V2.Credential Redeemer
  | CertifyingScript
      Haskell.Integer
      -- ^ 0-based index of the given `TxCert` in `txInfoTxCerts`
      TxCert
      Redeemer
  | VotingScript Voter Redeemer
  | ProposingScript
      Haskell.Integer
      -- ^ 0-based index of the given `ProposalProcedure` in `txInfoProposalProcedures`
      ProposalProcedure
      Redeemer

[Ryun1]

With my understanding this is good to go
and planned to be included within Plutus V3

[rphair]

Also my understanding but would be happy to hear, before merging, one final confirmation from @zliu41 and/or @MicroProofs that the recently modified changes accurately describe the planned changes for the next hard fork.

[zliu41]

I need to make another update before merging

[zliu41]

I made an update to the ScriptContext and ScriptInfo types, and this is now ready to merge - cc @rphair @MicroProofs