Skip to content
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

Behavior of Plutus V3 scripts without datum #637

Open
SeungheonOh opened this issue Jan 6, 2025 · 4 comments · May be fixed by #647
Open

Behavior of Plutus V3 scripts without datum #637

SeungheonOh opened this issue Jan 6, 2025 · 4 comments · May be fixed by #647
Labels
conformance documentation Improvements or additions to documentation era: conway

Comments

@SeungheonOh
Copy link

SeungheonOh commented Jan 6, 2025

PlutusV3 ledger api have introduced optional datum field to Spending constructor of ScriptInfo type. With changes in ScriptContext, intuitively, this change appears to be added in order to allow validation of PlutusV3 script UTXO that hold no datum. On contrast, such UTXOs locked on PlutusV1 and V2 script UTXO(with no datum) are considered burnt as the validation will always fail as per previous ledger specs.

So, I'm wondering if my assumption of PlutusV3 scripts now supporting "no datum" utxo is correct. And if so, having that spec'd out would be helpful since this behavior previously had detrimental effect.

@WhatisRT WhatisRT added documentation Improvements or additions to documentation era: conway conformance labels Jan 8, 2025
@WhatisRT
Copy link
Collaborator

WhatisRT commented Jan 8, 2025

I wasn't aware of this feature being implemented as part of Conway. You're completely right, if this is supported now this needs to be part of the spec. This should be fairly easy to do, just have to adjust a couple of types and functions. I don't think this will touch any proofs.

@lehins can you confirm that this is an intended feature? If so, this should have been communicated to us properly.

@lehins
Copy link

lehins commented Jan 8, 2025

@WhatisRT Yes, it is the CIP-69, which was indeed implemented for Conway era. I am really surprised you did not know about it. It was a big deal we even had to get an explicit approval from Charles to postpone the Chang hard fork in order to implement it.

@WhatisRT
Copy link
Collaborator

WhatisRT commented Jan 8, 2025

I only remember it coming up occasionally, but I wasn't in any meeting where a decision was made and it was never raised as something that we (formal methods) need to implement.

I'll give this a high priority for the spec release, should be fixed in a few weeks at the latest.

@WhatisRT
Copy link
Collaborator

I was going to write an implementation plan for this, but then I realized that there is actually nothing to do for the actual semantics, because we have a bug in our current Alonzo implementation. The spec actually allows the case for the datum being empty already (the Alonzo spec does forbid this explicitly though).

So all that needs to be done here is to document and expose this. Specifically, this line

∙  inputHashes ⊆ txdatsHashes

compares two ℙ DataHash, while in the original Alonzo spec it would have been ℙ (Maybe DataHash) (even though that spec is untyped). Here, a nothing gets just thrown out, while in the original spec the rhs could never contain a nothing so the lhs was forbidden from containing one either.

@williamdemeo can you add a small section to Ledger.Utxow explaining that & make sure that the figure showing UTXOW-inductive and getInputHashes are visible in the Conway spec? There's a NoConway environment that currently blocks the rule from being shown. This section should also reference CIP-69. I don't remember the status of the highlighting tool right now, but ideally the line inputHashes ⊆ txdatsHashes should be highlighted.

williamdemeo added a commit that referenced this issue Jan 15, 2025
@williamdemeo williamdemeo linked a pull request Jan 15, 2025 that will close this issue
4 tasks
@williamdemeo williamdemeo linked a pull request Jan 15, 2025 that will close this issue
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
conformance documentation Improvements or additions to documentation era: conway
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants