A new hardfork for ckb is already being planned, and the following is a preview of the planned changes

[zhangsoledad]

Discussed in #3827

^{Originally posted by zhangsoledad February 9, 2023}
A new hardfork for ckb is already being planned, tentatively named 2023, and the following is a preview of the planned changes

1. In the current ckb consensus rules, the version field of the block header is reserved and only allowed to be 0. In the 2023 edition this reservation will be removed to allow for the use of RFC0043

2. The new version of vm, after the last hardfork introduced a new vm version, this time we will introduce vm version2 in the same way, which will bring the following features:

   • New syscalls Spawn, Get Memory Limit, Set Content will be added. The syscall Spawn is the core part of this update. The Spawn and the latter two syscalls: Get Memory Limit and Set Content together, implement a way to call another CKB Script in a CKB Script. Unlike the Exec syscall, Spawn saves the execution context of the current script, like posix_spawn, the parent script blocks until the child script ends.
   • “A” Standard Extension, strictly speaking “A” Standard Extension in ckb-vm does not bring functional changes, but many existing code will be compiled with Atomic Instructions and need to be patched, while ckb-vm can implement A instructions to eliminate such work.
   • Introduce new mops to optimize performance feat: Introduce new mops for version 2 ckb-vm#321

   In addition, the design of the new Spawn syscall and Suspend/Resume is not well adapted, and the processing logic for transactions with huge cycles will change, so we hope to make some optimizations.

3. We are considering adding live cells commitments, there are two alternatives to add live cells commitments, one is through a softfork, similar to the light-client protocol, using block extension, or by hardfork, adding a root field to the block header, we are weighing these two alternatives and looking at the scenarios that require it, suggestions and discussions are very welcome.

4. We are plagued by a naming problem, naming is really hard. In ckb,

Script {
    code_hash: "0x...",
    hash_type: Data | Type,
    args: "0x...",
},

The hash_type of Script has two kinds, one is Data(Data & Data1) and the other is Type, this naming is very disturbing to many ckb beginners, it is very difficult for beginners to correspond the name with the real meaning behind, the relationship between the two is actually very similar to IP and Domain Name, so we consider renaming Type to NameID, this is just a preliminary proposal, hope there are more proposals will be proposed, welcome to discuss!

[doitian]

Ready to preview in dev chain using the version #4008

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.