CIP-0068 | Make more economic and contract-friendly

[szist]

These suggestions are coming from trying to implement the standard for an aggregator for token metadata.

Adds metadata batching options to the proposal and extends the documentation by explicitly mentioning datum inlining.

FYI @alessandrokonrad

[rphair]

@szist the title change is because:

1. (for the editors' sake) I took [WIP] out of the beginning to keep our list easily scannable;
2. (for your stated purposes of discussion) I left the [WIP] out entirely since CIP-0068 was a long time in the making, so the kinds of updates you're proposing would naturally have to be up for vigorous review and would likely be edited many times as a matter of course (so "work in progress" goes without saying).

Please get anyone with whom you've discussed these ideas to contribute here while we wait for @alessandrokonrad to weigh in. 😎

[szist]

Please get anyone with whom you've discussed these ideas to contribute here while we wait for @alessandrokonrad to weigh in. 😎

Thanks.

😰 I haven't really discussed it with anyone really, wasn't sure what was the right platform or way. The CIP discord categorically said, things should be discussed on github.

[rphair]

@szist in case it emerges in this discussion that what you are suggesting is beyond the scope of CIP-0068, and especially if all you end up with is a goal or problem definition without a specific solution, we have a new category called Cardano Problem Statement (CPS) on the way as described in this late stage draft (via #366): https://github.com/cardano-foundation/CIPs/blob/cip-cps-rework/CIP-9999/README.md

[alessandrokonrad]

Hey @szist CIP-0068 doesn't have versioning per se. What you try to change here is the sub standard 222 for NFTs.
All your concerns are valid, but have trade-offs too. Your introduced version 2 may change the 222 standard too much that it would make sense to create a new sub standard with a different label (CIP-0067).
I see your idea is to batch multiple reference NFTs into a single UTxO to save costs and be more economic. That's fair and makese sense for some projects, but it also increases execution units quite a bit in the plutus validator. Hence I would create a new substandard for batched reference NFTs.

datum = #6.122(multiasset)

Using the cbor constructor as a versioning mechanism is an interesting idea, but I feel like you lose a bit of flexibility. It's also harder to make use of that in contract languages where you don't have explicit access to the constructor index and type casting happens automatically in the back (e.g. Aiken, Helios)

missing recommendations around inlinening datum in utxos

This again also has trade-offs and I think you stated it correctly in your PR. We could include that paragraph into CIP-0068, but the idea and usage around inline datums is described in CIP-0032 already.

the metadata for NFTs/FTs is not enforced. Ideally it should for better contract support (e.g. decimals for FTs) and use a similar keyed struct as the tx body

What do you mean with is not enforced?

[szist]

Hey @szist CIP-0068 doesn't have versioning per se. What you try to change here is the sub standard 222 for NFTs. All your concerns are valid, but have trade-offs too. Your introduced version 2 may change the 222 standard too much that it would make sense to create a new sub standard with a different label (CIP-0067).

Not necessarily just for NFTs. If you consider DEXes with liquidity pools - on Minswap, Sundaeswap and WingRiders - currently all are using LP tokens. Identifying these lp tokens in the wallet is a very bad UX, unless they were minted with the cip-25 (infeasible in the case of Min/Sundae as they are dynamically minted, I think) tags or provided with offchain-metadata (pain).

I see your idea is to batch multiple reference NFTs into a single UTxO to save costs and be more economic. That's fair and makese sense for some projects, but it also increases execution units quite a bit in the plutus validator. Hence I would create a new substandard for batched reference NFTs.

datum = #6.122(multiasset)

Worth considering :). What is the use-case you were considering to use these reference UTxOs for in relation to NFTs? royalties?

Using the cbor constructor as a versioning mechanism is an interesting idea, but I feel like you lose a bit of flexibility. It's also harder to make use of that in contract languages where you don't have explicit access to the constructor index and type casting happens automatically in the back (e.g. Aiken, Helios)

I view that more of a shortcoming of those platforms. Versioning should be an integral part of datum design (Imagine using the same datum format across multiple contracts like oracles. If you change something, it's the most straightforward way to do it.). But it's an off-topic discussion

missing recommendations around inlinening datum in utxos

This again also has trade-offs and I think you stated it correctly in your PR. We could include that paragraph into CIP-0068, but the idea and usage around inline datums is described in CIP-0032 already.

Sure, but in my experience if it's not part of the tooling or considered during design, people will just use whatever. Even that's not a guarantee (just look how cip25 is not followed by most tokens, required fields missing, etc.). I would much prefer having some recommendations at least, so people actually consider it and not just use whatever random option the given tool gives them.

the metadata for NFTs/FTs is not enforced. Ideally it should for better contract support (e.g. decimals for FTs) and use a similar keyed struct as the tx body

What do you mean with is not enforced?

As in plutus data format. With Exact positioning without the need to parse through generic data format just to find some property in smart contracts. E.g. imagine metadata this way (I've chosen arbitrary columns to be selected :/ don't put any weight on them at this point):

data FTTokenMetadata = FTTokenMetadata {
  name :: !BuiltinByteString
  decimals :: !Integer
  totalSupply :: !Integer
  properties :: Map BuiltinData BuiltinData
}

This way the data - that would be used with highest possibility by smart contracts (like oracles), would be available more easily through field accessors, instead of parsing through a generic metadata format and finding the "string" keys you are actually interested in.

[alessandrokonrad]

Worth considering :). What is the use-case you were considering to use these reference UTxOs for in relation to NFTs?

Have a way to dynamically update the metadata based on some other validators for instance, giving the NFT holder the rights to update certain fields etc. But also to keep the datum small so it can be referenced with not too much costs in other validators.
Having multiple reference NFTs in a single UTxO makes this certainly more difficult, especially if you want to give a certain holder the rights to update a field in the metadata.

I view that more of a shortcoming of those platforms. Versioning should be an integral part of datum design

I don't think the cbor constructor has anything to do with versioning and should not be confused with the actual constructor of the contract language, that's why you have the extra field with the version.

Sure, but in my experience if it's not part of the tooling or considered during design, people will just use whatever. Even that's not a guarantee (just look how cip25 is not followed by most tokens, required fields missing, etc.). I would much prefer having some recommendations at least, so people actually consider it and not just use whatever random option the given tool gives them.

Since there wasn't set any constraint in CIP-0068 (or the substandards specifically) people can choose between inline datum or hash only. Both are acceptable. But yeah for the sake of clarity we can add a recommendation. I personally have been using both already.

As in plutus data format. With Exact positioning without the need to parse through generic data format just to find some property in smart contracts. E.g. imagine metadata this way (I've chosen arbitrary columns to be selected :/ don't put any weight on them at this point)

That's what I wanted to do initially. Ensuring exact positioning is hard especially if there are optional parameters. Also if you want to add extra entries you lose the key names. 3rd parties have to find them somewhere first, which makes the whole process a bit cumbersome.

[KtorZ]

Given that the CIP is still in a Proposed state, wouldn't it make sense to incorporate the changes -- when they 'make sense' -- to it rather than introducing a new version already? This would likely invalidate existing experiments that have been conducted, but for the sake of better future-proofing it?

[rphair]

@KtorZ some of these would also be reasons to rephrase this as a CPS, in case there's trouble reconciling this with CIP-0068 directly (reiterating my suggestion here, since I missed my chance to say this at today's CIP meeting)

[alessandrokonrad]

Given that the CIP is still in a Proposed state, wouldn't it make sense to incorporate the changes -- when they 'make sense' -- to it rather than introducing a new version already? This would likely invalidate existing experiments that have been conducted, but for the sake of better future-proofing it?

I think the primary concern/idea of this proposal is to allow for multiple reference NFTs in a single UTxO instead of only one NFT. Which makes sense, but also has trade-offs. You need to store more data in the datum and if you have just one reference NFT then it's one additional lookup and you need to store additionally the policyid and asset name in the datum, which increases cpu/mem.

[szist]

I will try to incorporate the changes till eow. Not all of them are breaking. Differentiating between bulk and single-utxo holders could make sense :). I will try to restructure this, so it's basically an extension and not a full new version, nor a full CPS. If any leftovers remain after that, we can do a CPS/new version.

[szist]

I don't think the cbor constructor has anything to do with versioning and should not be confused with the actual constructor of the contract language, that's why you have the extra field with the version.

I very much disagree with this. Constructor could have a lot to do with versioning, it was also one of the original intends for it afaik when designing these data representation. Adding/removing fields together with bumping the constructor index could be a flexible pattern. It gives you separation of concerns. Consider an oracle use-case where you identify oracle utxos through tokens. In theory the provider could replace the validator scripts, but not change the data format. When they add a new field, they could just bump the constructor index while leaving in the same identifier token, same validator. Or you could add a version in the datum and have a generic structure, but that would make parsing and accessing oracle fields much more expensive. Sure, you could add additional logic that every new version would require new oracle identifier tokens. Anyhow, it's a similar case here. If the formats are well-defined (not a generic structure), then versioning through index could make sense.

Anyhow that would be a much heavier change to the proposal, so I'm going to leave it out.

[szist]

The changes are very opinionated and I'm more looking to raise issues and discussion than actually proposing final
changes. Most changes should be self-explanatory. The issues I considered, but not all are incorporated:

• having 1 UTxO per reference token is not very economic
• losing minADA on NFTs is undesirable
• versioning could be done through the datum constructors
• missing recommendations around inlinening datum in utxos
• allow multiple reference tokens in a single utxo
• the metadata for NFTs/FTs is not enforced. Ideally it should for better contract support (e.g. decimals for FTs) and use a similar keyed struct as the tx body

From the original suggestions I left out versioning. Even though it's less efficient from the contracts standpoint, the additional flexility could be beneficial. I've also left out enforced positional types for the metadata - again it would help with contract efficiency at the cost of flexibility as pointed out by @alessandrokonrad .

In case of an NFT series the publisher costs can be minimized by batching all reference tokens into a single utxo and providing the datum through a hash, when sending it to an unspendable script address. This will reduce the costs to ~1 ADA currently.

[alessandrokonrad]

The changes are very opinionated and I'm more looking to raise issues and discussion than actually proposing final
changes. Most changes should be self-explanatory. The issues I considered, but not all are incorporated:

• having 1 UTxO per reference token is not very economic
• losing minADA on NFTs is undesirable
• versioning could be done through the datum constructors
• missing recommendations around inlinening datum in utxos
• allow multiple reference tokens in a single utxo
• the metadata for NFTs/FTs is not enforced. Ideally it should for better contract support (e.g. decimals for FTs) and use a similar keyed struct as the tx body

From the original suggestions I left out versioning. Even though it's less efficient from the contracts standpoint, the additional flexility could be beneficial. I've also left out enforced positional types for the metadata - again it would help with contract efficiency at the cost of flexibility as pointed out by @alessandrokonrad .

In case of an NFT series the publisher costs can be minimized by batching all reference tokens into a single utxo and providing the datum through a hash, when sending it to an unspendable script address. This will reduce the costs to ~1 ADA currently.

I think this is a good compromise and that looks good to me👍🏻

[rphair]

@szist this has become grossly out-of-date with respect to CIP-0068. Is it safe to assume due to your #382 (comment) that this can also be closed?

[rphair]

OK @szist please let us know if you will be continuing work on this... and if @alessandrokonrad or @KtorZ know of anyone who would be interested from the community or perhaps the CF then please I hope they might also be suggested here.