![見出し画像](https://assets.st-note.com/production/uploads/images/109159102/rectangle_large_type_2_a1d13ba78b22cf5400276cf7d12af97f.png?width=1200)
【完全保存版】AstarのXVM(Cross-Virtual Machine)について
当記事は、こちらの記事を翻訳・編集したものです。
0 はじめに
2022年、多くのことが起こりました。
Web3業界全体が、技術的な成果、現実的な問題の解決、今までに見たことのない産業の温床となるなど、新たな境地を切り開きました。
もちろん、業界が学び、改善すべき事件や出来事もたくさんありました。
2022年は、Web3の世界では「大盛況のうちに幕を閉じた」と言っても過言ではないでしょう。
しかし、テクノロジーは成長するものであり、このような出来事を経験することは、何がうまくいき、何がうまくいかないかを知ることにつながります。
Astar Foundationでは、今起きている外部からの影響に関係なく、未来の基盤を作るために努力してきました。
そして今日、Astar Visionを達成するための最も重要な機能の1つ、クロス仮想マシン(XVM)を紹介できることを誇りに思います。
この記事では、Web3におけるスマートコントラクトの役割、dApp開発を進める上で見えている問題点、XVMを作った理由、XVMの仕組み、そして最後に、未来が提示するものについて説明します。
1 WASM仮想マシンについて
1 WASMとは
WebAssembly(WASM)は、WebAssembly仮想マシンがWASMバイトコードを解釈するために読むことができるメッセージフォーマットです。
![](https://assets.st-note.com/img/1687671089307-allnrTXwpb.png?width=1200)
翻訳者注
コンパイルとは、高級プログラミング言語で書かれたソースコードを、コンピュータが直接実行可能な形式(通常はマシンコードまたはバイトコード)に変換するプロセスです。
厳密に言えば、WASMは、仮想環境でシステムと通信するために上位言語からコンパイルされるメッセージフォーマットを指します。
翻訳者注
メッセージフォーマットとは、データがどのように構造化、順序付け、符号化されるべきかを定めたものを指します。
データ交換の際に、送信者と受信者が同じフォーマットを理解している必要があります。
これにより、受信者(この場合、WebAssembly仮想マシン)は送信者(高級言語からのコンパイラ)からの情報を適切に解釈し、期待される動作を遂行できます。
しかし簡略化のため、この記事でWASMと言う場合は、バイナリとしてのWASMとブロックチェーン内の仮想マシンの両方を指すことにします。
![](https://assets.st-note.com/img/1687671187124-mrDEkRFcpk.png?width=1200)
WASMはもともと、システムレベル言語からコンパイルされたバイナリをブラウザに使用し、ウェブアプリケーションにネイティブに近いパフォーマンスを生み出すために使われていました。
翻訳者注
コンピュータのハードウェアまたはオペレーティングシステムと直接対話できるように設計されたプログラミング言語のことを指します。
これらの言語は、メモリ管理やハードウェアへのアクセスなど、システムの低レベルの部分に対する制御をプログラマに提供します。
しかし、WASMの移植性のおかげで、これはブラウザ以外でも実行できます。
2 スタックベースのVM
WASMのVMはEthereum Virtual Machine(EVM)のようなスタックベースのVMであるため、WASMのバイナリにコンパイルされている限り、スマートコントラクトの実行環境を作成することが可能です。
翻訳者注
ここは重要な部分なので、少し長くなります。
先を読まれる方は飛ばしてください。
スタックベースのVM(仮想マシン)とは、コンピュータの内部で計算やデータ管理を行うために「スタック」と呼ばれるデータ構造を使用する仮想マシンのことを指します。
スタックは、データの「最後に入ったものが最初に出る」(LIFO: Last In First Out)という特性を持つデータ構造です。
WASM(WebAssembly)のVMやEthereum Virtual Machine(EVM)は、このスタックベースの方式を使用します。
これは、スマートコントラクトの実行や、その他の高度な計算タスクを行うのに適しています。
![](https://assets.st-note.com/img/1687581943504-JvU2479VqS.png?width=1200)
翻訳者注
スタックベースのコンピューティングモデルがスマートコントラクトや高度な計算タスクに適している理由はいくつかあります。
1 局所性
スタックは「最後に入れたものを最初に取り出す」(LIFO:Last In, First Out)という原則に基づいています。
これは、局所性(最近使ったデータや命令を再利用する傾向があるというコンピューティングの特性)をうまく利用しています。
スマートコントラクトや高度な計算タスクでは、局所性が非常に重要です。
2 シンプルな設計
スタックベースのVMはレジスタベースのVMに比べて設計がシンプルで、その結果、プログラムの解釈と実行が容易になります。
また、バイトコードを解釈する際の複雑さも軽減します。
3 メモリ管理
スタックベースのVMは、メモリの割り当てと解放を自動的に行います。
これにより、開発者はメモリ管理について深く考える必要がなくなり、エラーやバグの可能性を減らすことができます。
4 セキュリティ
スタックベースのコンピューティングモデルは、不正なメモリアクセスを防ぐための境界チェックを提供します。
これは、スマートコントラクトのようなセキュリティが重要なコンテキストで特に有益です。
以上の理由から、スマートコントラクトや高度な計算タスクにはスタックベースのVMが適しています。
3 型安全性と適切なエラー処理
EVMとは異なり、これはWASMを通じて、Rust、Go、C++など、WASMをターゲットにできる言語で書かれたスマートコントラクトを実行するブロックチェーンを作成できることを意味します。
これらはすべて型安全性と適切なエラー処理をサポートしています。
![](https://assets.st-note.com/img/1687670690996-Cb3vHyImbA.png?width=1200)
4 非同期性
さらに、WASMネイティブにコンパイルできる主要な言語のほとんどが、その構文で非同期関数をサポートしているため、WASMスマートコントラクトに非同期性を導入することが可能です。
翻訳者注
非同期性とは、プログラムの一部が他の部分が完了するのを待たずに実行できる特性を指します。
非同期プログラミングの主な利点は、パフォーマンスの改善とリソースの効率的な利用です。
5 相互運用性
相互運用性については、これは、応答が何であるかを知らずにやみくもにメッセージを送信する代わりに、スマートコントラクト内でクロスチェーン関数を扱えるようになったことを意味します。
翻訳者注
非同期性があれば、スマートコントラクトは他のブロックチェーンの状態をチェックし、その結果に基づいて次のアクションを決定できます。
これにより、スマートコントラクトの複雑さと能力が大幅に向上します。
EVMとSolidityがこの部門で欠けていることを考えると、これはDeFi以外で業界標準のクロスチェーンネイティブアプリケーションを作成する上で大きな意味を持ちます。
翻訳者注
現在、Ethereum Virtual Machine(EVM)とその主要なプログラミング言語であるSolidityは、非同期性をサポートしていません。
つまり、EVMとSolidityで記述されたスマートコントラクトは、他のブロックチェーンの状態に基づいて動的にアクションを変更する能力には限界があります。
これは、複数のブロックチェーン間での複雑なインタラクションを必要とするアプリケーション、特に分散金融(DeFi)以外のアプリケーションにとっては大きな制限となります。
このため、WASMのような、非同期性をサポートする新しい技術が導入されると、それはDeFi以外の業界でのクロスチェーンネイティブアプリケーションの作成、そしてブロックチェーン技術全体のさらなる発展に大きな影響を及ぼす可能性があります。
6 スマートコントラクトの未来
これら多くの要因から、WASMはスマートコントラクトの未来です。
しかし、EVMとの互換性の問題があるため、ブロックチェーン技術の大量導入は困難になりつつあります。
2 XVMの動機
1 WASMベースのスマート・コントラクトの現状
技術的に言えば、WASMベースのスマート・コントラクトが進むべき道であることは誰もが知っています。
しかし、EVMが支配する世界でWASMスマートコントラクトを採用する場合、大きな課題があります。
ほとんどのチームは、リッチなEVMエコシステムに慣れすぎています。
ほとんどのWASM VMエコシステムは小規模で、あまりにも異質であるため、多くの既存プロジェクトはWASMスマートコントラクトをゼロから学ぶメリットを見いだせず、EVMエコシステムへのアクセスを犠牲にしています。
翻訳者注
少し意味が分かりにくいと思いましたが、メインの箇所でないので深掘らず、このまま進めます。
2 AstarにとってのXVM
私たちは、まさにこの問題を解決するためにXVMを作りました。
私たちをPlasmの頃から知っている人は、私たちが常に非常にWASMスマートコントラクトにフォーカスしたネットワークだったことを思い出すかもしれません。
しかし、Astarを立ち上げたとき、コントラクトパレットの代わりにEVMで立ち上げました。
翻訳者注
「コントラクトパレット」とは、Substrateフレームワーク(PolkadotとKusamaのエコシステムの核となる開発フレームワーク)で利用される特定のモジュールを指します。
Substrateフレームワークは、再利用可能な「パレット」と呼ばれるコンポーネントのセットで構成されています。
これらのパレットは、特定の機能やロジックを実装します。
「コントラクトパレット」は、この中の1つで、ブロックチェーンにスマートコントラクト機能を追加するためのパレットです。
具体的には、スマートコントラクトの作成と実行、スマートコントラクト間のインタラクションを可能にする機能を提供します。
通常、この「コントラクトパレット」はWebAssembly (WASM)をベースとしたスマートコントラクトの実行をサポートします。
これはエコシステムを立ち上げ、より幅広くプラットフォームを提供するためでした。
しかし、我々は常にWASMスマートコントラクトをより広範なエコシステムに組み込むことを計画していました。
3 XVMの概要
XVMのアイデアはそこから始まりました。
XVMはカスタムパレットとインターフェースのセットで、ある仮想マシンのスマートコントラクトが別の仮想マシンとあたかも同じ環境にあるかのように通信できるようにするものです。
![](https://assets.st-note.com/img/1687671951548-oRJdiSUZKN.png?width=1200)
翻訳者注
カスタムパレットはSubstrateベースのブロックチェーン(ここではAstar Network)の機能を拡張するためのモジュールで、一連のインターフェースは異なるVM間の通信を可能にするための機能を提供します。
言い換えれば、XVMを使えば、ink!スマートコントラクトを作成し、EVM側で利用可能なあらゆるアセットやコントラクトにアクセスできます。
![](https://assets.st-note.com/img/1687672099741-lrBeGrsp4q.png?width=1200)
4 XVMと別のレイヤー0との接続
さらに、AstarのEVMがAxelarやCelerのような別のレイヤー0に接続されている場合、AxelarやCelerに接続されているすべてのEVMチェーンにアクセスできるinkスマートコントラクトを作成できます!
翻訳者注
ここはまだあまり自信がありません。
WASMのVMとEVMがXVMを通じて繋がっています。
そのため、EVMから別のレイヤー0に繋がれば、結果として、WASMからの接続が達成できると考えました。
![](https://assets.st-note.com/img/1687672305846-bHBIqi0SjH.png?width=1200)
翻訳者注
Axelarはブロックチェーン間通信(IBC)を可能にするプロトコルで、異なるブロックチェーンネットワーク間でデータと資産を転送することができます。
Axelarはスケーラビリティと相互運用性を提供し、アプリケーションやユーザーが複数のブロックチェーン間でシームレスにやり取りできるようにすることを目指しています。
Celer Networkはレイヤー2スケーリングプラットフォームで、ブロックチェーンのスケーラビリティと相互運用性の問題を解決しようとしています。Celerはオフチェーン取引を可能にし、低コストで高速なペイメントソリューションとスマートコントラクトの実行を実現します。
XVMは、ビルダーが大規模なEVMエコシステムと相互作用しないという犠牲を払うことなく、革新的なdAppsを開発することを奨励することを願っています。
3 XVMのメカニズム
では、XVMはどのように機能するのでしょうか?
実際の仕組みは非常にシンプルで、エンコードされた呼び出しを配列として受け取り(SCALEコーデックにインスパイアされています)、XVMパレットへの引数として渡します。
![](https://assets.st-note.com/img/1687669875386-wCg9yrFFnz.png?width=1200)
翻訳者注
SCALEコーデックは、SubstrateとPolkadotで使用されるバイナリエンコーディング形式で、データのシリアライゼーションとデシリアライゼーションに使用されます。
4 アーキテクチャ
以下は、XVMの背後にあるアーキテクチャと、他のVMとの接続方法です
![](https://assets.st-note.com/img/1687577658702-zDWNGuO1jQ.png?width=1200)
1 XVMモジュールの公開について
各スマートコントラクトVMは、他の環境のスマートコントラクトが使用できるように、XVMモジュールを公開する方法を持ちます。
翻訳者注
「Chain Extension」や「Precompiled Contract」で「XVM Pallet」と繋がっています。
![](https://assets.st-note.com/img/1687657597265-lStdaRJN4T.png?width=1200)
2 各VMの関数について
XVMパレット関数を公開する各VMの関数を作成します。
例えば、コントラクト・パレットにはチェーン拡張機能(Chain Extension)があり、EVM側にはコンパイル済みのコントラクト(Precompiled Contract)があります。
![](https://assets.st-note.com/img/1687657778947-4IjGGMwPxY.png?width=1200)
翻訳者注
プリコンパイルドコントラクト(Precompiled contracts)とは、Ethereum Virtual Machine (EVM) が提供する特殊なスマートコントラクトの一種です。
これらは、その動作がEVMのコードではなく、ネイティブの(つまり、EVMを実行しているホストマシンの)コードによって定義されています。
プリコンパイルドコントラクトの目的は、いくつかの特定の重い計算(例えば暗号学的な関数)を効率的に行うことです。
EVMのバイトコードでこれらの計算を行うことは非常にガスコストが高くなるため、ネイティブコードで実行することでガスコストを下げることができます。
プリコンパイルドコントラクトは、特定のアドレス(たとえば、0x1から0xfまでのアドレス)に存在し、スマートコントラクトは通常のスマートコントラクトと同様にこれらのアドレスに対して呼び出しを行うことができます。
ただし、プリコンパイルドコントラクトは通常のEthereumスマートコントラクトとは異なり、そのコードはEVMコードではなくネイティブコードで実装されている点が特徴です。
3 エンコード済みの呼び出しについて
一方のVMにデプロイされたスマートコントラクトは、チェーン拡張機能またはプリコンパイルされたコントラクトにエンコードされた呼び出しを送信することで、もう一方のVMとやり取りすることができます。
![](https://assets.st-note.com/img/1687658186403-rrzq1CaE5f.png?width=1200)
4 アダプターについて
XVM関数が呼び出されると、パレットはターゲットVMのアダプターを呼び出し、関数コールをターゲットのスマート・コントラクトに渡します。
![](https://assets.st-note.com/img/1687658272940-6Qraqiu1Yh.png?width=1200)
ブロックチェーンの観点からは、このトランザクションの行は単一のブロックの一部となり、完全にトランザクション的なものとなリマす。
これがXVM呼び出しの方法です。
5 XVMの使用
1 概要
XVMコールがその中核でどのように機能するかが分かったところで、スマート・コントラクト開発者の観点からどのように機能するかについて説明しましょう。
最初のユースケースは、インク開発者がEVM空間のアセットにアクセスすることなので、このセクションでは主にink!コントラクトからXVMを使用することに焦点を当てます。
しかし、同じ原則がEVM上のSolidityコントラクトにも適用されることに注意してください。
2 XVMコールに必要なもの
SolidityコントラクトにXVMコールを行うために必要なのは、スマートコントラクトのH160 EVMアドレス、関数セレクタ、関数に渡すエンコードされた引数だけです。
翻訳者注
細かい話をすると、VMの識別子も必要です。
![](https://assets.st-note.com/img/1687673162409-4gLaUtzX3Z.png?width=1200)
3 全コードについて
話はもう十分なので、実際のコードを見てみましょう。
//! ERC721 EVM contract interoperability using XVM interface.
#![cfg_attr(not(feature = "std"), no_std)]
pub use self::erc721::{
Erc721,
Erc721Ref,
};
use ink_lang as ink;
/// EVM ID (from astar runtime)
const EVM_ID: u8 = 0x0F;
/// The EVM ERC721 delegation contract.
#[ink::contract(env = xvm_environment::XvmDefaultEnvironment)]
mod erc721 {
const APPROVE_SELECTOR: [u8; 4] = hex!["095ea7b3"];
const TRANSFER_FROM_SELECTOR: [u8; 4] = hex!["23b872dd"];
const MINT_SELECTOR: [u8; 4] = hex!["40c10f19"];
use ethabi::{
ethereum_types::{
H160,
U256,
},
Token,
};
use hex_literal::hex;
use ink_prelude::vec::Vec;
#[ink(storage)]
pub struct Erc721 {
evm_address: [u8; 20],
}
impl Erc721 {
/// Create new ERC721 abstraction from given contract address.
#[ink(constructor)]
pub fn new(evm_address: [u8; 20]) -> Self {
Self { evm_address }
}
#[ink(message)]
pub fn transfer_from(&mut self, from: [u8; 20], to: [u8; 20], token_id: u128) -> bool {
let encoded_input = Self::transfer_from_encode(from.into(), to.into(), token_id.into());
self.env()
.extension()
.xvm_call(
super::EVM_ID,
Vec::from(self.evm_address.as_ref()),
encoded_input,
)
.is_ok()
}
#[ink(message)]
pub fn approve(&mut self, to: [u8; 20], token_id: u128) -> bool {
let encoded_input = Self::approve_encode(to.into(), token_id.into());
self.env()
.extension()
.xvm_call(
super::EVM_ID,
Vec::from(self.evm_address.as_ref()),
encoded_input,
)
.is_ok()
}
#[ink(message)]
pub fn mint(&mut self, to: [u8; 20], token_id: u128) -> bool {
let encoded_input = Self::mint_encode(to.into(), token_id.into());
self.env()
.extension()
.xvm_call(
super::EVM_ID,
Vec::from(self.evm_address.as_ref()),
encoded_input,
)
.is_ok()
}
fn transfer_from_encode(from: H160, to: H160, token_id: U256) -> Vec<u8> {
let mut encoded = TRANSFER_FROM_SELECTOR.to_vec();
let input = [
Token::Address(from),
Token::Address(to),
Token::Uint(token_id),
];
encoded.extend(ðabi::encode(&input));
encoded
}
fn approve_encode(to: H160, token_id: U256) -> Vec<u8> {
let mut encoded = APPROVE_SELECTOR.to_vec();
let input = [Token::Address(to), Token::Uint(token_id)];
encoded.extend(ðabi::encode(&input));
encoded
}
fn mint_encode(to: H160, token_id: U256) -> Vec<u8> {
let mut encoded = MINT_SELECTOR.to_vec();
let input = [Token::Address(to), Token::Uint(token_id)];
encoded.extend(ðabi::encode(&input));
encoded
}
}
}
これは、XVMを使用してEVM環境でERC721 Solidityコントラクトを制御できるink!スマートコントラクトです。
これは、XVM SDKコントラクトリポジトリから直接取り出したものです。
コントラクト自体は大したものではないことがわかりますが、少し解剖してみましょう。
翻訳者注
以下のコードの解説は原文であまり細かく触れていなかったため、基本、翻訳者ベースで進めていきます。
4 VM_IDについて
![](https://assets.st-note.com/img/1687596343820-2WX0IzFczR.png?width=1200)
EVM_IDはVMのIDを指し、XVMがこのコントラクトがどのVMをターゲットにするかを理解するために必要です。
翻訳者注
Astarランタイムとは、Astarネットワークの核となる部分で、Rustプログラミング言語で書かれたブロックチェーンの基本構造を指します。
ランタイムはブロックチェーンの動作ルールを定義し、トランザクションの検証やブロックの生成などの基本的な操作を制御します。
つまり、Astarランタイムという基本構造の中で、EVM_IDが「0x0F」と定義されています。
これはIDなので、XVMを拡張していくつものスマート・コントラクトVMをサポートし、相互に通信できるようにすることができます。
5 XVMのデフォルト環境について
![](https://assets.st-note.com/img/1687597539718-tLAve1hm6W.png?width=1200)
翻訳者注
この「XvmDefaultEnvironment」で、その名の通り、XVMのデフォルト環境を使う旨を示しています。
6 関数セレクタの定義について
![](https://assets.st-note.com/img/1687597692445-3626HRY31Y.png?width=1200)
スニペットの後半では、このコントラクトが使用する関数セレクタを定数として定義しています。
翻訳者注
関数セレクタとは、Ethereumのスマートコントラクトが特定の関数を識別し、呼び出すための一意の識別子のことを指します。
これは関数の名前とそのパラメータ型から派生します。
![](https://assets.st-note.com/img/1687642198842-F18PAWKDzA.png?width=1200)
7 EVMアドレスについて
![](https://assets.st-note.com/img/1687597887531-hSF577unEq.png?width=1200)
コードの次の部分では、メッセージを送信するH160アドレス([u8; 20]は20バイト長の配列を意味し、160ビットであることに注意)を定義します。
![](https://assets.st-note.com/img/1687642479565-2SNonK2vda.png?width=1200)
8 コンストラクタについて
![](https://assets.st-note.com/img/1687597984618-RaspLuWxBg.png?width=1200)
この例では、コンストラクタとしてデプロイ時にユーザーにアドレスを定義させていますが、有効なEVMアドレスである限り、この動作は完全にカスタマイズ可能です。
翻訳者注
必要な情報である、EVMのアドレスを設定するのであれば、他のメソッドを追加するなどを行うことも可能です。
9 コントラクト関数について
次のセクションでは、クライアントが相互作用する呼び出し可能なパブリックなコントラクト関数を宣言します。
こちらの「transfer_from」関数を見てみましょう。
![](https://assets.st-note.com/img/1687603135260-bSU8lmuCOs.png?width=1200)
まず、「from」「to」「token_id」の3つの引数を取り、「bool」(trueかfalse)を返すということがわかります。
![](https://assets.st-note.com/img/1687603219940-OwbiEJF0sZ.png?width=1200)
次に、こちらの「transfer_from_encode」関数で符号化(エンコード)してそうです。(後で見てみましょう。)
into関数では型推論で別の型に変換し、所有権を移動させています。
(細かい部分は省略します。ご不明の場合は「型を変えている」のニュアンスで良いと思います。)
![](https://assets.st-note.com/img/1687603334948-BstOEG0euk.png?width=1200)
10 エンコード用関数について
では、「transfer_from_encode」関数を見てみましょう。
![](https://assets.st-note.com/img/1687604913694-lmkGjrClZC.png?width=1200)
「TRANSFER_FROM_SELECTOR」というバイト配列をベクター型に変換しています。
![](https://assets.st-note.com/img/1687642836383-GC2ELJnAVw.png?width=1200)
これによって、新たな要素を追加できるようになりました。
![](https://assets.st-note.com/img/1687604979128-OvoFvjKWMK.png?width=1200)
こちらは、Rustのenum型であるTokenのバリアント(具体的な形を持つenumの値)Addressを使用して、fromという値などをラップしています。
![](https://assets.st-note.com/img/1687643487158-sJ0HjXw7RN.png?width=1200)
このTokenというenumは、Ethereumの関数呼び出しに使用される各種のパラメータタイプを表現するためのものです。
例えば、AddressバリアントはEthereumのアドレスを表現し、UintバリアントはEthereumのuint型を表現します。
![](https://assets.st-note.com/img/1687607447690-BMMMGxD417.png?width=1200)
次に、こちらを見てみましょう。
「ethabi」ライブラリを用いています。
![](https://assets.st-note.com/img/1687648048340-ywYpwLIPXz.png?width=1200)
まずは、各値をバイト配列に変換します。
アドレスは20バイトです。
![](https://assets.st-note.com/img/1687647374411-oyPc5X1wU9.png?width=1200)
そして、32バイトになるように、0で埋めています。
なお、この2つの処理は同時に行われますが、わかりやすさのために、分けて書いています。
![](https://assets.st-note.com/img/1687647605934-4k30ttIQkG.png?width=1200)
これを「extend」でくっつけています。
![](https://assets.st-note.com/img/1687647906453-7Wj2TbLjtF.png?width=1200)
11 XVM Callについて
ここで、自身の実行環境の拡張機能である、「xvm_call」を使用しています。
![](https://assets.st-note.com/img/1687673742389-zubgD6VYSS.png?width=1200)
これにより、EVMの関数を呼び出します。
![](https://assets.st-note.com/img/1687648372820-fJz2U8Nxii.png?width=1200)
そして、具体的に、次の引数を渡しています。
![](https://assets.st-note.com/img/1687673889880-UYjz0dfm77.png?width=1200)
![](https://assets.st-note.com/img/1687649857205-mEpVIzujb1.png?width=1200)
このようにして、XVM Callが行われています。
6 今すぐ試す
XVMは現在、私たちのパブリック・テストネット「shibuya」で公開されています!
この最新機能をすぐに試すことができます。
また、XVMを使いたい開発者が開始できるように、いくつかのリポジトリを用意しました。
7 ink! XVM SDK
前のセクションをご覧になったかもしれませんが、スマート・コントラクトからXVMを使うのは簡単です。
しかし、開発プロセスをさらに簡単にするために、EVMやWASM VMの世界で一般的に使用されるインターフェースのためのXVM SDKを用意しました。
ぜひInk!XVM SDKリポジトリをチェックして、ERC20やERC721などを制御できるインク!コントラクトを作成してください。
![](https://assets.st-note.com/img/1687651093185-KsiNwVsXqg.png?width=1200)
コミュニティからの支援により、SDKを拡張してより多くのインターフェースをサポートし、SolidityとAsk!のSDKを作成し、XVMを活用できるサンプルdAppを作成できます。
8 Sub0 XVMワークショップ dApp
フルスタックのdAppで動くXVMについてもっと知りたいのであれば、Sub0 XVM Workshopリポジトリを見てください。
翻訳者注
Sub0はSubstrateの開発者会議を指しています。
Sub0はこのSubstrateフレームワークについてのディスカッションやワークショップが行われるイベントです。
![](https://assets.st-note.com/img/1687651204525-lZnjlTxVOW.png?width=1200)
これは、Sub0で初めてXVMの機能を一般公開するために使用したプロジェクトです。
このシンプルなdAppは、EVMとSubstrateの両方のネイティブの署名者からERC20トークンを制御する方法を示しています。
翻訳者注
この辺りは、こちらの記事を読んでからの方がイメージが湧きやすいかもしれません。
![](https://assets.st-note.com/img/1687651722285-nMzLxK0Qni.png?width=1200)
![](https://assets.st-note.com/img/1687651874406-TVR3841U9Q.png?width=1200)
XVMに関するAstar Tech Talkもご覧ください。
9 アプリケーション
1 ユニバーサルなアセットコントローラーについて
XVMのシンプルさにもかかわらず、EVMからWASM VMへの流動性の橋渡し以上の多くの潜在的なアプリケーションを作成できます。
XVMを使用すると、異なるアカウントスキームから異なる環境に存在する資産の所有権を証明することができます(例:Polkadot-jsウォレットを使用するだけで、EVM ERC20トークンの所有権移行)
![](https://assets.st-note.com/img/1687652704894-FMi6HMt0NM.png?width=1200)
つまり、すべてのアセットを管理するために環境ごとに新しいウォレットを作成する必要はありません。
つまり、単一の署名者でユニバーサルなアセットコントローラーを作成できるのです。
![](https://assets.st-note.com/img/1687653037561-1MRGHn9s6R.png?width=1200)
2 NFTマーケットプレイスでの応用例
例えば、多くのNFTマーケットプレイスでは現在、MetaMaskのようなEVM署名者のみが利用可能です。(なお例外はKusamaのSingularです。)
そのため、Polkadot-jsを使用したERC721 NFTやMetaMaskを使用したRMRK NFTの取引やオークションはできません。
XVMを使えば、2人の署名者がEVMとWASM VMの両方であらゆるNFT規格の所有権を扱い、移転できるようにすることで、この問題を解決できます。
![](https://assets.st-note.com/img/1687653850438-rkSU7dJVRz.png?width=1200)
これにより、UXの機会が広がります。
言い換えれば、ユーザーはお気に入りのウォレットインターフェースを離れることなく、複数のマーケットプレイスで様々なタイプのNFTを検討することができます。
3 クロスチェーンでの応用例
その他のアプリケーションとしては、XVMと同じエンコーディング方式を採用したクロスチェーンのdAppsがあります。
Astarネットワークを通じて、XCMPのようなセキュアなクロスコンセンサスメッセージパッシングプロトコルがPolkadot上にあれば、SolanaやNearのような完全に異質な環境でスマートコントラクトと対話することができます。
翻訳者注
ここは私はまだ理解しきれていません。
現在の理解では、Solanaなどに対応したXCMPがPolkadotにあればと読み取りました。
ただ、XCMPなどの実装はリレーチェーンの話であるため、Astarのコントロール外の話だと考えました。
一方、たとえそのようなXCMPがなくてもXVMで他のVMとの接続を実装することができれば、Solanaなどとも対話できるのではと考えました。
XVMに関して言えば、空は無限であり、私たちはこれによって、将来のスマートコントラクトが、どの言語で書かれ、どの環境/RPCを使用しているかに関係なく、シームレスに動作することを願っています。
10 将来
1 XVM v3について
現在、XVMはv2であり、我々はv3の作成に励んでいます。
v2の制限の一つは、XVMストレージのクエリーとエラー・メッセージがないことです。
![](https://assets.st-note.com/img/1687655068730-DGb3p68ivR.png?width=1200)
スマート・コントラクトとやり取りするとき、開発者はアプリケーション・ロジックの一部として、アカウントが保持しているERC20トークンの量のような特定の値をクエリすることを期待しています。
v3では、スマート・コントラクトが別の環境からスマート・コントラクトのストレージ値を読み取れるようにします。
エラーメッセージと同様に、開発者はトランザクションが成功したかどうかしかわかりません。
しかし、エラーメッセージを改善することで、プロジェクトがdAppのコーナーケースを適切に処理できるようになります。
2 XCMPとの融合について
XVMの将来的には、これをXCMPと統合し、Astar上のスマートコントラクトが、どのVMを使用しているかに関係なく、他のパラチェーン上のスマートコントラクトを呼び出せるようにしたい。
![](https://assets.st-note.com/img/1687655537196-HdNgwJzCAW.png?width=1200)
これにより、開発者は真にクロスチェーンなネイティブdAppを作成できるようになり、スマートコントラクトの機能をこれまでできなかったようなものまで拡張できるようになります。
3 新しいVMについて
最後に、EVMとコントラクト・パレットだけではマルチVMチェーンとは呼べません。
将来的には、スマート・コントラクトの非同期性をネイティブに処理し、クロスチェーンの呼び出しを非同期関数として抽象化できる別のVMを追加する予定です。
翻訳者注
WASMのVMも非同期性がネイティブなので、新しいVMとどう違うのかを疑問に持ちました。
![](https://assets.st-note.com/img/1687655886012-xa4awGMFFI.png?width=1200)
このVMはXVMと互換性があり、Astar Network上のすべてのdAppが、ユーザーに別のチェーンで別のアカウントを作成させたり、別のdAppをデプロイさせたりすることなく、クロスチェーン機能の機能を完全に利用できるようになります。
11 最後に
XVMを使用することで、EVMが支配する従来のブロックチェーンエコシステムを融合する際に発生する問題を排除し、EVMが提供する広大なエコシステムへのアクセスを犠牲にすることなく、新しいパラダイムのdAppプロジェクトがエコシステムに参入できるようになることがお分かりいただけたと思います。
WASMスマートコントラクトによって、プロジェクトがシンプルな非同期関数で他のブロックチェーンにアクセスして使用できるようになります。
そして、プロジェクトがスマートコントラクトを開発する際にSolidityに欠けている型安全性を恐れる必要がなくなり、WASMの拡張言語機能によって人材のプールとプロジェクトの多様性が向上する未来が見えます。
翻訳者注
WebAssembly(WASM)は、異なる多数のプログラミング言語をサポートしています。
C, C++, Rust, Go, TypeScriptなどの言語からWASMバイナリにコンパイルすることが可能です。
そのため、WASMスマートコントラクトを使用することで、さまざまな言語の知識を持つ開発者がブロックチェーンプロジェクトに参加できるようになります。
また、XVMを通じて、プロジェクトはWASMで構築することで何が失われるかを心配することなく、エンドユーザーに価値をもたらすものの構築に集中することができます。
翻訳者注
開発者がWASMを使用して開発することで、他の環境や言語で可能な機能を逃しているのではないかと心配する必要がないということです。
これは、XVMがEVMとWASMの両方の環境で動作し、各環境の機能を利用できるようにするためです。
Astar Networkは、あなたのイノベーションが始まる場所です。
12 Astarについて
Astar Network はマルチチェーンのためのスマートコントラクトの未来です。
![](https://assets.st-note.com/img/1687656389473-4WUet90rPR.png?width=1200)
Astar Networkは、EVMとWASMスマートコントラクトによるdAppsの構築をサポートし、クロスコンセンサスメッセージング(XCM)による真の相互運用性を開発者に提供します。
Astar独自のBuild2Earnモデルは、開発者が自分のコードと構築したdAppに対して、dAppステーキングメカニズムを通じて報酬を得ることを可能にします。
Astarの活気あるエコシステムは、世界的にPolkadotの主要なParachainとなり、すべての主要取引所とTier 1 VCによってサポートされています。
翻訳者注
Tier 1 VCsはTier 1 Venture Capitalistsの略で、最も一流とされるベンチャーキャピタル(VC)のことを指します。
ベンチャーキャピタルとは、起業家や新興企業に対して投資を行い、その成長を促進する企業や個人のことを指します。
Astarは、開発者がdAppsの構築を開始するために、すべてのイーサリアムとWASMツールの柔軟性を提供します。
PolkadotとKusama Networks上での成長を加速させるために、Astar SpaceLabsはトップTVL dAppsのためのインキュベーションハブを提供しています。
翻訳者注
TVLは"Total Value Locked"の略語で、DeFiのエコシステムにおいてよく使われる指標です。
これは特定のDeFiプロジェクトやプラットフォームにロックされている資産の総額を示します。
サポートをしていただけたらすごく嬉しいです😄 いただけたサポートを励みに、これからもコツコツ頑張っていきます😊