CIP-0025: Motivation and Asset Name Encoding about cips HOT 8 CLOSED

I'm closing this.

1. is still in the new version, reworded, but still confusing in my opinion. But I obviously could not make that clear.

2. is solved quite nicely with the byte strings used in Version 2. I like it a lot.

from cips.

But the “Update metadata link for a specific token” section makes quite clear that nothing like that is happening and the metadata can also be updated for tokens that have long been minted and sent away

Updating the metadata link is optional and you don't want it for most NFTs anyway. But imagine NFT are minted through a plutus script and these NFTs can be minted and burnt because it's part of some game. Now you burn that NFT, later you mint the NFT again with some new metadata. The history for that NFT still looks the same actually, so you have to make sure the NFT points to the latest available metadata.

The “Structure” section says: “This is true for version 1.0, future versions will use the hex encoding for asset_name.” Why, though?

Hex is more universal and there are projects who need to hex encode the asset name. This will lead to problems if the hex encoded asset name cannot be encoded to UTF-8. On the other hand all UTF-8 encoded asset name can easily be converted to hex. So hex is more flexible.
And the hex encoding is not meant for the asset name inside the metadata itself, but rather for the asset name of the token itself and the key in the metadata map. So you don't lose the human readability.

from cips.

But the “Update metadata link for a specific token” section makes quite clear that nothing like that is happening and the metadata can also be updated for tokens that have long been minted and sent away

Updating the metadata link is optional and you don't want it for most NFTs anyway. But imagine NFT are minted through a plutus script and these NFTs can be minted and burnt because it's part of some game. Now you burn that NFT, later you mint the NFT again with some new metadata. The history for that NFT still looks the same actually, so you have to make sure the NFT points to the latest available metadata.

I know. You didn't understand, what I have written. It makes absolutely no sense to have a lengthy paragraph in the Motivation on how every token can be traced back through it's transactions to find its minting transaction, when that is not, what is happening! The minting transaction is found solely via policy ID and asset name, not by tracing back, where that specific token came from (which would perhaps lead to different tokens with same policy ID, asset name, asset fingerprint having different metadata and would be super expensive, anyway).

The “Structure” section says: “This is true for version 1.0, future versions will use the hex encoding for asset_name.” Why, though?

Hex is more universal and there are projects who need to hex encode the asset name.

I know that, for example, SundaeSwap uses hex strings, which are not legal UTF-8 in their liquidity tokens. It's quite ugly, when wallet apps try to display them.

Should that really be allowed wanted for NFTs? CIP 25 is only relevant for them, not for every possible token that wants to save some bytes by also using non-UTF8 sequences.

This will lead to problems if the hex encoded asset name cannot be encoded to UTF-8. On the other hand all UTF-8 encoded asset name can easily be converted to hex. So hex is more flexible. And the hex encoding is not meant for the asset name inside the metadata itself, but rather for the asset name of the token itself and the key in the metadata map. So you don't lose the human readability.

What exactly do you want to do in that next version?

Shall the metadata.json be changed from

{
  "721": {
    "Metäl NFT": {
      […]
    }
  }
}

to

{
  "721": {
    "4d6574c3a46c204e4654": {
      […]
    }
  }
}

?

How shall this be converted to the actual CBOR metadata?

Do you want cardano-cli and other tools to make a special case for CIP 25 and interpret just the keys on the first level of a "721" metadatum differently and not encode it again, but take it as a string giving the actual hex values of the bytes written to the CBOR? (They already special case the top-level, taking the strings as representation for the transaction_metadatum_labels, which are uints. But doing it inside the metadatum structure is different, because not every transaction metadatum will want to give its first level keys as hex strings. So, cardano-cli and friends would have to distinguish by label (and version if version 1 CIP 25 metadata shall still be possible).)

Or should they continue to process it as any other string and write the bytes 3464363537346333613436633230346534363534 into the CBOR (doubling the space needed)?

If the latter is the case: Should 4d6574c3a46c204e4654 (doubly encoded to 3464363537346333613436633230346534363534) and 4D6574C3A46C204E4654 (doubly encoded to 3444363537344333413436433230344534363534) represent the same asset name? They just differ in case of the hex digits.

Also if the latter is the case: Should applications processing NFTs than look for all three possibilities – 4d6574c3a46c204e4654, 3464363537346333613436633230346534363534, and 3444363537344333413436433230344534363534 – when looking for the metadata of "Metäl NFT"? The first could still be there if the current version is used, the second and third would be the two possibilities for version 2. (Actually, there are more: Perople could mix lower and upper case hex digits. Bad style, but normally no problem for applications handling hex strings.)

from cips.

The minting transaction is found solely via policy ID and asset name, not by tracing back

That's because explorers already indexed their data. To actually build up that graph in first place you have to go from the first block to the last block...

How shall this be converted to the actual CBOR metadata?

I suggest you taking a look at: https://github.com/input-output-hk/cardano-ledger/blob/7f3339e1f98946cc6189c4e4f3c6b3884cbefc1a/eras/alonzo/test-suite/cddl-files/alonzo.cddl#L318-L323

Yes like this, where the hex string 4d6574c3a46c204e4654 is stored as bytes, and not as text as you described above.

{
  "721": {
    "4d6574c3a46c204e4654": {
      […]
    }
  }
}

from cips.

The minting transaction is found solely via policy ID and asset name, not by tracing back

That's because explorers already indexed their data. To actually build up that graph in first place you have to go from the first block to the last block...

Of course, they have to cache that information in some sort of database. It's important, what exactly they cache.

Take, for example, SpaceBud6206: https://cardanoscan.io/token/asset1gmpz5tpku56rxgj6kzsqqnjn2z63dc0ykxc06n?tab=minttransactions

Minted four times, burned three times (probably to correct some errors in the metadata).

If you trace back from the current holder to the mint transaction of the NFT currently in circulation (“Since tokens are always created in specific forging operations, we can always trace them back through their transaction graph to their origin.”), the mint transaction of this specific token is https://cardanoscan.io/transaction/273eb66eed462971c9a05be3ab322e0753fbeda80b88eee9f2cb2c8fb3063a2b at 2021-03-24 08:15:06 UTC (which is consistent, since it is the only one without a burn transaction shortly after).

But if we look at it in pool.pm https://pool.pm/asset1gmpz5tpku56rxgj6kzsqqnjn2z63dc0ykxc06n, it says “Minted 2021-03-23 17:02:53 UTC” (which is https://cardanoscan.io/transaction/cc0d4ffb000b4a420eb98f9f3ac4083088acb2db2d1c752ffe7ac72fb332cb7e, the very first mint transaction for that policy ID/asset name combination) and “Updated 2021-03-27 17:19:39 UTC” (which is https://cardanoscan.io/transaction/7b37bd31cf33c1e2e9005a97c3fe2d5544e92233b0754092187a9c36a4915c4e, the very last mint transaction for that policy ID/asset name combination) and they obviously take the metadata from that last minting.

So, they pretty clearly do not “trace them back through their transaction graph to their origin”, but just cache all mint transactions per policy ID and asset name in their database and take the metadata from the last one. It is used as a feature to repair metadata for NFTs that are already sold (and I'm sure the buyers like this feature, saving them the hassle of sending it back to be repaired). I'm pretty sure that Nami and all other wallet apps do exactly the same and it's fine.

Everything, I'm saying (now for the third time) is that the paragraph saying “Since tokens are always created in specific forging operations, we can always trace them back through their transaction graph to their origin.” should be deleted from the Motivation/introduction, since it is not what is happening. It's just confusing.

I suggest you taking a look at: https://github.com/input-output-hk/cardano-ledger/blob/7f3339e1f98946cc6189c4e4f3c6b3884cbefc1a/eras/alonzo/test-suite/cddl-files/alonzo.cddl#L318-L323

Yes like this, where the hex string 4d6574c3a46c204e4654 is stored as bytes, and not as text as you described above.

If you would take a look at; https://github.com/input-output-hk/cardano-node/blob/master/cardano-api/src/Cardano/Api/TxMetadata.hs#L286-L294

With a JSON like

{
  "721": {
    "4d6574c3a46c204e4654": {
      […]
    }
  }
}

the 4d6574c3a46c204e4654 is actually stored as CBOR text string (wasting a lot of space on the blockchain).

But the implementation actually has an expedient for my concerns: Just prefix the hex strings with 0x and cardano-cli and friends will encode them into CBOR bytes. (I didn't know that. So, thanks for being persistent enough to let me search the actual code!)

Since this is a breaking change, anyway, it should (for the next version of the CIP) probably also be done for the policy ID (a hex string), saving space and being semantically more appropriate.

And it should probably be explained in the CIP in some more detail, since we are currently arguing a lot about it and most people read less specs and code than either of us.

from cips.

Everything, I'm saying (now for the third time) is that the paragraph saying “Since tokens are always created in specific forging operations, we can always trace them back through their transaction graph to their origin.” should be deleted from the Motivation/introduction, since it is not what is happening. It's just confusing.

I get what you say. I added this paragraph initially because I just wanted to demonstrate that we have a unique link which can be established from the token being somewhere on the blockchain to the minting transaction. I have no problem removing it. People understand the idea of the link anyway.

Since this is a breaking change, anyway, it should (for the next version of the CIP) probably also be done for the policy ID (a hex string), saving space and being semantically more appropriate.

Good point👍🏻

from cips.

Hello @HeptaSean, @alessandrokonrad ,

I've read through this thread pretty closely and studied the CDDL schema, but I'm confused about the version2 schema changes. I'm mainly concerned about the differences affecting policy_id and asset_name.

If I have the following Version 1 metadata, how would it look in Version 2?

Version 1

• policy_id is a String. I think it represents the Hex encoded string of the blake2b hash of the policy script bytes without a 0x prefix
• asset_name is UTF-8 encoded String (therefore, this can be human readable and supports all Unicode characters)

{
  "version": "1.0",
  "721": {
    "a5ed39b2a8d0d6290266993eb94153dea112b76dc6a58332ff34b841": {
      "MyNFT": {
      […]
    }
  }
}

Version 2
Based on the CDDL, it says...

• policy_id is bytes
• asset_name is bytes

Therefore, my guess is that the policy_id of version 2 stays the same as version 1 and the asset_name is just converting the utf8 String bytes to hex encoded value and do not include the 0x prefix.

This is my guess of how the Version 1 example changes to Version 2.
I simply hex encoded the text MyNFT to get 4d794e4654 and left the policy_id value the same as in V1.

{
  "version": "2.0",
  "721": {
    "a5ed39b2a8d0d6290266993eb94153dea112b76dc6a58332ff34b841": {
      "4d794e4654": {
      […]
    }
  }
}

Another interpretation of version 2 is to hex encode each of the policy ID and asset name, but include the 0x prefix. Using that approach for the same example gives:

{
  "version": "2.0",
  "721": {
    "0xa5ed39b2a8d0d6290266993eb94153dea112b76dc6a58332ff34b841": {
      "0x4d794e4654": {
      […]
    }
  }
}

It feels like an example of how to apply version 2 would provide some clarity about how to interpret the CDDL. I appreciate anyone's thoughts!

from cips.

Another interpretation of version 2 is to hex encode each of the policy ID and asset name, but include the 0x prefix. Using that approach for the same example gives:

This is actually what is meant in version 2. Smaug just wrote a Twitter thread about it: https://twitter.com/SmaugPool/status/1615396143692644381

from cips.