Recommended Workflow for Script Upgrades

This article is based on ideas presented in this talk by Xuejie Xiao

We have introduced the Type ID upgradable code mechanism that enables us to build a Cell with a unique Type Script across all CKB Live Cells while maintaining the ability to modify this Cell.

This article outlines the recommended process for using Type ID Cells, adhering to the original principles of on-chain Script upgrades.

Workflow: Type ID + Lock Script

The key observation is that Lock Scripts can be changed in a Type ID Cell. This flexibility means that you don’t always have to use the same Lock Script. When upgrading a Type ID Cell, you can change the lock to leverage its flexibility.

The recommended workflow aligns well with the typical upgrade process, as outlined below:

1. Initial Deployment

When a piece of code is deployed for the first time, it’s unclear if it is free of bugs or if additional features will be requested after further interaction with the Script. At this stage, deploying the code with Type ID is preferable, as it allows for future upgrades. A multi-sig lock can be used at this point.

2. Iterative Upgrade

As development goes, the deployed code may undergo several upgrades using the “Type ID” design, addressing bug fixes and incorporating new features.

3. Final Code Freezing

Eventually we might reach a state where freezing the code is desirable, due to reasons like:

• Quirks in the deployed code have been sufficiently understood with enough confidence gained in the code stability
• A significant amount of assets are controlled by the code, bringing high risk if the code is changeable.

At this stage, one can perform a final upgrade on the Cell by simply altering the Lock Script to “unlockable”—to freeze the code. This way, even though the Type ID setup is still present, the Cell can no longer be modified. In other words, Type ID alone does not imply that the stored code is mutable—the Lock Script also plays a critical role in this process.

This recommended workflow addresses two distinct roles:

• For Script developer: A Script developer can choose to deploy a piece of code in an upgradable Cell using the "Type ID" Script.
• For dApp developer: It is entirely up to the actual dApp developer to decide whether to reference the deployed code using the "Type ID" approach.

These two roles are completely independent, offering flexibility in how upgrades and references are managed within the system.

An Example

Assume someone deployed UDT (User-Defined Token) code with a Type ID setup on-chain. Suppose two tokens are issued using this UDT code, where:

• UDT A uses a Type Script with type as its hash_type.
• UDT B uses a Type Script with data2 (a data variant) as its hash_type.

If the UDT developer upgrades the UDT code from Version 1 to Version 2, then:

• UDT A will immediately adopt Version 2
• UDT B will continue using Version 1, ignoring the new version of the code.

One might say that Version 1 is no longer present in a Live Cell, but that does not mean Version 1 is unusable. There are several options for retaining access to Version 1:

• By tracking the CKB chain history, one can locate the original Version 1 of the UDT code, redeploy it in a new Cell, and use it for subsequent operations.

• A fully developed ecosystem might also have a lending system aiding these requirements. Additionally, there is an interesting possibility to consider: While a Script currently locates code within a dep Cell, there has been historical discussion around allowing a CKB transaction to temporarily store code within the witness structures. If there is enough interest in this idea, CKB could potentially reintroduce this feature in the future.

Conclusion

This article introduced the original design workflow for implementing an upgradable Script using Type ID. By leveraging Lock Scripts strategically, developers can establish a structured and iterative approach to build decentralized Scripts on CKB, ensuring both flexibility and security.