当前位置：网站首页>Exploring the source code of Boca Cross Chain Communication: Elements

Exploring the source code of Boca Cross Chain Communication: Elements

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

Polkadot The most distinctive advantage is its cross chain capability , Therefore, we should go deep into the ecological world of Boca , We must study its cross chain technology .

in general , Boca cross chain solution has the following characteristics :

Strong interoperability

Excellent scalability

Strong universality

Heterogeneous cross chain has strong consistency

Unique sharing security mechanism , Good safety

As the first step of studying Boca cross chain technology , First, let's take a look at several elements involved in cross chain communication .

Like any communication system , To explore its operating mechanism , We need to understand the following points :

Participants in the communication

The content transmitted in the communication process

How the communication process is implemented , Communication protocol

Now I will focus on the above three aspects , Come on Polkadot The cross chain communication mechanism of .

Boca's cross chain participants

Speaking of cross chain communication participants , You may feel that there is no need to discuss , Because the so-called cross chain communication , As the name suggests, it is not “ Different blockchains ” Communication between them ? The participants are different blockchains ~

Of course, that's right , But in fact, Boca's cross chain ambition goes far beyond this .

Boca, the founder Gavin Wood For Boca's cross chain target participants , Defined as different “consensus system” namely “ Consensus system ”, Or say “consensus environment” namely “ Consensus environment ”.

XCM aims to be a language communicating ideas between consensus systems

Mention here XCM That is, the exchange language used by Boca to cross the chain , We will go into more detail below .

In the original words “

consensus system"

The translation is ” Consensus system " , But notice , The consensus system here , It is similar to what we usually mentioned in blockchain development

Consensus system

Meaning is different .

What we said in the development

Consensus system

refer to

The mechanism of consensus

perhaps

Consensus algorithm

, Also known as **“ Consensus engine ”**, such as PoW, PoS, DBFT, BABE, GRANPA etc. ,

And in the words of Lin Jiawen, the boss

Consensus system

, It refers to an entity system that operates based on a consensus engine , In other words, Boca's cross chain participants are “ A system that operates on some kind of consensus mechanism ”, Such as :

Blockchain

Intelligent contract

Transfer bridge

even to the extent that pallets.

In Boca's cross chain vision , These consensus systems can communicate freely , The consensus engine on which communication participants are based can be completely different , Just follow consistent in your communications Polkadot Cross chain framework .

such “ Cross consensus ” Communication solutions , This is the most special difference between Boca and other cross chain solutions .

such as “ Contracts on different chains call each other ” problem : For example, a deployment in Phala Privacy computing smart contracts on the chain , You need to call another deployment in Crust Storage contracts on the chain , It is basically impossible to realize under other cross chain schemes , Boca can do it .

Boca this “ Cross consensus ” The way , It should be said that it provides unlimited possibilities for developers .

The contents of Boca's cross chain transmission

Understand the participants in Boca cross chain communication , Let's look at the contents of Boca cross chain communication , Or the language of cross chain communication . Polkadot Cross Chain Communication , Or say “ Cross consensus ” The content of communication is XCM.

XCM

XCM, Full name

Cross-Consensus Message Format

, It's literally

Cross consensus message format

. You can see from the name , Boca is a language designed for cross chain communication , Namely “ Cross consensus ” Of .

XCM It was originally developed as a message format for cross chain communication , You can easily understand XCM For something like Web2.0 In traditional development JSON perhaps Protobuf Format .

However, after many iterations , It has evolved into a common cross consensus communication language , Its universality is constantly improved and improved in each iteration . Abreast of the times V3 The version can already be based on Polkadot Parallel chain of and based on Kusama Parallel chains of communicate with each other .

future XCM Nor is it limited to poca /substrate Within the ecology , Instead, it becomes a direct universal communication language for any different consensus system . In the future, we will have a separate article to explore in detail XCM, Here we just pass XCM A glimpse of the source code of .

XCM Currently running are V0, V1 and V2 Three versions , among V0 The version will be obsolete , And new V3 Version has been completed on Valentine's day this year , It is still in the test branch , As of the writing time of this article , V3 edition XCM Already in progress benchmark, The code audit should be submitted and finally deployed soon .

stay V0 and V1 In the version , Xcm It's a man named

Xcm<Call>

enum

, In order to facilitate reading comprehension , The code is simplified here :

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

And in the V2 and V3 In the version , Xcm It was replaced by a

Tuple Struct

Tuple structure :

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

If we look carefully , Will find V2 Version later Xcm The tuple structure is actually a Vec aggregate , Its aggregated child element is a named

Instruction<Call>

Enumeration , Take a closer look at this

enum

Source code :

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

What do you see ? Is it the same as the original V0 and V1 Version of Xcm It's about the same length ?

Yes , stay V2 and V3 In the version , The original Xcm

enum

Renamed

Instruction<Call>

, And the whole thing Xcm Then it is expanded into a tuple structure , Its essence is a Vec aggregate , The element children of the collection will be changed from the original Xcm Expanded into

Instruction<Call>

enumeration .

In addition, we can see ,

Instruction<Call>

It actually defines a series of execution action instructions ; These instructions define the specific content of the communication , such as

WithdrawAsset

The order is to tell

origin

Fang withdraw Some resources , And put it into the holding register (Holding Register) in , It doesn't matter what it means , Then we're XCM In the special article on .

V3 Version and V2 Version of

Instruction<Call>

The data structure definitions are the same , Contains only subitems that are smaller than V2 There are more versions .

Combined with the above source code, we can see , current XCM Is a sequence of consecutive instructions Vec aggregate ; And you can also see that , from V0 To V3, XCM It is expanding and improving .

Where there are instructions, there must be places to execute them , XCVM The execution environment of is XCVM virtual machine .

XCVM

, Full name

Cross-Consensus Virtual Machine

, namely

Cross consensus virtual machines

, Here is XCM Where the message is actually executed , stay Polkadot In the source code , The name of this section is

xcm-executor

, Its core definition is a

XcmExecuteor

The structure of the body :

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>,
}

This

XcmExcutor

The structure is XCVM The main body of , It implements a main method called

execute

, Used to carry out XCM Each instruction of :

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

Inside the method is to call

process_instruction

Function to handle each XCM Instructions , So let's look at

process_instruction

Method source code :

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
},

From the source , It is not difficult to see that for every XCM Processing of instructions , XCVM All of them are processed and executed directly after obtaining their parameters .

This virtual machine architecture that directly processes instructions , It's called “ Based on register ” Virtual machine architecture ; The difference in bitcoin script And so on ` The data stack ’ It is a way to transfer data and then process it , That is to say “ Based on stack ” Virtual machine architecture .

XCM Not Turing's perfect language , Again XCVM Not Turing's complete virtual machine . There are advantages to using a non Turing complete approach , One of them is to make XCVM In processing and executing XCM Keep efficient , So as to ensure that a large number of messages can be delivered and processed in a timely and effective manner .

Boca cross chain communication protocol

XCM As a cross consensus communication language , A communication implementation mechanism is needed to transfer and exchange it , This communication process mechanism , Is the so-called “Protocol” agreement . What we see everyday HTTP, FTP, TCP, UDP These are similar communication protocols .

Generally speaking , One Ptotocol Will define the specific steps in the communication process , For example, how to initiate , How to receive , How to validate , What's the first step , What to do in the second step .

Boca cross consensus communication Protocol At present, it is divided into the following categories :

XCMP
, Full name Cross-Chain Message Passing, namely
Cross chain message protocol
, The agreement uses Merkle Tree to ensure communication security verification , And based on this, there is a simple queuing system ; stay XCMP During the execution of the agreement , The relay chain will only cross chain transaction related metadata (metadata) Store in hash form , Therefore, the occupied resources and execution efficiency are extremely high . XCMP There are two forms :

Direct communication ,
xcm Message data is transmitted directly between parallel chains , For a relay chain, there can only be one “ Notify ” The action of , This method is highly scalable , It is still under development .

Repeater communication ,
That is, the relay chain is used to transmit , Specifically, through VMP To achieve , VMP See below for details .

XCMP-Lite, namely HRMP(
Horizontal Relay-routed Message Passing Horizontal relay routing messaging
agreement ). because XCMP The direct communication mode of China Pingxing chain is still under development , So at the moment Polkadot and Kusama On the relay chain , It uses HRMP As a transition at this stage . You can see from the above , HRMP In the message delivery of , The data is directly expressed in Vec

HRMP And XCMP Use the same interfaces and functions , But the biggest difference is HRMP Store all message contents in the trunk chain , Therefore, the occupied resources and execution efficiency are far less than XCMP. Here are HRMP In the source 2 Message structure code , Also for ease of understanding , Here we do some simplification :

 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>,
 }

 This approximation “ Plaintext ” To store all message data .

VMP (Vertical Message Passing Vertical messaging protocol ) ,
VMP It's actually a general term , Used with HRMP Of “ level ” Contrast ; HRMP Of H namely “Horizontal level ”, It refers to the communication between parallel chains ; and
VMP
Of V namely “Vertical vertical ” It mainly refers to the communication between the relay chain and the parallel chain , VMP contain 2 Agreements :

UMP (Upward Message Passing Uplink messaging protocol )
: The message is passed from the parallel chain to the relay chain , be called “ Pass up ”, Since the contents of messages sent from each parallel chain to the relay chain may vary greatly , therefore
UMP
The module mainly provides a module named
UmpSink
Of
trait
To unify constraints . Use trait To unify the benefits of constraints , It is to give each parallel chain as much flexibility as possible .

 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  Downlink messaging protocol **) :  Passing messages from the relay chain to the parallel chain ,  be called “ Pass down ”;  This can relatively unify the format ,  So the source code defines a `DownwardMessage` type ,  The essence is a `Vec<u8>` type ,  And use `InboundDownwardMessage` The structure is wrapped ,  So that it can be put in the queue for processing

 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,
 }

That's what we're talking about right now Polkadot Cross chain communication protocol used by ecology , But from XCM Of “ Cross consensus ” Let's guess , There may be something similar in the future

XCM compatible

The agreement , It is used for communication between non Boca blockchain network and Boca system , Even between two non Boca networks , You can also use XCM Compatible protocol for communication .

summary

thus , We have preliminarily explored several core elements of Boca's cross chain mechanism , From which we can see , Boca's cross chain or cross consensus design , Its goal is relatively ambitious , No longer confined to the Poka Ecology , Instead, it tries to cover the entire decentralized blockchain ecosystem , And in constant iterative development .

Due to Boca's excellent framework mechanism across the chain , Distinctive “ Shared security ” system , This makes Boca series the most outstanding cross chain ecology in the industry , There are already many parallel links with their own characteristics ; Next article , Let's explore the framework design of Boca cross chain .