以一个开发者视角来看 ckb 2021 的 hardfork 内容(二)

上一篇说到了 cycles 的限制被打开了,对后续引入各种稀奇古怪的加密算法有重大利好,除了算法,有没有可能有其他的应用场景呢,这里我就稍微提一个拍脑袋的想法:

开发者需要在链上存一个巨大的表数据,我们都知道 ckb 链上想存数据就要付出对应的 byte 费用,一比一兑换,童叟无欺,但有没有可能骗一下这个机制呢,其实是有的,尤其是在 cycles 上限被打开的时候,先上传一个 7z 或者 gzip 等压缩算法库,然后将巨大的表压缩之后上传,每次使用的时候解压缩,这无疑是提高了每次交易的 cycles,但它降低了 ckb 的占用数,一种 native 的时间换空间方案,但要记得,ckb-vm 在运行时是有上限的,4M 的空间,不存在 swap 区,也就是数据展开之后最大也就只能用 4m 不到的空间,不然就爆掉了。

接下来说说网络相关的东西。

网络算是 hardfork 首当其冲要解决的问题,它主要是:

  1. 包含 hardfork 版本的客户端必须兼容之前所有版本实现,并且在走过 hardfork 时点后,主动断开所有旧版本客户端的连接,并永久拒绝任何旧版本客户端的连接
  2. 由于不同版本的 VM 对同一个 script 的执行可能得出不同的 cycles,必须以 VM 切换为时点,清理不符合的验证版本,让它不会在网络中传播导致节点被 ban
  3. 考虑到新块广播是以 gossip 方式在网络上传播的,势必会存在一个时点网络上的节点处于半分裂状态,即有些跨过了 hardfork,有些还没过去,对于有能力跨过但尚未跨过的客户端,需要让它有能力有空间同步上来,而不是当成无效节点断开连接
  4. 对于临时加入的有能力跨过 hardfork 的客户端,不能因为 hardfrok 已经过去了很久而拒绝它
  5. 动态切换过程中,不能因为任何原因导致分裂

因为底层 Tentacle 库的支持,很大程度上避免了无法挽回的符号位占用问题,用框架提供的版本管理功能,就可以轻松迁移大部分协议。

ckb 的网络协议林林总总加起来大概有七八个,每一个都可以独立打开,虽然如果不开核心协议 sync 的连接会定时被清理,但它终究是赋予了可以单独开任何协议的可能性,为了兼容旧客户端并彻底堵死 hardfork 之后被旧客户端连接的可能性,所有协议都必须在这次变化中以兼容模式升级版本,即 hardfork 版本下支持打开版本 1,2 协议,当 hardfork 时点过去后,ckb 将再发一个版本,清理掉这些兼容代码,用一种非常清爽的方式将网络的冗余代码删除。

唯一特殊的升级在于 relay 协议,这个协议涉及到交易广播,因为 VM 版本不同而导致 cycles 可能不一致,那么单纯的兼容升级就无法使用了,因为节点无法保证对端状态是否与自己一致,如果不一致,交易广播的行为就可能导致网络分裂,于是需要一种相对复杂的方式升级,即同时挂载两个行为互斥的 relay 协议,严格限制他们互斥的使用时间点,让处于任何时点的客户端只能接到对应时点的交易,避免网络分裂问题。

PR:https://github.com/nervosnetwork/ckb/pull/2796

原文:CKB hardfork features(三) 略有修改

1 Like