Currently there are two deployment modes on CKB, one is through data_hash (not upgradeable), and the other is through type_id (can be upgraded).
However, there is a type of script (like UDT script) code that plays a critical role in the ecosystem. The community may hope that this code cannot be easily upgraded, but if there is technological progress, this code should be able to be upgraded.
I think the best way is to add a deployment method. The script is deployed through type_id, which is an upgradeable mode, but its upgrade must be through a hard fork, not some multi-signature verification.
Or just make type script unupgradable. Even if a bug is found in a type script, affected user assets are still protected by (various of) lock scripts, so the real impact is not the same as, e.g. on Ethereum where all ERC20/ERC721 tokens are pooled together. As long as the lock scripts are secure it buys time for type script developer (or community) to devise a rescue plan. Layered defense.
Then for such unupgradable type scripts a necessary piece is migration plans - how can type script v1 cells upgrade to v2 in case of emergent or normal upgrade?
For assets like Spore, unupgradable type script not only means the asset is as immutable as a hard metal in physical world, it also brings vintages and antiques into the digital world - a good old v1 Spore could have higher value than a 2024-edition v42 Spore
Not all scripts can be solved with new deployments. For some scripts, migration is painful, and due to the abstraction of CKB, many things that should have been implemented at the chain level are moved to the script level. For some scripts , it is reasonable to use hard forks to control upgrades.
the issue with this approach is application-level considerations become consensus-level considerations and establishing this norm may change the way people think about CKB.
One of the goals of CKB’s design was to minimize the need for hard forks- application-level concerns will complicate L1 governance and may motivate hard forks that would otherwise be unnecessary.
Every hard fork increases the authority of the group(s) initiating and implementing it, while a lack of fork moves things further toward no group having this kind of role.
Those scripts may consider using a homebrew or shared on-chain governance as the code cell lock, which can be more flexible, more interest aligned, and off load hardfork burden from L1 consensus. I’m looking forward to seeing more onchain governance scripts/dapps build on CKB.
The trustless specturm looks like (from less to more trustless):
