Skip to content
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

Discussion about the hash_type of xUDT script on testnet #2072

Closed
Flouse opened this issue Jul 17, 2024 · 6 comments
Closed

Discussion about the hash_type of xUDT script on testnet #2072

Flouse opened this issue Jul 17, 2024 · 6 comments
Assignees
Labels
enhancement New feature or request

Comments

@Flouse
Copy link

Flouse commented Jul 17, 2024

�Description

The current xUDT on pudge.explorer.nervos.org

image
https://pudge.explorer.nervos.org/scripts#xUDT

The latest xUDT deployment in RFC-0052 is

image

See https://github.com/nervosnetwork/rfcs/blob/abeb01be8c0b1491ac8a1ab3908416e9ab3cc432/rfcs/0052-extensible-udt/0052-extensible-udt.md#deployment

Describe the solution you'd like

Maybe both the above scripts could be interpreted as xUDT on ckb-testnet-explorer.

Describe alternatives you've considered

Revert the hash_type of xUDT back to type in the latest RFC docs.
cc @XuJiandong

References

@Flouse Flouse added the enhancement New feature or request label Jul 17, 2024
@Flouse Flouse changed the title Discussion about the hash_type of xUDT script Discussion about the hash_type of xUDT script on testnet Jul 17, 2024
@XuJiandong
Copy link

XuJiandong commented Jul 17, 2024

The current xUDT description on pudge.explorer.nervos.org should use data1 instead of type. It's not upgradeable.

nervosnetwork/rfcs#428 (comment)

@Keith-CY Keith-CY self-assigned this Jul 17, 2024
@Keith-CY
Copy link
Collaborator

I noticed that only code hash and hash type were updated in the RFC while the tx hash is not(nervosnetwork/rfcs@4c6c762)

So the script is still deployed at https://pudge.explorer.nervos.org/transaction/0xbf6fb538763efec2a70a6a3dcb7242787087e1030c4e7d86585bc63a9d337f5f outputs[0]

Its data hash matches 0x50bd8d6680b8b9cf98b73f3c08faf8b2a21914311954118ad6609be6e78a1b95, but its type script is of type id and the owner lock is of secp256_k1.

How is the upgrade disabled?

@XuJiandong
Copy link

It's for historical reasons. When it was first deployed on the testnet, we wanted it to be upgradable to fix potential bugs. However, once this final version is deployed, it will not be upgraded.

@Keith-CY
Copy link
Collaborator

It's for historical reasons. When it was first deployed on the testnet, we wanted it to be upgradable to fix potential bugs. However, once this final version is deployed, it will not be upgraded.

Got it, the script is upgradable but won't be updated anymore.

The script can be referenced by type hash or data hash, and only data hash is suggested and mentioned in the RFC. Am I right?

@Keith-CY
Copy link
Collaborator

Keith-CY commented Jul 17, 2024

The reference info of type hash and data hash will be listed simultaneously
image

Because most on-chain use cases are based on type hash

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants