[0052] Extensible UDT

[XuJiandong]

Extensible UDT(xUDT) is an extension of Simple UDT for defining more behaviors a UDT might need. While simple UDT provides a minimal core for issuing UDTs on Nervos CKB, extensible UDT builds on top of simple UDT for more potential needs, such as regulations.

[phroi]

Hey Cryptape, iCKB here 👋 I was updating iCKB implementation from sUDT to xUDT and I stumbled upon an apparent inconsistency in the RFC:

• On mainnet xUDT is deployed and referenced by data1 with a zero lock.
• On testnet xUDT is deployed and referenced by type.

So my questions are:

1. Why keeping on testnet the reference by type when the implementation on mainnet cannot be updated? 🤔
2. Would it be possible to update the proposed RFC to reflect the reference by data1 for both? If not, why?

Keep up the Great Work,
Phroi

[XuJiandong]

Hey Cryptape, iCKB here 👋 I was updating iCKB implementation from sUDT to xUDT and I stumbled upon an apparent inconsistency in the RFC:

• On mainnet xUDT is deployed and referenced by data1 with a zero lock.
• On testnet xUDT is deployed and referenced by type.

So my questions are:

1. Why keeping on testnet the reference by type when the implementation on mainnet cannot be updated? 🤔
2. Would it be possible to update the proposed RFC to reflect the reference by data1 for both? If not, why?

Keep up the Great Work, Phroi

Done in 4c6c762

[xxuejie]

This part also confuses me: why does the xUDT spec make a choice to use data1(or actually any particular value of hash type?). To me, it is possible to make recommendations, but it should really be the decision of each individual asset to say if it wants to use data1 or type.

And to me it really is wrong to limit hash type to data1 for testnet deployment to get the same value as mainnet.

I get it that one contributing reason, is that the sole deployment of xUDT on mainnet was done without a type ID, but there is really no stopping for one to deploy an xUDT script by themselves with a type ID setup, then issue a new token using type as hash type. Are we saying those tokens are not xUDT tokens?

I do recommend that the spec shall not make decisions on the values of hash type used by an asset type.

[phroi]

The specification was not really clear on xUDT Data, so I dug a bit the code and I was shocked. While the molecule file has a definition for xUDT Data, no validation actually occurs in the xUDT code itself!! 🙀

This claim is easy to verify as:

• XudtData is not referenced in any other molecule definition.
• In all generated validating functions the string XudtData always appears in the generated function name.
• The string XudtData never appears in the xUDT code itself.

After the initial shock, I understood that this is a sensible decision as:

• To be 100% sUDT compatible xUDT Data rules cannot be possibly enforced in all cases.
• The XudtData rule enforcement is delegated to the Extension Scripts and Cell Lock who actually need them for locating their own data.
• In a way rule enforcement works similarly to the CoBuild rules enforcement.
• This leaves the possibility open for future standard improvements without changing xUDT code itself.

Side note: the molecule definition uses vector Bytes <byte>, but the actual Bytes should be free from such rules. For example no need for the Bytes header if the lock uses a static Struct.

[phroi]

As far as I can see, the intended a molecule representation of XudtData is the following:

// Bytes ...                                  // No Bytes definition as it's a placeholder for anything
option BytesOption (Bytes);                   // BytesOption can be of zero length
vector BytesOptionVec <BytesOption>           // This is a dynvec, some fields may have zero length
option BytesOptionVecOption (BytesOptionVec); // BytesOptionVecOption can be of zero length

table XudtDataTable {
  lock: BytesOption,                          // Possibly Empty
  data: BytesOptionVecOption,                 // Possibly Empty
}

option XudtData (XudtDataTable);

Considerations: in case there are no xUDT Script Extensions and Lock Script stores data as XudtData, the only overhead is the table header, so 12 bytes, is this correct?

@XuJiandong does this represent the intended xUDT behaviour? If so, could you please update the spec to reflect it?

[phroi]

@XuJiandong I was wondering: after the 16 bytes for amount and the XudtData table, is it allowed to have additional data? Or it's forbidden and it should be represented inside the XudtData table?

Example: a NFT data and metadata could be stored after the XudtData table. Does it makes sense or should be forbidden?

[XuJiandong]

@phroi All molecule issues can be found in this RFC. Excessive discussion of molecule specifics is not required in this RFC.

[XuJiandong]

Example: a NFT data and metadata could be stored after the XudtData table. Does it makes sense or should be forbidden?

It's not allowed. There's no need to store them after the table; they can safely be placed in the item of XudtData.data.