Substrate 跨链技术源码级探索: XCVM的概览

接上一篇关于Subtrate跨链几个要素组件的初步探索, 这篇文章我们来解码一下XCVM, 在此之前, 我们需要先知道XCVM执行的是XCM消息, 所以先来稍微复习一下XCM消息的格式.

前提: XCM消息格式和版本

XCM从开始开发到现在, 已经近2年多的时间, 期间版本从v0到如今正式上线的V2, 以及正在完善的V3, 经历了不少变化, 各版本之间是一种累积叠加, 又大幅度改动的过程.

尤其是在V1到V2的过程中, 其源码演变比较厉害, 在之前的文章中, 我们看到: 

在 V0 和 V1 版本中, Xcm 是一个名为

Xcm<Call>

的

enum

, 为了便于阅读理解, 这里将代码做了精简处理:

#[scale_info(bounds(), skip_type_params(Call))]pub enum Xcm<Call> { //...snippets WithdrawAsset(MultiAssets), ReserveAssetDeposited(MultiAssets), ReceiveTeleportedAsset(MultiAssets), //...snippets}


而在 V2 和 V3 版本中, Xcm 则换成了一个

Tuple Struct

元组结构体:

#[scale_info(bounds(), skip_type_params(Call))]pub struct Xcm<Call>(pub Vec<Instruction<Call>>);


如果我们仔细去看, 会发现 V2 版以后的 Xcm 元组结构体实际是一个 Vec 集合, 其集合子项元素则是一个名为

Instruction<Call>

的枚举.

因此, 如果调用XCM时, 就必须标明其版本, 版本的标识如下:

• version: u8

• message
  : the message, 必须在version确定的情况下有效

• Version: u8 = 2
  , 
  message: Vec<Instruction>
  , 因此, 一个完整的XCM消息就是2 byte的版本标识+ 
  SCALE
  编码的
  XCVM
  指令序列

• 一个XCM的最终执行效果, 取决于两个 
  XCVM
   是否恰当地初始化两个寄存器: 
  Original Programme
   表示消息 和 
  Original Origin
  表示消息来源

XCVM寄存器

XCVM作为执行XCM消息指令的虚拟机, 本质上是一个寄存器架构的非图灵完备的虚拟机.

因此我们需要先看一下

XCVM

的寄存器设计; 作为XCM消息格式的执行器, XCVM的寄存器有着强约束, 不能被随意设置, 而是应该放置特定相关的值, 而且只能在特定场景和特定规则下才能改变.

以下是各个寄存器的基本作用和含义:

Programme

 

存放类型: 

Vec<Instruction>

 

初始值: 

Original Programme

的值 

作用: 当前正在执行的

XCVM

指令, 当全部指令执行完毕或者错误发生时才可能改变

 

Programme Counter

存放类型: u32

 

初始值:0

 

作用: 当前正在执行的指令在

Programme

寄存器中的索引数,每当成功执行一个指令则+1, 

Programme

寄存器更新时重置为0

Error

 

存放类型: Option<(u32, Error)>

 

初始值: None

 

作用: 最新的指令程序执行错误, 仅当程序出错时才设置, 可以主动清除.其中两个子值是错误发生时

Programme Counter

值和错误类型 

Error Handler

 

Vec<Instruction>

 空列表 如果错误发生时, 需要执行的指令, 当程序发生错误, 则清空本寄存器, 并将其值放到

Programme

中执行 

Appendix

 

存放类型: Vec<Instruction>

 

初始值: 空列表 

作用: 附加执行的指令, 当程序执行完毕, 或者出错后

Error Handler

也被清空后, 就会值放到

Programme

里面并清空本寄存器 

Origin

 

存放类型: Option<MultiLocation>

 

初始值: 内值设为Original Origin 

作用: 当前程序的授权地址, 可以为

None

(即没有授权), 或者严格为内部地址(限定的授权子集)

Holding Register

 

存放类型: MultiAssets

 

初始值: 空集(无资源) 

作用: 当前程序控制下但没有上链的资源, 可当作还没有使用的资源(

unspent

)的

非持久化

寄存器, 类似资源的临时存放区域 

Surplus Weight

 

存放类型: u64

 

初始值:0

 

作用: 当前程序预估值的多余值, 包括没有执行的指令权重, 没有生效的错误处理权重, 和指令成功执行的保守预估权重 

Refunded Weight

 

存放类型: u64

 

初始值: 0

 

作用: Surplus Weight

中已退回的部分, 

XCM

平台没有执行费用因此没有使用此寄存器

XCVM

基本执行流程

XCVM

是一个

fetch-dispatch

"抓取-分发" 循环执行的状态机, 其步骤如下:

• Programme
  寄存器为空时, 停机

• 从
  Programme
  中拿到
  Programme Counter
  索引值指向的指令

• 如果指令存在, 则执行该指令, 并检查执行结果:

• 如果没有错误, 代表执行成功, 则将
  Programme Counter
  加1

• 若发生错误, 则

• 设置
  Error
  寄存器的值(错误发生的索引和错误类型)

• 将
  Programme Counter
  置为
  0

• 将
  Programme
  的内容替换为
  Error Handler
  的内容, 并清空 
  Error Handler

• 如果指令不存在, 则:

• Programme Counter
  置为
  0

• 将
  Programme
  的内容替换为
  Appendix Register
  的内容

• 将
  Error Handler
  中内容的预估权重, 加到
  Surplus Weight
  中去

• 清空 
  Appendix Register
  和
  Error Handler

• 与普通的
  fetch/dispatch
  机制不同的是, 
  XCVM
  的执行中有
  Error Handler
  和
  Appendix
  寄存器, 需要注意的是:

• Error
  寄存器在程序执行完毕后不会被清空, 这样可以让
  Appendix
  寄存器可以使用
  Error
  中保留的值

• 无论程序执行成功与否, 
  Error Handler
  寄存器都会被清空, 这样保证前一个程序的错误处理逻辑不会影响后续的代码执行

注意

• 指令类型
  Instruction
   是个标签联合类型(Rust中的
  enum
  ), 每个指令由
  SCALE
  编码的以
  0
  为初始索引的指令列表中的位置+其操作构建而成, 需要注意

• Origin
  术语在此处, 表示
  Origin
  寄存器中值代表的位置, 因此 
  controlled by the Origin
  意思等同"由
  Origin
  寄存器中的值代表的地址控制

• Holding
  术语表示
  Holding
  寄存器中的值, 因此
  reduce Holding by the asset
  等于"从
  Holding
  寄存器中减少资产

• Appendix
  和
  Error Handler
  也是类似

• on-chain
  术语, 应该理解为"在本地共识系统下的持久状态(within the persistent state of the local consensus system)", 不应该仅仅只当区块链的作为本地共识场景下对待.

• Compact
  , 
  Weight
  和
  QueryId
  类型应该理解为
  SCALE
  中定义的压缩整数类型

• 
  

关于XCVM的寄存器和指令执行流程就介绍到这里, 下一篇我们来探索具体的XCM指令含义和使用.