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

[zhangsoledad]

Discussed in https://github.com/nervosnetwork/ckb/discussions/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](https://github.com/nervosnetwork/rfcs/tree/master/rfcs/0043-ckb-softfork-activation) 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](https://github.com/nervosnetwork/rfcs/blob/master/rfcs/0034-vm-syscalls-2/0034-vm-syscalls-2.md#exec) syscall, `Spawn` saves the execution context of the current script, like [posix_spawn](https://man7.org/linux/man-pages/man3/posix_spawn.3.html), the parent script blocks until the child script ends. - [“A” Standard Extension](https://five-embeddev.com/riscv-isa-manual/latest/a.html), 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 https://github.com/nervosnetwork/ckb-vm/pull/321 In addition, the design of the new Spawn syscall and [Suspend/Resume](https://github.com/nervosnetwork/rfcs/blob/master/rfcs/0033-ckb-vm-version-1/0033-ckb-vm-version-1.md#33-suspendresume-a-running-vm) 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](https://github.com/nervosnetwork/rfcs/blob/master/rfcs/0044-ckb-light-client/0044-ckb-light-client.md#chain-root), 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, ```Rust 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 https://github.com/nervosnetwork/ckb/issues/4008

[github-actions[bot]]

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.

[eval-exec]

Hardfork (Meepo 2024) has activated on TestNet.
Ref: https://github.com/nervosnetwork/ckb/releases/tag/v0.119.0