一种可更新的script插件集(Extensible Script)

中文 CKB 开发与技术讨论
1

可更新的脚本插件集（Extensible Script）

在看了看 RFC: Extensible UDT后，发现xUDT的xudt args存在于用户的Typescript中，从而导致xUDT在一开始就需要决定使用哪些扩展，而很难中途去添加或者删除扩展，因为很难让所有用户的Cell都同时更换typescript的args。
在与@kylexu沟通后，我们想到一种可更新的脚本插件集，但目前只有idea。

出于监管目的或者规则更新的需要，或者解锁逻辑的增删，脚本管理者有时需要在原来的逻辑上动态增添逻辑，目前已有的代码更新是通过全局唯一的typescript以及type字段来实现，但是这种思路适用于代码更新，但不适用于动态的增减插件。

本方案也借助将TypeID，同时结合了xUDT的思路（copy了许多文字）。

数据结构

符合xScript的Cell数据结构可如下所示：

用于typescript时：

data:
    <issuer_defined> 
type:
    code_hash: extensible_script type script
    args:  typescript hash
lock:
    <user_defined>

用于lockscript时:

data:
    <issuer_defined> 
type:
    <user_defined>
lock:
   code_hash: extensible_script type script
   args:  typescript hash

你可能注意到script的args不再是Owner lockhash，而是变成了一个typescript hash，那么这个typescript hash意味着什么呢？

每个想要利用可更新的脚本插件集的发行方，都需要用Type ID发行一个plugins Cell用于存放所有的插件，该plugins Cell使用TypeID以保证全局只有一个cell拥有该typescript，这个typescript的hash就是用户typescript的args域的值。

extensible_script执行时，会在dep cells里寻找一个typescript hash与args一致的cell，该cell即为plugins cell，如果找不到这样的cell，则返回错误。

该typescript全局唯一的plugins Cell的数据结构可如下：

data:
    <xscript flags> <xscript data>
type:
    code_hash: type ID script
    args:  type ID args
lock:
    Owner lockhash

xscript flags是一个四字节的标记：

  • 如果flags全部为0，则不对脚本做任何验证
  • 如果flags是0x1，那么那么扩展数据将包含一个以 ScriptVec 结构进行序列化的 molecule，并且需要所有的script全部验证成功，该typescript才验证成功。
  • 如果flags是0x2，那么那么扩展数据将包含一个以 ScriptVec 结构进行序列化的 molecule，只需要任意一个script验证成功，该typescript即验证成功，具体验证哪一个，可以在Witness的里指定，由xScript脚本选择。
  • 如果flags是0x3，扩展数据将包含前一节解释的 ScriptVec 结构的 blake160 哈希。实际的 ScriptVec 结构数据将包含在当前交易中包含的 witness 中，但验证逻辑类似0x1。
  • 如果flags是0x4，扩展数据将包含前一节解释的 ScriptVec 结构的 blake160 哈希。实际的 ScriptVec 结构数据将包含在当前交易中包含的 witness 中，但验证逻辑类似0x2。
  • 其他的flag含义待定。
table Script {
    code_hash:      Byte32,
    hash_type:      byte,
    args:           Bytes,
}

vector ScriptVec <Script>;

ScriptVec 结构中包含的每个条目，都被解释为具有附加行为的扩展脚本的 CKB 脚本哈希。当一个xscript 脚本被执行时，它将按照flags指定的模式执行扩展脚本。

一个扩展的脚本可以被下列的任一种方式加载：

  1. 有些扩展的逻辑可能已经有预定义的哈希，例如，我们可以使用 0x0000 ... 0001 来表示监管的扩展。这些脚本的实际代码已经被镶嵌在 xscript 自身的脚本中了。

  2. Owner lock （所有者的锁）可拿来使用：如果当前交易中的一个 input cell 使用了与当前扩展脚本相同脚本哈希的 lock script，我们可以认为扩展脚本已经被验证。

  3. 如果一个扩展脚本不匹配任何上述标准，xscript 将使用包含在扩展脚本中的 code_hash 和 hash_type 以调用 ckb_dlopen2 的功能，从当前交易的 cell deps 中加载动态链接的脚本。如果脚本可以成功定位，xscript 将寻找一个带有以下签名的导出函数:

    int validate(int is_owner_mode, size_t extension_index, const uint8_t* args, size_t args_length);

    is_owner_mode 表示当前 xUDT 是否通过所有者模式解锁(如 sUDT 所述)，extension_index 指的是当前的扩展在 ScriptVec 结构中的索引。args 和 args_length 被设置为当前扩展脚本的 script 结构中所包含的 script args。

    如果该函数返回0，则认为对当前扩展脚本的验证是成功的。

可能的用途

除了可以加监管扩展外，通过这种策略，我们可以构造一个将铸币权和最终管理权分离的UDT，并且二者都可以转让，在插件中加入一个UDT验证逻辑，其args可以放置Owner lockhash，而拥有plugins Cell的所有权的主体可以修改其args域，从而转移铸币权，同时plugins Cell也可以转移出去，将管理权彻底转移。

另一种可能的用途是多模式的锁脚本，可以在plugins Cell中加入多种验证模式，比如ETH地址、Tron地址，Webauthn地址，电子邮件地址等任意种验证模式，同时，而且通过修改脚本，可以加入更精细的限制，比如每种解锁逻辑可以转出的代币上限，或者可以解锁的时间等等。当然，由于多模式锁脚本是用户自己指定的，其实可以把插件信息直接放在lock_script的args域，然后通过动态链接来验证，从而不需要另外指定plugins cell。

6 Likes