-
Notifications
You must be signed in to change notification settings - Fork 318
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
CIP-???? | No Datum Is Unit #364
Conversation
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.
This suggestion has been made a number of times before. I'm reluctant to adopt it for the reason listed here: #309 (comment)
|
||
## Specification | ||
|
||
When trying to consume a utxo without a datum hash or an inline datum, the node would substitute a unit datum as an argument instead. |
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.
This is not sufficiently specified. "unit datum" is not a thing. What value of type Data
are you proposing?
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 could be anything, really. I am personally split between List []
and I 0
. In a future where we accept this proposal, which would you like this to be?
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 disagree with using something like unit at all, see the linked comment. I would prefer something like Maybe X
, but then again we have a representation problem.
I honestly don't see the point in this CIP. It's a very minor space optimisation that is arguably not clean. |
This proposal falls under the Plutus' umbrella and seems to not be deemed as receivable. As discussed in today's editors meeting, we see two possible ways forward:
|
Probably I should write a CPS about this where I lay out some of the questions that need to be answered by proposed solutions. |
That would be great -- I can close this PR or mark it as a rejected solution, although I would like to get some more insight as to why, @michaelpj, using a default value that could be supplied using a datum would be a bad design decision. (as in the linked PR) Is there a case where this value being present, in a script-locking context, where it would otherwise be locked forever, be a bad thing? |
@zygomeb since nothing has come of this since the Plutus team at the time deemed it "unreceivable" it's not likely that this could go anywhere today: therefore closing this as |
This CIP is a simple quality of life change. It defines a default interpretation of a utxo with no datum (defaulting to
()
) for the purposes of scripts that were either erroneously created or make no use of datums.(draft proposal in branch)