CIP-0087? | Maybe Datum

[fallen-icarus]

A CIP that looks to address the concerns of #364, #423, #309, #310, and #321 in one go.

See proposal here.

[rphair]

Looks good at first view @fallen-icarus & thanks for drawing all these discussions together.

[nielstron]

I approve this CIP. The issue of accidentally locking UTxOs for good is widespread and problematic and the use cases for multipurpose scripts are clear enough to make them easy to achieve by design.

[nielstron]

Note that the motivation/problem 3 is not accurate. A solution to this problem with the current design / PlutusV2 and the corresponding drawback is outlined here: https://github.com/ImperatorLang/eopsin/blob/master/ARCHITECTURE.md#minting-policy---spending-validator-double-function

[fallen-icarus]

@nielstron I updated the problem 3 section to acknowledge eopsin's workaround. My apologies for not doing it sooner.

[nielstron]

Thanks!

[ch1bo]

PR #309 has a related discussion to this.

#309 (comment)

[fallen-icarus]

@ch1bo What are your thoughts about this CIP? It is meant to address the concerns of 309 as well. Do you agree that it does?

Edit: Here is my recent comment in that thread that further explains my perspective. comment

[imikushin]

@fallen-icarus In this model, can there be a situation when there's one script address, and:

• one transaction would spend from it running the script as a tx-level script,
• another transaction would spend from it running the script per-UTxO?

Another question: can a transaction run several tx-level scripts? (Perhaps, when spending outputs from M addresses, created from N scripts, where M > N) How would this work?

[fallen-icarus]

@imikushin The same script can be used in either context. You can think of all scripts as having logic like

if maybe_datum == Just datum
then utxo_level_logic
else tx_level_logic

can a transaction run several tx-level scripts? ... How would this work?

You can use as many tx-level scripts as will fit into the tx. The following table shows some valid usages:

Tx 1	Tx 2	Tx 3	Tx 4
Script A as tx-level	Script A as tx-level	Script A as utxo-level	Script A as utxo-level
Script B as tx-level	Script B as utxo-level	Script B as tx-level	Script B as utxo-level

The only restriction is that, within the same tx, script A cannot be used as BOTH a tx-level script and a utxo-level script. As far as how this would work, the ledger is already capable of detecting if all the relevant scripts are present. Currently, every utxo needs an accompanying script to execute at the utxo-level. This detection tooling will need to be slightly altered to also allow using tx-level scripts to witness all utxos from that script's address in the same way that a pubkey can witness all utxos from the user's address.

Perhaps, when spending outputs from M addresses, created from N scripts, where M > N

This is an interesting use case: If Address AA and Address AB are protected by Script A, can script A be used at the tx-level for Address AA's utxos while being used at the utxo-level for Address AB's utxos in the same tx? I would have to say no simply because this would likely dramatically complicate the ledger-script interface and I don't think this use case is ubiquitous enough to warrant adding such complexity. For most use cases, the script is probably meant to be used as only one level or the other, regardless of the address being spent from. If this usage is necessary, you can always break it up over multiple txs. Somebody on the plutus or ledger team will know better how complicated allowing this niche use case would be. The proposal, as it is now, does not allow for this use case.

[imikushin]

@fallen-icarus, thanks for your reply. With clarifications about multiple tx-level scripts, I can definitely get behind this proposal.

Tx-level validation (as opposed to per-UTxO) basically gives more scalability for free (besides, of course, implementation cost), i.e. we're not paying for it by sacrificing security or decentralization.

[imikushin]

@fallen-icarus Just a thought: maybe a better name for this CIP could be Transaction Level Validation Scripts.

I think it communicates the solution much better. Sure, script re-usability is an issue. But a much bigger concern is scalability, which this proposal addresses.

I mean, just think of a transaction dealing with multiple outputs that has to perform a ZK proof verification (a pretty intensive computation). How much easier it gets with per-transaction script execution vs per-output.

[fallen-icarus]

@imikushin I had thought about that before but tx level scripts aren't the main focus of this CIP. While I personally agree with the tx level scripts being the most important consequence of this CIP (since you can't fully utilize the eUTxO model without it), the main focus is on changing things to use the Maybe Datum. @rphair Do you have an opinion on this?

[rphair]

@fallen-icarus I agree the "Transaction" oriented name would be eye-catching for implementations, but the goal of any standard is to be applied as generally as possible. Therefore if the current name "Maybe Datum" is the most generally applicable I'd be in favour of keeping it in the title unless there's a more explicit title that means the same thing (as a non Plutus programmer it means nothing to me except what people have said about this & related CIPs).

@imikushin's highlighted use case is a great one to keep focusing on, but from my (not technically expert on this subject) point of view you have to read deeply into the text to find how this phrase applies to the subject. So maybe that use case could be included under a heading like "Use cases for Transaction Level Validation Scripts" in the Motivation or Rationale section.

[michaelpj]

This CIP contains two very different proposals:

• A fairly straightforward proposal to make datums optional. This is fine, I would like to do something like this, but overall I prefer CIP-0069? | Plutus Script Type Uniformization #321
• A complicated proposal to reduce how often scripts are executed in some cases.

I think it would be a stronger proposal if these were separated (from the title I assumed it would just be the first part). In particular the second needs much more development, as it currently glosses over a lot of important details.

---

I think the overall proposal could be carved up and made simpler and more compositional.

• Proposal 1: when the ledger accumulates script evaluations to perform as (Script, [Data]) tuples, it deduplicates this list before performing evaluations, so as not to do redundant work. This would need a CIP because it would need to specify the budget discount for the non-evaluated scripts, otherwise it's pointless.
• Proposal 2: optional datums or CIP-0069? | Plutus Script Type Uniformization #321
• Proposal 3: something with this special flag designed to make more script evaluations look identical

This would allow for proposal 1 to get implemented, while we're still working out what the best way to get more identical script evaluations is (whether it's proposal 3 or something else).

[fallen-icarus]

@michaelpj thanks for the review. I'll need to think about the rest of your comments here.

[ShariffL]

@oversize @KtorZ @katomm adding you in this discussion as well. Is there a way to get this CIP approved and merged? It will improve scalability for multi output tx. Or can you advise us how to move forward on this CIP? CC: @imikushin

[fallen-icarus]

@ShariffL I agree with @michaelpj that this CIP should be broken up into a few composable CIPs. Currently, I am considering breaking it up into two CIPs:

1. Using Maybe Datum for when a utxo is missing one. This would also enable universal scripts (one that can mint, spend, or manage rewards). It is mutually exclusive to CIP-0069? | Plutus Script Type Uniformization #321.
2. Adding a new tx input type for grouped inputs. See here. This would address the redundant executions and enable "ignoring" datums even if utxos have them (they will still be present in the ScriptContext).

[fallen-icarus]

I have updated the proposal to represent the reviewers' responses. This proposal no longer deals with the redundant executions. As suggested, that will be its own CIP.

[ch1bo]

To give another use case: There are situations where the sender should not need to be aware they are sending funds to a script.

An example to this are "Smart contract wallets". These wallets would lock funds in a script instead of a private key and can be used to implement do social recovery wallets or for-purpose debit accounts.

[michaelpj]

Since this is the major competitor to your proposal, I think you need to say a lot more about why you think yours should be implemented instead!

[fallen-icarus]

@michaelpj Do you think there is value in implementing the Maybe Datum for now while we sort out the ScriptArgs? The main difference between the two is that the ScriptArgs is easily extendable, but there are still questions around it. The Maybe Datum proposal does not take us very far from the existing design. IMO the issues discussed in this CIP are pressing enough to prioritize fixing soon. If we implement the Maybe Datum proposal first, we can then take our time sorting out the ScriptArgs. If ScriptArgs is deemed to be better, how much different is the process of going from our current design to ScriptArgs than going from the Maybe Datum design to ScriptArgs?

Being able to sort out the ScriptArgs without the pressure caused by the discussed issues is my main argument for why we should do the Maybe Datum. Basically, the idea is to use this CIP as a potential stopgap.

[michaelpj]

No, absolutely not. Changes that require new Plutus ledger languages are very expensive because they require us to support old versions forever. I am extremely not keen to add something that we plan to remove later.

[fallen-icarus]

@michaelpj Understood. Then I don't have an argument for choosing this proposal over the ScriptArgs one since I personally believe that, if the ScriptArgs can be added safely, it should be used. However, I think there is value in documenting what has been considered at each step of evolution for the design - this has been my main motivation for continuing to steel man this CIP despite thinking that ScriptArgs would likely be better. I am totally fine with this proposal getting merged, but then marking its status as inactive once ScriptArgs is ready. I'm not sure if the CIP process is meant to be used this way.

Considering that you did something similar with #336, what are your thoughts about this? I'm willing to wait until the ScriptArgs proposal is ready and then try arguing against it.

[Ryun1]

I believe this has been included within Conway

Can you confirm @zliu41 @lehins ?🙏

[fallen-icarus]

The others can correct me if I am wrong, but as the author of this CIP, I do not think this is being implemented in Conway. CIP-69 (#784) uses a Maybe Datum in a different way than this CIP was proposing. IMO, CIP-69 obsoletes the need for this one.

[lehins]

@fallen-icarus Yes, you are right in that CIP-0069 takes a different approach to solve the same problem. In that sense, it does make this CIP obsolete.

[rphair]

Thanks everybody especially @fallen-icarus for all the prior work on this. Based on the last comments by @lehins @fallen-icarus @Ryun1 I'm closing this as superseded, but please feel free to reopen if that turns out not to be true.