当前位置：网站首页>波卡跨链通信源码探秘: 要素篇

波卡跨链通信源码探秘: 要素篇

2022-06-30 12:23:00 【InfoQ】

Polkadot最具特色的优势就是其跨链能力, 因此要深入波卡生态世界, 就必须要研究其跨链技术.

总的来说, 波卡跨链解决方案有以下几个特点:

互操作性强

优异的可扩展性

超强的普适性

异构跨链具备强一致性

独有的共享安全机制, 安全性好

作为研究波卡跨链技术的第一步, 首先我们来看看跨链通信所涉及到的几个要素.

同任何通信系统一样, 要探究其运行机制, 我们大致需要了解以下几点:

通信的参与对象

通信过程中传递的内容

通信过程如何实施, 即通信协议

下面我就以上三个方面, 来对Polkadot的跨链通信机制做初步探索.

波卡跨链的参与对象

说到跨链通信参与对象, 你可能会觉得没啥讨论的必要, 因为所谓跨链通信, 顾名思义不就是“不同区块链”之间的通信嘛? 参与对象就是不同的区块链咯~

这么想当然也是没错, 但实际上波卡跨链的野心远不止于此.

波卡创世大佬Gavin Wood对波卡跨链的目标参与者, 定义为不同的 “consensus system” 即“共识系统”, 或者说 “consensus environment”即“共识环境”.

XCM aims to be a language communicating ideas between consensus systems

这里提到XCM即波卡跨链所用的交换语言, 下文我们再详细讲.

原话中的“

consensus system"

翻译过来即”共识系统" , 但是请注意, 这里的共识系统, 跟我们平时在区块链开发中所提的

共识系统

的含义是不同的.

我们在开发中的所说的

共识系统

指的是

共识的机制

或者

共识算法

, 也被称为**“共识引擎”**, 比如PoW, PoS, DBFT, BABE, GRANPA等,

而林嘉文大佬这句话里的

共识系统

, 则指的是基于某种共识引擎而运作的实体系统, 也就是说波卡跨链的参与对象是“一个基于某种共识机制而运行的系统”, 如:

区块链

智能合约

转接桥

甚至pallets.

在波卡的跨链愿景中, 这些共识系统之间可以任意通信, 通信参与者所基于的共识引擎可以完全不同, 只需在通信中遵循一致的Polkadot跨链框架即可.

这种“跨共识”的通信解决方案, 是波卡区别于其它跨链解决方案的最特殊的地方.

比如“不同链上合约相互调用”问题: 比如一个部署在Phala链上的隐私计算智能合约, 需要调用另一个部署在Crust链上的存储合约, 在目前其它跨链方案下基本无法实现, 而波卡则可以做到.

波卡这种“跨共识”的方式, 应该说为开发者提供了无限种可能.

波卡跨链传递的内容

了解的波卡跨链通信中的参与者, 我们来看波卡跨链通信的内容, 或者说跨链沟通的语言. Polkadot跨链通信, 或者说“跨共识”通信传递的内容是XCM.

XCM

XCM, 全称

Cross-Consensus Message Format

, 直译过来是

跨共识消息格式

. 从名字就可以看到, 波卡为跨链通信设计的语言, 就是“跨共识”的.

XCM起初是作为一种跨链通信消息格式而开发, 你可以简单理解XCM为类似于Web2.0传统开发中的JSON或者Protobuf格式.

然而经过多次迭代, 已经演变成一个通用的跨共识通信语言, 其普适性在每次迭代中都不断完善和提高. 最新的V3版已经可以做到让基于Polkadot的平行链与基于Kusama的平行链相互通信.

未来XCM也不会仅仅局限于波卡/substrate生态内, 而是成为任意不同共识系统直接的通用通信语言. 后续我们会有单独文章详细探究XCM, 这里我们仅仅通过XCM的源码来略窥一二.

XCM目前正在运行的有V0, V1和V2三个版本, 其中V0版本即将废弃, 而新V3版本已经在今年情人节完成代码, 目前还处于测试分支里面, 截止本文写作的时间, V3版XCM已经在进行benchmark, 应该不久就会提交代码审计并最终部署.

在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>

的枚举, 再进一步观察这个

enum

的源码:

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

看到什么? 是不是跟原来V0和V1版的Xcm长的差不多?

是的, 在V2和V3版本中, 原来的Xcm

enum

被重新名为

Instruction<Call>

, 而整体的Xcm则扩展成一个元组结构体, 其本质则是一个Vec集合, 集合的元素子项都是将由原来的Xcm扩充成的

Instruction<Call>

枚举.

另外我们也可以看到,

Instruction<Call>

实际是定义了一系列执行动作指令; 这些指令定义了通信的具体内容, 比如

WithdrawAsset

指令是告诉

origin

方withdraw某些资源, 并将其放入持有寄存器(Holding Register)中 , 这里不用管其具体含义, 后续我们在XCM的专文中我们再详细介绍.

V3版和V2版的

Instruction<Call>

数据结构定义是一样的, 仅包含的子项比V2版本多了一些.

结合上面的源码我们可以看出, 目前的XCM就是一个包含一系列连续指令的Vec集合; 同时也可以看出, 从V0到V3, XCM是在不断扩展中并完善中.

有指令就必须要有执行指令的地方, XCVM的执行环境是XCVM虚拟机.

XCVM

, 全称

Cross-Consensus Virtual Machine

, 即

跨共识虚拟机

, 这里是XCM消息实际执行的地方, 在Polkadot的源码中, 这一部分的名称是

xcm-executor

, 其核心定义是一个

XcmExecuteor

的结构体:

pub struct XcmExecutor<Config: config::Config> {
 pub holding: Assets,
 pub origin: Option<MultiLocation>,
 pub original_origin: MultiLocation,
 pub trader: Config::Trader,
 /// The most recent error result and instruction index into the fragment in which it occurred,
 /// if any.
 pub error: Option<(u32, XcmError)>,
 /// The surplus weight, defined as the amount by which `max_weight` is
 /// an over-estimate of the actual weight consumed. We do it this way to avoid needing the
 /// execution engine to keep track of all instructions' weights (it only needs to care about
 /// the weight of dynamically determined instructions such as `Transact`).
 pub total_surplus: u64,
 pub total_refunded: u64,
 pub error_handler: Xcm<Config::Call>,
 pub error_handler_weight: u64,
 pub appendix: Xcm<Config::Call>,
 pub appendix_weight: u64,
 _config: PhantomData<Config>,
}

这个

XcmExcutor

结构体即XCVM的主体, 其上实现了一个主要的方法叫

execute

, 用来具体执行XCM的每条指令:

impl<Config: config::Config> XcmExecutor<Config> {
 //...snippets
 pub fn execute(&mut self, xcm: Xcm<Config::Call>) -> Result<(), ExecutorError> {
 //...snippets
 if let Err(e) = self.process_instruction(instr) {
 *r = Err(ExecutorError { index: i as u32, xcm_error: e, weight: 0 });
 },
 //...snippets
}

execute

方法内部则是调用

process_instruction

函数来具体处理每一个XCM指令, 因此我们查看

process_instruction

方法源码:

fn process_instruction(&mut self, instr: Instruction<Config::Call>) -> Result<(), XcmError> {
 match instr {
 //...snippets
 TransferReserveAsset { mut assets, dest, xcm } => {
 let origin = self.origin.as_ref().ok_or(XcmError::BadOrigin)?;
 // Take `assets` from the origin account (on-chain) and place into dest account.
 for asset in assets.inner() {
 Config::AssetTransactor::beam_asset(asset, origin, &dest)?;
 }
 let ancestry = Config::LocationInverter::ancestry();
 assets.reanchor(&dest, &ancestry).map_err(|()| XcmError::MultiLocationFull)?;
 let mut message = vec![ReserveAssetDeposited(assets), ClearOrigin];
 message.extend(xcm.0.into_iter());
 Config::XcmSender::send_xcm(dest, Xcm(message)).map_err(Into::into)
 }
 //...snippets
 }
 //...snippets
},

从源码中, 我们不难看出对于每一个XCM指令的处理, XCVM都是拿到其参数后直接进行处理执行.

这种直接处理指令的虚拟机构架, 就是所谓的“基于寄存器”的虚拟机构架; 区别于bitcoin script等需要使用`数据栈’做数据中转场所然后再处理的方式, 也就是所谓“基于栈”的虚拟机构架.

XCM不是图灵完备的语言, 同样XCVM不是图灵完备的虚拟机. 采用非图灵完备的方式有诸好处, 其中之一是能让XCVM在处理和执行XCM的保持高效, 从而保证大量消息能够及时有效性传递和被处理.

波卡跨链的通信协议

XCM作为跨共识的通信语言, 需要一个通信实施机制来传递交换它, 这个通信过程机制, 就是所谓“Protocol”协议. 我们日常所见的HTTP, FTP, TCP, UDP这些都是类似的通信协议.

一般来说, 一个Ptotocol会定义通信过程中的具体步骤, 例如如何发起, 如何接收, 如何验证, 第一步做什么, 第二步做什么等等.

波卡跨共识的通信Protocol目前分为以下几种:

XCMP
, 全称 Cross-Chain Message Passing, 即
跨链消息协议
, 该协议使用Merkle 树来确保通信安全验证, 并基于此有一个简单的排队系统; 在XCMP协议执行过程中, 中继链仅仅将跨链交易相关元数据(metadata)以哈希的形式储存, 因此占用的资源和执行效率极高. XCMP有两种形式:

直接通信,
xcm消息数据在平行链之间直接传输, 对于中继链来说仅仅可以只有一个“知会”的动作, 这种方式可扩展性极高, 目前还在开发之中.

中继通信,
即通过中继链来传递, 具体的就是通过VMP来实现, VMP的详细见下文.

XCMP-Lite, 即HRMP(
Horizontal Relay-routed Message Passing 水平中继路由消息传递
协议). 由于XCMP中平行链直接通信的模式还在开发中, 因此目前在Polkadot和Kusama中继链上, 使用的是HRMP作为现阶段的过渡.从以上可以看出, HRMP的消息传递中, 数据是直接以Vec

HRMP与XCMP使用相同的接口和功能, 但最大的区别在于HRMP将所有消息内容都储存在中继链中, 因此占用的资源和执行效率远远不如XCMP. 以下是 HRMP源码中的2个消息结构体代码, 同样为了便于理解, 这里做了精简处理:

 pub struct InboundHrmpMessage<BlockNumber = crate::BlockNumber> {
 pub sent_at: BlockNumber,
 pub data: sp_std::vec::Vec<u8>,
 }
 
 pub struct OutboundHrmpMessage<Id> {
 pub recipient: Id,
 pub data: sp_std::vec::Vec<u8>,
 }

这种近似“明文”的方式存储全部消息数据的.

VMP (Vertical Message Passing 垂直消息传递协议) ,
VMP其实是一个统称, 用来与HRMP的“水平”相对照; HRMP的H 即“Horizontal 水平”, 是指平行链与平行链之间的沟通; 而
VMP
的V即“Vertical垂直”则主要指中继链和平行链之间的通讯, VMP包含2个协议:

UMP (Upward Message Passing 上行消息传递协议)
: 由平行链往中继链传递消息, 称为“向上传递”, 由于各个平行链向中继链发送的消息的内容可能千差万别, 因此
UMP
模块主要提供了一个名为
UmpSink
的
trait
来统一约束. 使用trait来统一约束的好处, 是尽量给予各个平行链灵活自由.

 pub trait UmpSink {
 fn process_upward_message(
 origin: ParaId,
 msg: &[u8],
 max_weight: Weight,
 ) -> Result<Weight, (MessageId, Weight)>;
 }
 
 impl UmpSink for () {
 fn process_upward_message(
 _: ParaId,
 _: &[u8],
 _: Weight,
 ) -> Result<Weight, (MessageId, Weight)> {
 Ok(0)
 }
 }

- **DMP (Downward Message Passing 下行消息传递协议**) : 由中继链向平行链传递消息, 称为“向下传递”; 这个就可以相对地统一格式, 因此源码中定义了一个`DownwardMessage`类型, 本质是一个`Vec<u8>`类型, 并用`InboundDownwardMessage`结构体包裹起来, 以便放入队列中去处理

 pub type DownwardMessage = sp_std::vec::Vec<u8>;
 
 #[derive(Encode, Decode, Clone, sp_runtime::RuntimeDebug, PartialEq, TypeInfo)]
 #[cfg_attr(feature = &quot;std&quot;, derive(MallocSizeOf))]
 pub struct InboundDownwardMessage<BlockNumber = crate::BlockNumber> {
 pub sent_at: BlockNumber,
 pub msg: DownwardMessage,
 }

以上就是目前Polkadot生态所使用的跨链通信协议, 但从XCM的“跨共识”愿景来猜测, 未来也许会有类似

XCM兼容

的协议, 用于非波卡系的区块链网络和波卡系之间进行通信, 甚至两个非波卡系网络之间, 也可以采用XCM兼容协议进行通信.