-
Notifications
You must be signed in to change notification settings - Fork 159
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[0052] Extensible UDT #428
Conversation
Co-authored-by: Flouse <1297478+Flouse@users.noreply.github.com>
Co-authored-by: Flouse <1297478+Flouse@users.noreply.github.com>
Co-authored-by: Flouse <1297478+Flouse@users.noreply.github.com>
Co-authored-by: Flouse <1297478+Flouse@users.noreply.github.com>
Co-authored-by: Flouse <1297478+Flouse@users.noreply.github.com>
Co-authored-by: Flouse <1297478+Flouse@users.noreply.github.com>
Co-authored-by: Flouse <1297478+Flouse@users.noreply.github.com>
Co-authored-by: Flouse <1297478+Flouse@users.noreply.github.com>
Co-authored-by: Flouse <1297478+Flouse@users.noreply.github.com>
Co-authored-by: Flouse <1297478+Flouse@users.noreply.github.com>
Co-authored-by: Yukang <moorekang@gmail.com>
Co-authored-by: Flouse <1297478+Flouse@users.noreply.github.com>
Co-authored-by: Flouse <1297478+Flouse@users.noreply.github.com>
* rename XudtWitnessInput to XudtWitness * raw_extension_data and extension_data are not correlated. The extension_data has a new section * behavior of multiple instances of the same extension script * some wording
Hey Cryptape, iCKB here 👋 I was updating iCKB implementation from sUDT to xUDT and I stumbled upon an apparent inconsistency in the RFC:
So my questions are:
Keep up the Great Work, |
Use `data1` instead of `type`
Done in 4c6c762 |
This part also confuses me: why does the xUDT spec make a choice to use And to me it really is wrong to limit 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 I do recommend that the spec shall not make decisions on the values of |
The specification was not really clear on This claim is easy to verify as:
After the initial shock, I understood that this is a sensible decision as:
Side note: the molecule definition uses |
As far as I can see, the intended a molecule representation of
Considerations: in case there are no xUDT Script Extensions and Lock Script stores data as @XuJiandong does this represent the intended xUDT behaviour? If so, could you please update the spec to reflect it? |
@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? |
It's not allowed. There's no need to store them after the table; they can safely be placed in the item of |
The deployment of xUDT on Testnet is TypeId according to the Cryptape blog and almost Dapps/Wallets/Explorer are using the version with TypeId, see https://pudge.explorer.nervos.org/scripts. I'm confused about why the RFC document ultimately chose version data1, given that very few projects in the ecosystem use this version. |
This two versions ( |
@duanyytop I'd like to point out that supporting both For example a XUDT referenced by Another issue that may arise is that some platforms will support only Both these issues will create ecosystem fragmentation:
Hence my previous question on the reason of supporting both reference in the RFC. |
Personally, I would disagree with this. To me, it is an unfortunate fact that some platforms only support one value of The deployment of a script code(whether the cell contains the actual code for a script uses type id or not), is actually decoupled from the fact how another will use such script code. The developer of a CKB script code can deploy their code with type ID enabled, but it is not necessarily the fact that others will have to use the type ID. To me it is perfectly normal to use And yes, the same CKB script code referenced using |
Since so far seems that we are going for both versions, I asked Lumos if they could integrate the testnet |
Hooray! 🚀🚀🚀 |
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.