CIP25 V2 - why is policy and token name not hex encoded bytes, rather than raw bytes? about cips

[KtorZ]

hex-encoded byte strings are no longer byte strings, they are text strings. Hex encoding is meant to turn any raw binary data into something that is text-friendly using a restricted alphabet (and so are base32, base58, base64 and other similar encoding).

What is ultimately stored on the blockchain are not hex-encoded text strings, it's raw bytes (as in, an array of unsigned integer values spanning over 8 bits, or simply put, u8). The main reason being that (a) it's a lot more compact and (b) it's a lot more flexible. Programs have many efficient primitives to deal with byte buffers; working with text strings however is usually inefficient.

[Tenancio]

@KtorZ Thanks for that reply, it has answered my question!

@rphair I think now I understand more an example is probably not necessary.

Thanks for your help!

[thaddeusdiamond]

I will let @alessandrokonrad and @KtorZ weigh in but in my opinion bytestrings are preferred to hex encoded bytestrings so that flexible encodings can be specified. That said, that would probably require an encoding field in the CDDL which I do not see so if policy ID and asset name are only ever referenced as hex encodings in the spec, I think that change could be made.

As for the asset name specifically I know @alessandrokonrad has done work on CIP-0068 that requires linking assets via naming conventions which had some delimiter constraints (using a bytearray sequence), so that is why the raw bytes there.

[rphair]

cc @alessandrokonrad @thaddeusdiamond @KtorZ

[rphair]

@Tenancio the last response seems complete... does this answer your question properly? Or do you still think it's important that a "real world example" be included in the CIP? It seems to me that the example isn't necessary because people will generally understand what's meant by a sequence of bytes (and I don't see how an example could be chosen to generally represent a sequence of unsigned 8-bit values anyway).