【完全保存版】EVM以外のVMを使用しているスマートコントラクトプラットフォームについて
当記事は、こちらの記事を翻訳・編集したものです。
０ はじめに
スマートコントラクトは、特定のニーズに合わせた、ブロックチェーン上のオリジナルの利用シーンを構築することができます。
ブロックチェーンがスマート・コントラクトをサポートするには、スマート・コントラクト実行環境またはスマート・コントラクト仮想マシンが必要です。
最も人気のある環境はイーサリアム仮想マシン（EVM）で、イーサリアム・ブロックチェーンによって最初に導入され、その後、イーサリアムが作ることができた巨大なエコシステムを活用したい多くの異なるネットワークによって採用されました。
しかし、EVM以外のスマートコントラクト仮想マシンもあり、そのほとんどはWebAssembly（WASM）をベースにしています。
１ EVMとWASMの比較
EVMはスタックベースのステートマシンで、EVMのオペコードをブロックチェーンの上で実行できる計算命令に解釈します。
翻訳者注
「EVMのオペコード」とは、EVMが理解し、計算命令として実行するための一連の命令セット（コード）を指します。
これは、スマートコントラクトを動作させるためのプログラム命令です。
翻訳者注
スタックについては、こちらの記事の第１章で詳細に扱いました。
これは、Polkadotの創設者であるGavin Wood博士によって作られました。
開発者はSolidityやVyperなどのコントラクト指向言語を使って、EVMのバイトコードまでコンパイルできるアプリケーションを書くことができます。
EVMは1024アイテムの深さを持ち、各アイテムは256ビットのワード（長さ）です。
1024項目という制限は、EVMスマートコントラクトの複雑さに本質的な限界があることを意味します。
その上、すべての演算が256ビットであるため、256ビットでないプロセッサー（つまりすべて）は、これらの演算を計算する際にかなりのオーバーヘッドを抱えることにもなります。
翻訳者注
現代の一般的なコンピュータプロセッサは、32ビットまたは64ビットのデータを基本単位として操作を行います。
その結果、EVMが256ビットの演算を行うたびに、一般的なプロセッサは複数のステップを必要とします。
この追加の計算ステップがオーバーヘッドとなり、スマートコントラクトの実行速度を遅くし、効率を低下させる可能性があります。
さらに、EVMバイトコードはゼロから作られているため、他の言語がEVMをターゲットにする場合、コンパイラをゼロから作らなければならず、拡張性が非常に難しくなるため、言語能力も問題となります。
翻訳者注
新しい言語をサポートするためには、それぞれに対して新しいコンパイラを開発しなければならず、これは時間とリソースを必要とします。
また、コントラクト指向言語としては珍しい構文であるため、参入障壁が非常に高いことは言うまでもありません。
全体として、EVMの制限により、Solidity dAppの開発者が複雑なユースケースを作成することは非常に困難です。
より高度なユースケースになると、スマートコントラクトはより複雑さを要求し、EVMはその限界を見せています。
そこで登場するのがWASMベースのスマートコントラクトです。
WASMは技術的にはバイナリ命令フォーマットで、V8などの命令を実装したスタックベースの仮想マシン上で実行できます。
翻訳者注
「V8」は、Googleが開発したJavaScriptエンジンであり、Chromeブラウザで使用されています。
V8は、JavaScriptだけでなくWebAssemblyの命令も実行することができます。
しかし、一般の人々やこの文脈では、WASMと言えば、WASM命令を実行できる一般的な仮想マシンを指します。
WASM自体は、ブラウザ環境からネイティブレベルの操作を実行するための共通規格です。
Google、Microsoft、Mozilla、Appleなどの業界リーダーが開発を主導しています。
WASMのパワーを使えば、ゲームのようなハードウェア負荷の高い作業も、ネイティブレベルに近いパフォーマンスでブラウザから実行できます。
EVMと同様に、WASMもバイトコードで動作するスタックベースのVMです。
WASMでプログラミングするということは、WASMのサンドボックス（VM）内でのみ実行可能なWASMバイトコードにコンパイルできる高級言語を使うということです。
言い換えれば、WASMはスマートコントラクトVMにとって完璧な適合性を持つ可能性があります。
翻訳者注
スマートコントラクトのVMは、スマートコントラクトのコード（通常はバイトコード形式）を安全かつ効率的に実行するための環境を提供します。
これには高速な実行、セキュリティ、サンドボックス化（独立した実行環境）、そして異なるプログラミング言語からコンパイルされたコードのサポートが必要です。
WASMはこれらの要件を満たす特性を持っています。
それはバイナリ命令形式であり、これによりコードは高速に実行されます。
また、セキュリティが重視され、WASMのコードはサンドボックス化された環境で実行されるため、他のシステムへの影響を最小限に抑えます。
さらに、多くの現代のプログラミング言語はWASMへのコンパイルをサポートしています。
このように、WASMの特性がスマートコントラクトのVMの要件と一致するため、「WASMはスマートコントラクトVMにとって完璧な適合性を持つ可能性がある」と表現されています。
WASMにインスパイアされた、あるいはWASMを直接使用したカスタムVMを使用する高パフォーマンスのネットワークが増えているように、多くの人気のあるブロックチェーンがこの思いを共有しています。
WASMがEVMに対して持つ主な利点は以下の通りですが、これらに限定されるものではありません。
ネイティブの32/64ビットオペレーション
広範な言語サポート
エコシステムの拡張が容易
高いパフォーマンスと互換性
翻訳者注
「エコシステムの拡張が容易」について、WASMは多くの主要なプログラミング言語からコンパイルすることができます。
これにより、既存の開発者が既知の言語を使用してブロックチェーンやスマートコントラクトのアプリケーションを開発しやすくなります。
さらに、新しい言語やツールがWASMに対応するためのコンパイラを作成しやすいことから、WASMは新たな技術や開発手法の導入を促進します。
また、WASMは既存の多くのWebブラウザでネイティブに実行されます。これにより、ブロックチェーンとWeb技術の統合が容易になり、ブロックチェーンのアプリケーションがより広いユーザーベースにアクセスできるようになります。
WASMベースのスマートコントラクトが技術的にEVMより優れていることはわかりましたが、dApp開発に関してはなぜEVMがいまだに王者なのでしょうか？
なぜ多くのネットワークがいまだにEVMを使っているのでしょうか？
簡単な答えは、その開発者エコシステムがあるからです。
Solidityは多くの新しいdApp開発者にとってゲートウェイ言語であり、流動性の高いブロックチェーンのほとんどがEVMをサポートしているため、新しいプロジェクトがEVMを無視することは難しくなっています。
それでは、代替VMを使用している他のブロックチェーンネットワークは、EVMにもかかわらず、どのようにエコシステムを維持しているのでしょうか？
２ その他のスマートコントラクトプラットフォーム
１ Solana
Solanaは、そのほぼ瞬時の確定性（finality）とスマート・コントラクトのパフォーマンスでよく知られています。
翻訳者注
ネットワークが「near-instant finality」を持つ場合、トランザクションはほぼ即座に確定し、その結果はネットワーク全体で不可逆となります。
この特性は、ブロックチェーンネットワークの性能とスケーラビリティに大きな影響を与えます。
トランザクションが迅速に確定すれば、その分だけネットワーク上で一度に処理できるトランザクションの数が増え、ユーザーエクスペリエンスも向上します。
これは特に高頻度のトランザクションが行われる状況（例えば、金融取引や大規模な分散アプリケーション）で有利となります。
興味深いことに、彼らはスマート・コントラクトを「オンチェーン・プログラム」と呼んでおり、C++やRustで書くことができます。
そして技術的には、SolanaはWASMでは動作しません。
代わりに、彼らはVMとしてBerkeley Packet Filter(BPF)バイトコードを使用します。
しかし、コントラクト言語は、彼らのプログラムをコンパイルするためにLLVM（WASMをターゲットとする同じコンパイラ）を使用しています。
翻訳者注
少し長いですので、ご存じの方は飛ばしてください。
LLVMは、コンパイラとツールチェーンの構築を目的としたライブラリとツールの集まりです。
LLVMはそのフレームワークの一部として、一連の中間表現（IR、Intermediate Representation）を定義しています。
これはLLVM IRと呼ばれ、プログラムを表現するための言語です。
LLVM IRは静的型付けを持つ、そしてRISC-like（Reduced Instruction Set Computerのような）の命令セットを備えています。
LLVMは様々な最適化をLLVM IR上で行います。
これにより、どの言語で書かれたプログラムも同じように最適化できるという利点があります。
さらに、LLVMはバックエンドとして様々なアーキテクチャをサポートしており、x86、ARM、MIPS、RISC-Vなど多くのプラットフォームに対応しています。
コードはまずフロントエンド（例えばClangなど）によってLLVM IRに変換され、最適化が施された後、特定のアーキテクチャ向けにコード生成が行われます。
これにより、LLVMは様々なプログラミング言語とハードウェアプラットフォームをサポートすることが可能となります。
そのため、必要な変更を最小限に抑えてWASMに再コンパイルできます。
翻訳者注
LLVMを用いたプログラムは必要な変更を最小限に抑えてWASMに再コンパイルすることが可能です。
主なドキュメントはSolanaの公式ドキュメントにあります。新しい開発者はここから始めることになります。
しかし、コアチームによって維持され、支持されている他の教材はありません。
彼らのクライアントAPIである@solana/web3.jsは、オンチェーンプログラムとの通信がどのように機能するかという点で、精彩を欠いています。
しかし、彼らの最大の強みは、Solanaコマンドラインツールと呼ばれるオールインワンツールにあります。
単一のCLIツールから、ユーザーは以下の機能を使うことができます
faucet エアドロップ
アカウント管理
オンチェーンプログラムのデプロイ
トランザクションの構築
ノード管理
ステーキング
署名ユーティリティ
翻訳者注
署名ユーティリティとはデジタル署名に関連する機能のことを指しています。
デジタル署名は、電子情報（メッセージ、ドキュメント、トランザクションなど）の真正性や完全性を保証するために使用される暗号学的な手法で、ブロックチェーン技術においては非常に重要な役割を果たします。
CLIにはscaffolding（基本的なテンプレート）が埋め込まれていませんが、コア・チームが管理する別のリポジトリがあり、開発者はそれをプロジェクトに使用することができます。
２ Near
Nearはnightshadeシャードと高性能なWASMスマートコントラクトVMで有名です。
翻訳者注
Nightshadeシャードは、Near Protocolが採用しているシャーディング技術の一部です。
シャーディングとは、データベースの管理を効率的に行うための一般的なテクニックで、大きなデータベースをより扱いやすい小さな部分（シャード）に分割することを指します。
ブロックチェーンの文脈では、シャーディングはネットワークのスケーラビリティ（拡張性）を向上させるための一つの手法です。
しかし、開発者の間で有名なもう一つの理由は、その洗練された開発者エコシステムでしょう。
RustとAssemblyScript（TypeScriptの一種）でNearのスマートコントラクトを書くことができます。
Solanaと同様、Nearにも単一のドキュメントサイトがあります。
初めて開発する人は、クライアントサイドとスマートコントラクトの両方の開発にこのドキュメントが必要なだけで、その中にノード管理/開発へのリンクもあります。
また、フロントページには、学びたい開発者に役立つ外部リソースのリストもあります。
Nearはまた、near-api-jsと呼ばれる独自のJavaScriptクライアントAPIを持っています。
開発者はこのAPIを使って、スマートコントラクトの呼び出しやトランザクションの実行など、ノードのあらゆるRPCを作成できます。
翻訳者注
RPCは「Remote Procedure Call」の略語で、遠隔手続き呼び出しという
意味です。
これは、ネットワークを通じて別のコンピューター上のプログラムやサービスに対して、あたかも自分のローカルシステム上のプログラムであるかのように関数や手続きを呼び出すためのプロトコルまたは技術です。
これはNode.jsのCLIツールで、near-api-jsをバックにしてNearブロックチェーンとやりとりします。
Near CLIでは以下のことができます。
アカウント管理
スマート・コントラクトのデプロイ
スマートコントラクトとの対話
トランザクションの構築
バリデータの管理
ScaffoldのdAppリポジトリ（コントラクトとフロントエンド）
３ Cosmos
Cosmosエコシステムは、相互運用性を念頭に置いたモジュラー型ブロックチェーンを構築するためのコアSDKを備えているという意味で、Polkadotエコシステムとよく似ています。
翻訳者注
モジュール式の設計（またはモジュラー設計）とは、システムを独立した部品（モジュール）に分割する設計手法を指します。
これらのモジュールはそれぞれ独立して機能し、そして一緒に組み合わせることで全体のシステムを形成します。
コアSDKがモジュール式の設計を可能にするというのは、開発者が必要な機能を持つモジュールを選択し、それを組み合わせてカスタムブロックチェーンを構築することができるということを意味します。
例えば、あるブロックチェーンはスマートコントラクト機能が必要な場合、その機能を持つモジュールを追加できます。
また、異なるコンセンサスアルゴリズムを使用するブロックチェーンを構築したい場合は、そのアルゴリズムを実装するモジュールを使用できます。
CosmWasmはCosmos SDKのモジュールで、Cosmosエコシステムにスマートコントラクト機能を追加します。
これを使用する有名なネットワークにTerraがあります。
現在、CosmWasmはRustスマートコントラクトのみを公式にサポートしていますが、コアモジュールはGoを使用して作られているため、将来的には言語サポートの拡大が想像できます。
CosmWasmはCosmos SDKのモジュールであるため、メインのCosmWasm開発者ドキュメントと、CosmWasmモジュールを使用するCosmosエコシステムのプロジェクトによって維持されている複数の小さなドキュメントがあります。
例えば、Terra Academyは、Rustを使ったハンズオン開発とCosmWasmを使ったスマートコントラクトの開発を学ぶための主な情報源です。
そして、Terraのメイン・ドキュメントには、CosmWasmスマート・コントラクトの開発者リファレンスしか含まれていません。
開発者向けドキュメントのほとんどは、CosmWasmのメインドキュメントページにあります。
しかし、CosmWasmは独立したブロックチェーンではないため、ほとんどの新規開発者はCosmWasmモジュールを使用しているプロジェクトによって管理されているドキュメントから始め、最終的にメインドキュメントを参照して詳細を確認することになります。
翻訳者注
つまり、最初はTerraのようなブロックチェーンプロジェクトを通じ、CosmWasmが実際にどのように使われているのかを学ぶかもしれません。
そして、その後、CosmWasmの公式ドキュメントに進むという流れが考えられます。
CosmWasmは、CosmJsと呼ばれる独自のJavaScript APIと、Terra Network上のWASMスマートコントラクトと対話するために作られたTerra.jsを持っています。
他のネットワークとは異なり、CosmWasmは専用のオールインワンCLIツールを持っていません。
その代わりに、cargoを使用してRustスマートコントラクトをコンパイルし、wasmdと呼ばれるGo CLIを使用してターミナルからデプロイして対話します。
しかし、CosmWasmの開発環境をセットアップするには、多くの手動設定や前提条件が必要です。
そのため、TerraにはTerrainというオールインワンのCLIツールがあります。
Terrainでできることは以下の通り
アカウント管理
ネットワーク管理
Scaffold dAppリポジトリ（コントラクトとフロントエンド）
テスト
スマートコントラクトのデプロイ
コントラクトとの対話
クライアント・スクリプト・フレームワーク
翻訳者注
"Client script framework"とは、クライアントサイドで実行されるスクリプトやプログラムを作成、管理するためのフレームワークのことを指します。
これは、スマートコントラクトと対話するためのクライアントアプリケーションや、スマートコントラクトの動作をテストするためのスクリプトなどを作成するために使用されます。
クライアントスクリプトフレームワークは、特定のタスクを自動化したり、一貫性のある開発環境を提供するためのツールやライブラリのセットを提供することで、開発の効率化と品質の向上に寄与します。
４ Polkadot／Substrate
Polkadotのエコシステムもまた、Polkadotネットワーク自体がスマート・コントラクトをサポートしないという興味深い構造を持っています。
その代わりに、Substrate（Polkadot SDKに相当）で構築されたブロックチェーンは、コントラクト・パレットと呼ばれるランタイム・モジュールを実装することができます。
このパレットを実装すれば、どのブロックチェーンでもWASMスマートコントラクトを実行できるようになります。
現在、ink!（RustのeDSL）をサポートしており、AssemblyScriptのeDSLをサポートするための作業も行われています。
翻訳者注
eDSL（embedded Domain Specific Language）は、特定の問題領域（ドメイン）に特化したプログラミング言語をホスト言語内に埋め込むことで作成されるプログラミング言語の一種です。
Substrateはコントラクトパレット、WASMコントラクト言語（ink）、JavaScript APIを別々のプロジェクトとして扱っているため、SubstrateのWASMコントラクトのドキュメントはかなり乱雑で、単一のソースではなく分散しています。
Substrateノード開発者は、Substrate開発者向け公式ドキュメントやワークショップでコントラクトパレットについて学ぶことができます。
Polkadotのエコシステムを構築したい新規開発者は、Polkadotの公式ドキュメントがあります。
しかし最終的には、ink!の公式ドキュメントや、Astar Networkのような各パラチェーンの開発者向け文書から、詳細な開発ガイドラインを読む必要があります。
おそらく、Polkadot/Substrateエコシステムのための最も包括的で成熟したWASMスマートコントラクト開発者向けドキュメントは、SuperColonyによって維持されているOpenBrushでしょう。
ink!を使った一般的なWASMコントラクト開発については、これが最高のソースです。
翻訳者注
OpenBrushは実際にとても便利だと思います。
Polkadot/Substrateには、@polkadot/apiと呼ばれるJavaScript APIもあり、これにも独自のドキュメントがあります。
翻訳者注
こちらもかなり使うことになると思います。
スマートコントラクトAPIはPolkadot APIパッケージの一部であるため、ドキュメントはPolkadot.jsチームによって管理され、ここに保管されています。
ご覧のように、Polkadot/Substrateエコシステムには、他のプロジェクトのようにWASMスマートコントラクトを開発するための単一のドキュメントがありません。
また、コントラクトパレット、言語コンパイラ、コントラクトとやり取りするためのJavaScript APIは別々のプロジェクトとして扱われているため、新しい開発者が一目ですべてを確認できる単一のソースがなく、ドキュメントが別々に保管されています。
CLIツールについては、Polkadot/Substrateは、Terrain、Near CLI、Solana CLIのようなスマートコントラクトを構築するためのオールインワンツールや標準的な開発者環境を持っていません。
その代わり、ツールはSubstrateノード管理ツールと言語コンパイラツールに分かれています。
（スマートコントラクト開発者のためのノードセットアップとアカウント管理プロセスを合理化するRedspotというツールがありましたが、このツールは現在保守されていません。）
Substrate CLIは以下を提供します。
アカウント管理
署名者ユーティリティ
ノード管理
ネットワーク管理
ink!コントラクト・コンパイラCLI（Cargoコントラクトとしても知られています）はこちらです。
コントラクトのビルド
コントラクトのデプロイ
ユニットテストの実行
スマート・コントラクトとの対話
コントラクトデータのデコード
５ 一目でわかるエコシステム
さて、WASMコントラクト・エコシステムが提供するものを探ってきたので、これらのネットワークを比較対照してみましょう。
お分かりのように、単一のブロックチェーン・ネットワークが統一された開発者環境とドキュメントを提供する方がはるかに簡単で、新しい開発者が一目ですべてを理解しやすくなります。
一方、CosmosやPolkadot/Substrateのようなブロックチェーンフレームワークやレイヤー0チェーンは、特定のネットワークに偏りが出る可能性があるため、統一された開発者環境やCLIツールを作るのが難しいです。
翻訳者注
"Layer 0 chain"とは、ブロックチェーンのインフラストラクチャの最も基礎的なレベルを指す用語です。
これはブロックチェーンのスタックの最下部に位置し、その上に複数の別々のブロックチェーン（Layer 1）やその上のアプリケーション（Layer 2）が構築されることを可能にします。
Layer 0のチェーンは、多くの場合、異なるブロックチェーン間での相互運用性や、スケーラビリティといった問題を解決しようとしています。
これらのチェーンは、通常、プロトコルレベルでの相互運用性を提供し、それにより個々のブロックチェーンネットワークが互いに通信したり、トランザクションを交換したりすることを可能にします。
PolkadotやCosmosは、このLayer 0の例としてよく挙げられます。
これらのネットワークは、個々のブロックチェーン（これらは"Parachains"（Polkadot）または"Zones"（Cosmos）と呼ばれます）が独自のルールやロジックを持ちながら、同時に一つの共有のセキュリティモデルと共有の通信プロトコルの下で相互作用することを可能にします。
だからこそ、そのフレームワークの上に構築されるブロックチェーンが、Terraのようにドキュメントやツールを提供するのは自然なことです。
CosmWasmは、Substrateのように言語、コントラクトモジュール、JavaScript APIをすべて別個に扱うのではなく、ひとつのプロジェクトの一部として扱うため、Substrateの扱い方よりもはるかに統一されています。
次にツールのサポートを見てみましょう。
NearやSolanaのようなブロックチェーンが開発者により統合されたオールインワンのツールを提供しているのに対して、CosmWasmを持つCosmosエコシステムは基本的な機能しか提供しておらず、既存のツールとともに完全に統合された環境を構築するためにTerraのようなエコシステムのプロジェクトに依存していることは明らかです。
一方、SubstrateのCLIツールは、開発者が最初にデプロイターゲットとしてローカルコントラクトノードをセットアップしなければならないため、非常に散在しています。
Cargoコントラクトはありますが、Substrateエコシステムはaskのようなスマートコントラクト言語が増えることを期待しています。
３ WASMを再びスワンキーに😎
これまでのセクションでお分かりのように、WASMコントラクトのエコシステムはまだ新しいものですが、この技術を大量採用に向けて強力に推進している注目度の高いプロジェクトがたくさんあります。
しかし、Substrateエコシステムの進歩は、基礎となるテクノロジーが優れていないとしても、同等であるにもかかわらず、まだ遅れており、混乱しているように見えます。
そこで我々の出番となります。
Astar Networkは、Astar Networkの相互運用性を活用したいすべての将来のdAppsのために、Substrate WASMエコシステムを推進することを目指しています。
そのために、私たちAstar Networkは、Astar Networkから開発者の旅を始める開発者ドキュメントの統一、開発者教育の強化、新しい革新的なWASM dAppsのインキュベーションと助成金の提供、そして最も重要なSwanky CLIの作成に注力します。
Swanky CLIは、私たちのエコシステムが最も必要としているSubstrate WASMコントラクト開発者のためのオールインワンCLIツールです。
このツールはまだ開発中ですが、以下のような様々な機能をサポートする予定です。
ユニットテスト
コントラクトの相互作用
デプロイ
アカウント管理
開発者ノードのセットアップ
6月末までには、そして将来的には、以下を追加する予定です：
統合テスト
フロントエンド・アプリとコントラクトの両方のためのスキャフォールディング
その他多数
コードベースはモジュール性を念頭に作られているため、Swankyは、エコシステムを拡大するために、より多くのプロジェクトが参加するにつれて、複数のスマートコントラクト言語のサポートを追加する予定です。
私たちはスマート・コントラクトの未来の一部になれることに興奮しています。
そして、WASMスマートコントラクト開発者エコシステムへのヒッチハイクガイドはこれで終わりです。
ありがとうございました。
いいなと思ったら応援しよう！
