CIP-0069 | add Datum to ScriptContext #784

zliu41 · 2024-03-14T19:43:13Z

Closes #769

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

rphair · 2024-03-15T05:13:51Z

@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 · 2024-03-15T16:02:23Z

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

MicroProofs · 2024-03-15T18:43:56Z

CIP-0069/README.md

+```hs
+data ScriptPurpose
+  = ...
+  | Spending TxOutRef Datum


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

michaelpj · 2024-03-18T10:21:58Z

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 · 2024-03-18T18:49:07Z

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 · 2024-03-18T19:10:30Z

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 · 2024-03-18T19:24:11Z

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 · 2024-03-19T00:21:32Z

Updated; datum is now optional

rphair · 2024-03-19T17:17:43Z

@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 · 2024-03-21T12:26:20Z

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 · 2024-04-16T13:58:51Z

@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 · 2024-04-16T14:18:40Z

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 · 2024-04-16T14:56:00Z

Ok I'll make it to the meeting today.

leo42 · 2024-04-16T15:24:12Z

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 · 2024-04-16T16:47:42Z

@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 · 2024-04-17T00:08:37Z

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 · 2024-04-17T03:50:37Z

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 · 2024-04-17T04:02:52Z

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 · 2024-04-17T04:21:42Z

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 · 2024-04-17T06:27:43Z

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 · 2024-04-17T06:46:09Z

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 · 2024-04-17T06:48:06Z

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 · 2024-04-17T06:50:25Z

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 · 2024-04-17T09:50:30Z

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 · 2024-04-17T10:00:34Z

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 · 2024-04-18T17:05:34Z

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 · 2024-04-18T17:05:58Z

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 · 2024-04-18T17:06:55Z

@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 · 2024-04-18T17:09:08Z

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 · 2024-04-18T17:21:55Z

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 · 2024-04-18T17:22:00Z

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 · 2024-04-18T17:28:20Z

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 · 2024-04-18T17:29:21Z

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 · 2024-04-18T17:31:14Z

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

…gument

lehins

Looks great. Couple suggestions from me

CIP-0069/README.md

lehins · 2024-04-19T21:18:47Z

CIP-0069/README.md

+
+The ScriptPurpose type used in the Redeemers Map is left the same.
+
+


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

CIP-0069/README.md

Co-authored-by: Alexey Kuleshevich <[email protected]>

rphair · 2024-04-21T18:18:41Z

@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 · 2024-04-25T18:24:15Z

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 · 2024-04-26T01:00:23Z

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 · 2024-05-28T16:17:18Z

I need to make another update before merging

zliu41 · 2024-06-05T18:40:28Z

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

CIP-0069 | add Datum to ScriptContext

91c0493

rphair added Category: Plutus Proposals belonging to the 'Plutus' category. Update Adds content or significantly reworks an existing proposal labels Mar 15, 2024

MicroProofs reviewed Mar 15, 2024

View reviewed changes

Maybe Datum

21c2670

rphair added the State: Last Check Review favourable with disputes resolved; staged for merging. label Mar 19, 2024

MicroProofs added 3 commits April 19, 2024 16:08

Push up new specification that changes Plutus scripts to take in 1 ar…

39005ff

…gument

Add one more line about the relaxing the ledger rule

7296a6a

typo fix

048158b

lehins reviewed Apr 19, 2024

View reviewed changes

MicroProofs and others added 2 commits April 19, 2024 23:33

Update CIP-0069/README.md -- ScriptContext type

a8ae527

Co-authored-by: Alexey Kuleshevich <[email protected]>

Update CIP-0069/README.md -- Remove old paragraph

2b85ccd

Co-authored-by: Alexey Kuleshevich <[email protected]>

zliu41 mentioned this pull request Apr 29, 2024

PlutusV3: Datum/Redeemer in ScriptContext, Datum Optional, Unified Script Type IntersectMBO/plutus#5934

Merged

update type structure

2d9e392

kwxm mentioned this pull request May 7, 2024

UCaseOfCase Translation Relation and Decision Procedure IntersectMBO/plutus#5947

Closed

8 tasks

Ryun1 approved these changes May 28, 2024

View reviewed changes

rphair approved these changes May 28, 2024

View reviewed changes

factor out redeemer

ffc4c8d

rphair merged commit 93a6c22 into cardano-foundation:master Jun 6, 2024

fallen-icarus mentioned this pull request Jul 17, 2024

CIP-0087? | Maybe Datum #440

Closed

TotallyNotChase mentioned this pull request Jul 21, 2024

Bump to latest Plutarch mlabs-haskell/ply#52

Merged

rphair removed the State: Last Check Review favourable with disputes resolved; staged for merging. label Sep 3, 2024


		The ScriptPurpose type used in the Redeemers Map is left the same.

CIP-0069 | add Datum to ScriptContext #784

CIP-0069 | add Datum to ScriptContext #784

Conversation

zliu41 commented Mar 14, 2024

rphair commented Mar 15, 2024

MicroProofs commented Mar 15, 2024

MicroProofs Mar 15, 2024

Choose a reason for hiding this comment

michaelpj commented Mar 18, 2024

zliu41 commented Mar 18, 2024 • edited Loading

MicroProofs commented Mar 18, 2024

zliu41 commented Mar 18, 2024

zliu41 commented Mar 19, 2024 • edited Loading

rphair commented Mar 19, 2024 • edited Loading

WhatisRT commented Mar 21, 2024

MicroProofs commented Apr 16, 2024

rphair commented Apr 16, 2024 • edited Loading

MicroProofs commented Apr 16, 2024

leo42 commented Apr 16, 2024

MicroProofs commented Apr 16, 2024 • edited Loading

lehins commented Apr 17, 2024

MicroProofs commented Apr 17, 2024

MicroProofs commented Apr 17, 2024

MicroProofs commented Apr 17, 2024

nielstron commented Apr 17, 2024

lehins commented Apr 17, 2024 • edited Loading

lehins commented Apr 17, 2024

lehins commented Apr 17, 2024

KtorZ commented Apr 17, 2024 • edited Loading

michele-nuzzi commented Apr 17, 2024

MicroProofs commented Apr 18, 2024

lehins commented Apr 18, 2024

lehins commented Apr 18, 2024

MicroProofs commented Apr 18, 2024 • edited Loading

MicroProofs commented Apr 18, 2024

lehins commented Apr 18, 2024

lehins commented Apr 18, 2024 • edited Loading

MicroProofs commented Apr 18, 2024

lehins commented Apr 18, 2024

lehins left a comment

Choose a reason for hiding this comment

lehins Apr 19, 2024

Choose a reason for hiding this comment

rphair commented Apr 21, 2024

rphair commented Apr 25, 2024

zliu41 commented Apr 26, 2024

Ryun1 left a comment

Choose a reason for hiding this comment

rphair left a comment

Choose a reason for hiding this comment

zliu41 commented May 28, 2024

zliu41 commented Jun 5, 2024

zliu41 commented Mar 18, 2024 •

edited

Loading

zliu41 commented Mar 19, 2024 •

edited

Loading

rphair commented Mar 19, 2024 •

edited

Loading

rphair commented Apr 16, 2024 •

edited

Loading

MicroProofs commented Apr 16, 2024 •

edited

Loading

lehins commented Apr 17, 2024 •

edited

Loading

KtorZ commented Apr 17, 2024 •

edited

Loading

MicroProofs commented Apr 18, 2024 •

edited

Loading

lehins commented Apr 18, 2024 •

edited

Loading