CIP-???? | No Datum Is Unit #364
Conversation
There was a problem hiding this comment.
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.
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.
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.
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? |
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)