CKB hardfork features（一）

从这篇开始，咱就开始剧透 ckb 在今年的硬分叉修改内容了，当然，其实这也算不上剧透，因为 RFC 仓库中的 PR 是公开的，修改内容都早已公示出去了，只是实现相对落后一点，从目前的进度来看，剩下还未实现的修改已经不多了，当然，除了实现，还需要大量的测试用来保证行为的正确性和一致性。

这篇主要介绍的是咱参与开发的第一个特性，允许在全网传播消耗 cycle 巨大的交易，这是对之前版本限制的放开，也是只有在 fork 版本打开才能达到全网通行的特性之一。

变化内容

严格意义上来说，这个修改并不属于 break change 范畴，只是它依赖于 hardfork 的 VM 功能，所以被捆绑到了 hardfork 之后。还有一个原因是虽然对大交易传播的限制并不是写在共识规则里，但它是写在 p2p 网络的链路里，只有在 hardfork 的时机，才有可能全网更新 binary 让特性能顺利全网通用。

在 ckb 主网上线之前，我们做了一个简单的测试，用户可以用一个非常大的交易让某些性能相对差的节点验证时间超时，即用大交易对某些节点 DDOS，让它无法正常跟上全网。随即，我们将全网默认允许执行的 cycles 做了限制，将其设定在 70_000_000 这个数字上，大致相当于一个交易验证上限在 10 分钟，具体是哪个类型的 CPU 执行时间，因年代久远已经丢失了，这就简单的对 DOS 攻击做了一个一刀切的限制，但这也限制了正常的大交易的传播，这也是上线期间的取舍。

本次 VM 升级带来了 resume/suspend 功能，即交易验证可以分段执行和挂起，不再是只能执行到无法执行为止了，这样的功能给上述的防 DOS 带来了新的解决方案，可以将这种不常见的大交易单独做一个验证通道，慢速执行，并且在其他地方需要计算资源的时候挂起执行，这样一来，既规避了 DOS 攻击带来的无法同步问题，又能移除不必要的限制，释放了 ckb 上业务的潜能。

设计与实现

交易执行的重点在于几个状态机的切换和交易插入队列的入口确定，以及对空闲时段的确定和大交易执行的挂起时机等等，相对来说功能不算复杂。

需要区分的是，交易来源及需要如何处理：

来源	处理方式	Fork 版本是否必须加上
RPC 提交	阻塞或挂起执行大交易	挂起方式不是第一版必须实现的，可以暂时忽略
Compact block	新鲜交易就地阻塞执行	与原有方式一致，不需要修改
Sync	交易就地阻塞执行	与原有方式一致，不需要修改
Relay transaction	将大交易插入分段执行队列，小交易阻塞执行	必须在 fork 版本实现

基于上述的变化，首先由咱做了一个 demo 版本，正常可用，然后由于咱对交易池的部分逻辑并不是特别清楚，在接入交易池的时候做得不是很好，又由 zhangsoledad 基于咱的实现重构了一版：PR，之后合入 ckb 主支的应该是重构之后的版本，至于咱的实现，在代码合入之后应该会被删除。