TIP-21 Serialization Primitives

[Wollac]

This RFC describes the serialization concepts in one document instead of scattered across all the RFCs.

Rendered Version

[luca-moser]

I think it would be useful if we can also add some notations for reflecting Subschema constraints such as lexical order or uniqueness in order to make the RFCs overall shorter. Currently these things are always written as separate list items under the table notation.

Perhaps something like anyOf(lexical, unique) and in cases such as a NativeToken set anyOf(lexical, unique(NativeTokenID)) as in "unique on the NativeTokenID" (which is a tighter constraint than just unique).

To fortify the case for lexical/unique, here a screenshot to show the duplication of information across the new output RFC:

[luca-moser]

In the current and next protocol we have cases where the byte array is denoted by a different type than uint32:

• Indexation feature block's tag bytes is denoted by a uint8
• Indexation payload (to be removed)'s index field is denoted by a uint16

Therefore I think it makes sense to change the notation from ByteArray to something which includes the length denotation type, perhaps something like <uint8,uint16,uint32>ByteArray as in "Variable Length Byte Array denoted by uintX". It might be clear that the length is meant in the notation, as the "ByteArray" name already implies an array of bytes and not of uintX.

[Wollac]

I am not sure this adds clarity. We've introduced the dynamic byte array as a primitive, so that it can be reused in various RFCs and this was also the motivation for using the fixed type of uint32. If this is no longer fixed and can vary, I would rather remove the dynamic byte array completely. In RFCs one would then introduce a new separate field Length and the array then has the type ByteArray[Length]. This is also how it is already done in the indexation payload in the message RFC.