CKB 相关技术文章第三篇。

背景

CKB 的每一个交易在提交到交易池之前都会经过一个 script verification 的过程，本质上就是通过 CKB-VM 把交易里的 script 跑一遍，如果失败了则直接 reject，如果通过了才会继续后面的流程。

这里的 script 就是一种可以在链上执行的二进制可执行文件，也可以称之为 CKB 上的合约。它是图灵完备的，我们通常可以通过 C、Rust 来实现这些 script，比如 nervosnetwork/ckb-system-scripts 就是 CKB 上的一些常用的系统合约。用户在发起交易的时候就设置好相关的 script，比如 lock script 是用来作为资产才所有权的鉴定，而 type script 通常用来定义 cell 转换的条件，比如发行一个 User Define Token 就需要指定好 UDT 所对应的 type script。script 是通过 RISC-V 指令集的虚拟机上运行的，更多内容可以参考 Intro to Script | Nervos CKB。

大 cycle 交易的挑战

通常一个简单的 script 在 CKB-VM 里面执行是非常快的，VM 上跑完之后会返回一个 cycle 数目，这个 cycle 数量很重要，我们用来衡量 script 校验所耗费的计算量。一个合约的 cycle 数多少，理论上来说依赖于 VM 跑的使用用了多少个指令，这由 VM 在跑的时候去计算 VM Cycle Limits。

随着业务的复杂，逐渐出现了一些大 cycles 的交易，跑这些交易可能会耗费更多的时间，但我们总不可能让 VM 一直占着 CPU，比如在处理新 block 的时候，CPU 应该在让渡出来。但之前 CKB-VM 对这块的支持不够，为了达到变相的暂停，处理大 cycles 的时候我们可以设置一个 step cycles，假设我们设置为 100 cycles，每次启动的时候就把 max_cycles 设置为 100，这样 VM 在跑完 100 cycle 的时候会退出，返回的结果是 cycle limitation exceed，然后我们就知道这个 script 其实是没跑完的，先把状态保存为 suspend，然后切换到其他业务上做完处理之后再继续来跑。回来后如何才能恢复到之前的执行状态呢，这就需要保存 VM 的 snapshot，相当于给 VM 当前状态打了一个快照：

根据这个机制，我们老的 script 校验大交易的整个流程是通过一个 FIFO 的队列保存大交易，然后通过一个后台任务不断地从这个队列中取交易跑 VM，每次都跑 1000w cycle 左右，在这个过程中就可能切换出去，没跑完的交易继续放入队列等待下一次执行：

对应到代码就是 ChunkProcess 这个单独服务来处理的。由于 ChunkProcess 是一个单独的服务，它的处理流程和其他交易的处理流程是不一样的，这样会导致代码的复杂度增加，比如：

1. 要针对 ChunkProcess 里面的交易额外判断，例子 1, 例子 2
2. 暂停 / 恢复 ChunkProcess 处理的时候，需要对 ckb-vm 做相关的状态保存和恢复处理，参考结构 TransactionSnapshot, 代码比较复杂且容易遗漏，历史上也有过相关的 bug 1, bug 2, 以及安全问题。
3. 代码中包含重复逻辑，比如 chunk_process 里的 process_inner 和 _resumeble_process_tx。
4. 由于它只能同时处理一个大 cycle 交易，在 tx pool 本身比较空闲的情况下如果收到了多个大 cycle 交易也不能并行处理，比如 .bit 团队之前有过反馈他们通过本地 rpc 同时提交多个大 cycle 交易会比较慢的问题。

CKV-VM pause

这些问题的根本是 VM 只能通过 cycle step 的方式来暂停，有没有一种方式是我们任何时候想暂停就暂停，就是 event based 的方式。所以后来 CKB-VM 团队做了一些改进：

• ckb-vm 新的暂停方式
• feat: Add alternative snapshot design. #345
• Make ckb-vm thread-safety...