在 hardfork 之后 ckb 的虚拟机(ckb-vm)也将会升级到一个新版本, 从 version 0 升级到 version 1, 包括性能提升，错误修复, 以及增加新的 RISC-V 扩展, 当然升级不应该破坏旧的代码，用户需要有选项来指定虚拟机的版本。
我们在 RFC32 提出了一个方案，让用户如何来选择 ckb-vm 版本:
我们将会通过硬分叉进行升级, 下一个预定的硬分叉是 ckb2021，会从一个特定的 epoch 开始激活。对于激活 epoch 之前的区块中的所有交易，还是按照 ckb-vm 0 版本来验证所有交易的脚本, 在这些交易中，lock script 和 type script 中的 hash_type 序列化后对应的值是 0 或 1
在 ckb2021 被激活后，用户可以通过不同的 hash_type 给每个脚本选择 ckb-vm 版本, hash_type 的值将会增加一个数值: 2
hash_type |
matches by | VM version |
|---|---|---|
| 0 | data hash | 0 |
| 1 | type script hash | 1 |
| 2 | data hash | 1 |
在 ckb 提供的 json rpc 中, hash_type 是枚举值, 在激活后也将会添加一个 “data1”
- 0: “data”
- 1: “type”
- 2: “data1”
关于 hash_type 更多的信息可以参考 [rfc22]
因为 ckb-vm 版本选择取决于交易属于哪个 epoch，所以在激活点附近的前几个区块，仍然在 tx pool 中的交易来说，它不是确定性的。CKB节点必须运行两个版本的 relay 协议, 关于这点可以参考 [rfc35]
除此之外, 如果想了解 ckb-vm version 1 具体包括了哪些改动, 请参考 [rfc33] 和 [rfc34]