大時代エンジン WASM：スマートコントラクトとクロスチェーン相互作用の新范囲を推進
TechFlow厳選深潮セレクト
大時代エンジン WASM：スマートコントラクトとクロスチェーン相互作用の新范囲を推進
Wasmのポータビリティと高性能により、ブロックチェーン分野における重要な技術の一つとなっている。
Web3業界の深掘り報道に専念し潮流を洞察著者: Mike@Foresight Ventures
TL;DR
WebAssembly（通称Wasm）は、ポータブルで高性能なバイナリ命令フォーマットであり、Webブラウザ上で実行可能である。これは複数のプログラミング言語に対応する汎用的なコンパイルターゲットとして設計されており、異なるプラットフォーム間での実行が可能である。
ブロックチェーンは、暗号技術と合意形成アルゴリズムを用いてデータの安全性と信頼性を確保する、分散型の台帳技術である。取引記録やデータ保存、スマートコントラクトの実行などに利用できる。
Wasmとブロックチェーンの間には、以下のような関係性および応用シーンが存在する。
-
スマートコントラクト：Wasmはスマートコントラクトの実行環境として利用でき、異なるブロックチェーンプラットフォーム上でコントラクトを動作させることが可能になる。Wasmの高性能性とポータビリティにより、スマートコントラクトはより効率的に実行され、クロスプラットフォームでの利用も実現できる。
-
クロスチェーン相互作用：Wasmはクロスチェーン相互作用を実現するために使用できる。異なるブロックチェーンのロジックをWasmコードにコンパイルすることで、異なるチェーン上で同一のロジックを実行し、データ転送や相互作用を実現できる。
-
オンチェーン外計算：Wasmはブロックチェーン外部での計算に利用でき、その結果をチェーン上に提出できる。これにより、データの安全性と信頼性を保ちつつ、計算効率と柔軟性を高めることができる。
-
データプライバシー：Wasmはブロックチェーン上のデータプライバシー保護にも活用できる。機密データの処理ロジックをWasmコードにコンパイルし、チェーン上で実行することで、プライバシーを守りつつ計算の検証可能性を確保できる。
要するに、Wasmとブロックチェーンは相互に融合することで、より効率的で安全かつ柔軟なブロックチェーンアプリケーションやサービスを提供できる。Wasmのポータビリティと高性能性は、ブロックチェーン分野における重要な技術の一つとなっている。
一、Web Assemblyとは何か
WebAssemblyは、W3C（World Wide Web Consortium）が開発した高効率・軽量な命令セット標準であり、ネットワークと高性能処理の革新技術として注目され、クロスブラウザでの実行をサポートしている。つまり、C/C++、Go、Rustなどの異なるプログラミング言語を統一されたバイナリ形式にコンパイルし、JavaScriptの代替としてほぼネイティブレベルの効率でブラウザ上で実行できるようになる。
WebAssembly、あるいは略してWASMは、メモリセーフでプラットフォーム非依存であり、あらゆる種類のCPUアーキテクチャに効率的にマッピングできる。主な利点は以下の通りである。
-
高効率：WASMは完全な言語機能を持ち、実際にはサイズが小さく、読み込みが高速なバイナリフォーマットである。ハードウェアの能力を最大限に引き出し、ネイティブ言語と同等の実行効率を目指す。
-
安全性：WASMはメモリセーフかつサンドボックス化された実行環境で動作し、既存のJavaScript仮想マシン内でも実装可能である。Web環境では、WASMは同源ポリシーやブラウザのセキュリティポリシーを厳密に遵守する。また、WASMのコンパイル時にはインターフェースが限定的であり、多くのWASMアプリケーションはネットワーク接続できない（ソケット非対応）。現在はローカルデータベースのみサポートされている。多くのセキュリティ問題は実行時の不正なメモリアクセスに起因するが、WASMはコンパイル時にこれを回避できる。
-
互換性：WASMはバージョンレスで、機能テストが可能かつ後方互換性を持つように設計されている。JavaScriptから呼び出され、JavaScriptのコンテキストに入ることもできるし、Web APIのようにブラウザ機能を呼び出すことも可能である。WASMはブラウザだけでなく、Node.js、Deno、IoTデバイスなど非Web環境でも実行可能である。従来の方法では複数回のコンパイルが必要だったが、WASMでは一度のコンパイルで「プラグアンドプレイ」が可能となる。
さらに、Webは唯一真にユニバーサルなプラットフォームであり、あらゆるデバイスからアプリケーションにアクセスできる。これにより、単一のコードベースを維持でき、更新が簡素化され、すべてのユーザーがアプリケーションを利用できるようになる。WASMは64ビットおよび32ビット整数演算をサポートしており、CPU命令と一対一に対応している。浮動小数点演算を排除することで、決定性を容易に実現でき、これは合意アルゴリズムにとって必須である。LLVMコンパイラ基盤プロジェクトによって支えられており、WasmはLLVMの長年にわたるコンパイラ最適化の恩恵を受けることができる。WASMはGoogle、Apple、Microsoft、Mozilla、Facebookといった大手企業によって継続的に開発されており、これらの企業が開発するブラウザのバックエンドはすべてWASMのコンパイルをサポートしている。
WASMの素晴らしい点は、まるで魔法のエンジンのようで、どこでも動作でき、ダウンロードもインストールも不要なバイナリフォーマットであることだ。ワンクリックで必要なときにすぐにWebアプリを起動できる。ブラウザには組み込みのセキュリティ機構があるため、ダウンロードして実行するバイナリファイルよりも安全であり、実行中のコードがシステムに危害を加えることはない。また、Webアプリの共有も非常に簡単で、リンクはどこにでも貼れるクリック可能な文字列として扱える。
二、なぜ我々はWeb Assemblyを必要とするのか
2.1 Web2
ブラウザに組み込まれた機能とWebが提供するインタラクティブ性により、Webは静的なハイパーテキストコンテンツと軽量なスクリプト言語から、驚くべきアプリケーションと機能に満ちた強力で人気のあるプラットフォームへと進化した。しかし、現時点でもWebアプリケーションのほとんどは依然として同じスクリプト言語（JavaScript）によって駆動されている。だが、JavaScriptが当初設計された目的は、これらを実現することではなかった。
JavaScriptは当初、軽量なハイパーテキスト文書に少しのインタラクションを加えることを目的としたシンプルなスクリプト言語であった。学びやすく、書きやすいことを重視しており、実行速度を追求していたわけではない。しかし、ブラウザにおけるJavaScript解析の大幅な性能改善により、顕著なパフォーマンス向上が実現された。
JavaScriptの実行速度が向上するにつれ、ブラウザ内で実行可能なことが大きく拡大した。新しいAPIにより、インタラクティブなグラフィックス、ビデオストリーミング、オフライン閲覧などが可能になった。また、かつてはローカルアプリケーションに限定されていた多くのアプリケーションがWebに移行し始めた。今や、ドキュメントの編集やメールの送信を簡単にブラウザで行えるようになった。しかし、いくつかの分野では依然としてJavaScriptのパフォーマンスが課題となっている。ブラウザ以外で使用するソフトウェア、例えばゲーム、動画編集、3Dレンダリング、音楽制作などを考えてみよう。これらは大量の計算を必要とし、高いパフォーマンスが要求される。JavaScriptではこのような高性能要求には対応しきれない。
しかし、JavaScriptを置き換えるのは現実的ではなく、何十年もかかるかもしれない。インターネット全体がJavaScriptに依存しているためだ。それに、多くの人々が今もなおJavaScriptの改良に取り組んでいる。確かに、nullや==など他の言語と比べて劣る部分はあるが、それだけの理由で技術全体を交換する必要はない。
そのため、WebAssemblyはJavaScriptを置き換えるものではないが、将来誰もWASMを使わなくなるという意味ではない。実際、WASMの使用はますます広がっていくだろう。なぜなら、WASMはWebページに強力な計算能力をもたらすことができるからだ。画像処理やゲームなどに利用でき、PhotoshopのようなWeb版アプリを良好に動作させたり、60fps以上で動作する3Dゲームをブラウザ内で実行したりできる。特にゲームは難易度が高いが、音声と映像の処理だけでなく、物理効果やAIの調整も同時に行う必要がある。WASMがブラウザ上でゲームを効率的に実行できる能力は、他の多くのアプリケーションをブラウザに持ち込む可能性を開く。
上図はJavaScriptとWASMのワークフローの比較であり、WASMがJavaScriptよりもはるかに簡潔であることがわかる。
2.2 Web3
WASM VM
2018年、イーサリアムエコシステム内では、WASM VMをスマートコントラクトの仮想マシンとして導入する議論が始まった。これはEVMよりも性能が良いと考えられたためである。EVMの生みの親であるGavin Woodは、WASMがEVMを置き換える可能性について言及し、Vitalikもイーサリアム2.0がWasmコントラクト（eWASM）にアップグレードされ、より多くの開発ニーズに対応すると述べた。現在、Wasmコントラクトの発展はすでに一定の形を見せている。
2.3 EVMはどのように設計されているのか？ なぜ非効率なのか？
アーキテクチャのサイズ過大
従来のコンピュータが持つ命令セットは32ビットまたは64ビットの入力を受け付ける。一方、EVMは異なり、特殊な256ビットコンピュータとして意図的に設計されており、これはイーサリアムのハッシュアルゴリズムをより容易に処理するためであり、このアルゴリズムは明確に256ビットの出力を生成する。
しかし、実際にEVMプログラムを実行するコンピュータは、256ビットのワードを自らのネイティブアーキテクチャに分割して実行しなければならず、これがシステム全体を非常に非効率的かつ非実用的にしている。
また、イーサリアム上でSHA256のような複雑なアルゴリズムを基本OPCODESを使って実装しようとすれば、非常に困難な作業となる。命令セットを通じて複雑なプログラムを実行する際に発生する高額なガス問題を解決するため、イーサリアムはプリコンパイルという概念を導入し、プログラムをEVMに事前にコンパイルして固定ガスで実行可能とした。注目に値するプリコンパイルの一つがイーサリアムのハッシュアルゴリズムであり、仮にこれを仮想マシン内で実装すれば、コントラクトの呼び出し時に極めて高額な費用が発生する。
肥大化するプリコンパイル
プリコンパイルの問題点は、仮想マシンの肥大化と複雑化を招くことにある。これは根本的な問題、すなわち現在の命令セットと仕様の非効率で粗末な設計を解決できない。
もし、複雑なプログラムをプリコンパイルせず、基本命令だけで効率的に実装できるような新しい仕様と命令セットを定義できるとしたらどうだろうか？ まさにここでWASMが役立つのである。
2.4 EVMとWASM VMの比較
-
速度：WASMはEVMよりも高速な実行を目指している。EVMはスマートコントラクトのコンパイルと実行において効率の問題を抱えることがあるが、WASMはコンパイル済みコードへの直接変換により、読み込み速度と処理能力を向上させる。
-
プリコンパイル：EVMは暗号計算を効率的に実行するためにプリコンパイルコントラクトに依存しているが、これによりハードフォークのリスクが生じる可能性がある。WASMはプリコンパイルコントラクトへの依存を排除し、開発者が効率的で高速なスマートコントラクトを作成できるようにする。
-
取引手数料：より高速なWasm仮想マシンにより、取引のスループットが大幅に向上し、コントラクトの展開や取引コストも大きく削減できる。Wasmコントラクトは、現在のイーサリアムにおける高取引手数料と混雑問題をうまく解決できる。
-
柔軟性と相互運用性：Wasmはスマートコントラクト開発者が利用可能な言語の選択肢を広げ、Rust、C++、JavaScriptなど、任意のWasm対応の高級言語で複雑なビジネスロジックを開発できる。つまり、自分がよく知っている言語でスマートコントラクトを書くことができ、Rustベースのink!やAssemblyScriptベースのAsk!など、最も成熟したツールを選べる。
EWASMチームは、イーサリアム上でWebAssemblyを統合し、実行レイヤーをより効率的でシンプルなものにすることで、完全な分散型計算プラットフォームとしての適性を高めようとしている。WASMはすでにDfinityやEOSなど多くの他のプロジェクトで標準として採用されており、実行層の強化に活用されている。
2.5 Stylus（Arbitrum）
Stylusプロジェクトは、イーサリアムのレイヤー2ネットワークArbitrum上で、WebAssembly（WASM）仮想マシンを導入することで、スマートコントラクトの実行性能を向上させるものである。コントラクトはSolidityよりも高速に実行でき、ガスコストも削減される。これにより、Arbitrumネットワーク上で高性能なスマートコントラクトを構築しやすくなる。現在、C、C++、Rustのコンパイルがサポートされている。
カスタムプリコンパイルのサポート：Stylusはカスタムプリコンパイル（precompiles）もサポートしており、開発者は自身のRustやC++によるプリコンパイルをArbitrumネットワークに展開できる。これにより、チェーンアップグレードを待たずに新しい暗号アルゴリズムや特定の機能をチェーン上に導入できる。例えば、テンソル計算のプリコンパイルにより推論コストを下げ、チェーン上での機械学習に貢献できる。
EVMとの相互運用性：Stylusは、イーサリアム仮想マシン（EVM）との相互運用性を通じて、既存のイーサリアムエコシステムと統合される。つまり、Stylusコントラクトは既存のEVMコントラクトと相互にやり取りでき、EVMと同じグローバル状態を共有できる。
再入機能（Reentrancy）：Cosmos wasmとは異なり、Stylus Rust SDKは再入機能を導入しており、開発者が手動で有効化できる。これによりコントラクトの相互運用性がより柔軟になるが、セキュリティを確保するために状態管理を慎重に行う必要がある。
Arbitrumエコシステムの人気に支えられ、StylusはWASM統合において最も意義深い取り組みの一つとなり得る。同時に、zkrollupにおけるArbitrumの競争力にも好影響を与えるだろう。
2.6 Gear（Polkadot）
Gearプロトコルは、Polkadotのパラチェーンとして展開可能な技術の構築を目指している。これはスマートコントラクトのホスティングツールとなる。Polkadotと同様に、GearもSubstrateフレームワークを使用している。これにより、特定用途向けのブロックチェーンを個別に作成するプロセスが簡素化される。Substrateは豊富な機能を標準搭載しており、開発者はプロトコルの上にカスタムエンジンを構築することに集中できる。
以前はブロックチェーンを立ち上げるコストが高かったが、Gearにより、dApp開発者はブロックチェーン全体をゼロから構築・運営するのではなく、自分のプロジェクトに集中できるようになる。
Gearプロトコルの中核となるのはスマートコントラクトモジュールである。Gearの場合、任意のスマートコントラクトはRust、C、C++などの異なる言語でコンパイルされたWebAssemblyプログラムである。暗号世界外の開発者にとっても、慣れ親しんだ環境でスマートコントラクトを構築できるため、参入障壁は低い。開発者はより簡単にスマートコントラクトのプログラミング言語を試せる。
Gearのスマートコントラクトアーキテクチャは内部でアクターモデルを使用しており、以下の機能を提供する。
-
不変プログラムに対する永続的メモリ
-
非同期メッセージ処理
-
ブロックチェーンコンテキスト向けの最小限で直感的かつ十分なAPI表面
-
チェーン上コンポーネント間のアクター通信プロキシモデルにより、高い合成性、並列コード実行およびシャーディングとの互換性が向上する。
各プログラムは固定量のメモリを持ち、Gearではこれを制御できる。プログラムは自身のメモリ空間でのみ読み書き可能であり、他のプログラムのメモリにアクセスすることはできない。各プログラムは独立したメモリ空間を持ち、Gearノード上で情報を並列処理できる。
2.7 CosmWasm（Cosmos）
CosmWasmは、現代的で強力なWasmベースのスマートコントラクトプラットフォームであり、Cosmos-SDKに簡単に統合できる。CosmWasmの主な利点の一つは、IBC（Inter-Blockchain Communication）とネイティブに連携するコントラクトが書ける点であり、開発者とユーザーがマルチチェーンの未来に入り込める。現在はRustのみサポートしている。
CosmWasmの利点
-
安全性：Rust言語を使用することで、スマートコントラクトの安全性が向上する。
-
クロスチェーン互換性：Cosmosエコシステム内のIBC（Inter-Blockchain Communication）プロトコルをサポート。
-
パフォーマンス：従来のEVM（イーサリアム仮想マシン）と比較して、CosmWasmは一部のケースでより高い効率と低い取引手数料を示している。
-
開発者フレンドリー：Rust言語の型安全性とメモリ安全性により、スマートコントラクト内の特定のエラーを低減できる。
課題と制限
-
学習曲線：Solidityなど一般的なスマートコントラクト言語と比べ、Rustは初心者にとって学習曲線が急峻である可能性がある。CosmWASMが大規模に採用されるためには、より多くの言語のコンパイルをサポートする必要がある。
-
エコシステムとツールの支援：成長中ではあるが、成熟したスマートコントラクトプラットフォーム（例：Ethereum）と比べ、CosmWasmの開発ツールやエコシステムはまだ限られている。
-
市場占有率と知名度：スマートコントラクトプラットフォームの中で、CosmWasmはEthereumやBinance Smart Chainなどと比べて知名度が低く、開発者やユーザーを惹きつける力に影響を与えている。
-
メンテナンスとアップグレードの課題：CosmWasmはコントラクトのアップグレード機能を提供しているが、スマートコントラクトのメンテナンスとアップグレード管理は依然として複雑な作業であり、セキュリティホールを避けるために注意深く扱う必要がある。
-
互換性の問題：EVMや他のスマートコントラクト環境に慣れたプロジェクトにとっては、CosmWasmへの移行が互換性の課題を伴う可能性がある。
2.8 ZK-WASM
WASM仮想マシンに加えて、最近登場した新技術ZKWASMがある。開発者Delphinus LabsはすでにGitHub上でZK-WASMのコードをオープンソース化している。ZKWASMにより、開発者は再実行なしに既に実行された計算の正当性を検証できる。ZKWASMを利用することで、開発者はさまざまなプログラミング言語でZKPアプリケーションを柔軟に構築できる。これらのアプリケーションはWebブラウザ上でシームレスに実行可能である。
ZKWASMの概念はZKSNARKに由来する。ZKSNARKはSNARGとゼロ知識証明の混合体である。通常、ZKSNARKを使うにはPinocchio、TinyRAM、Buffet/Pequin、Geppetto、xJsnarkフレームワーク、ZoKratesなどの算術回路言語または回路に適した言語でプログラムを書く必要がある。これは既存のプログラムにとって障壁となり、ZKSNARKの力を十分に発揮できない。しかし、もう一つの方法として、ソースコードレベルではなく、仮想マシンのバイトコードレベルでZKSNARKを使用し、ZKSNARK対応の仮想マシンを実装する方法がある。Delphinus Labsは後者のアプローチを採用し、WASM仮想マシン全体をZKSNARK回路に書き込んだ。これにより、既存のWASMアプリケーションは一切修正せずにZKWASM上で直接実行できる。したがって、クラウドサービスプロバイダーは、いかなる個人情報も漏らすことなく、計算結果が誠実に計算されたことをユーザーに証明できる。
ZKWASMは、ブラウザ内操作のZK証明をブロックチェーンに提出できるなど、多様なユースケースを提供する。これにより、ウェブ操作のブロックチェーン上での検証が可能になる。また、オラクル、オンチェーン外計算、自動化、Web2とWeb3の接続、機械学習やデータ処理の証明生成、さらにはゲームやソーシャルアプリにも応用できる。採用が進むにつれ、zkWASMはWeb3の可能性を広げ、Web2開発者をこの変革的な枠組みに巻き込んでいくだろう。
Delphinus LabのZKWASM実装により、開発者はゼロ知識証明の力を活用してアプリケーションのセキュリティとプライバシーを強化でき、より信頼性が高く分散化されたデジタル社会の実現に貢献できる。
三、結論
Webのパフォーマンスとスマートコントラクトプラットフォームの実行層の将来は明るい。dAppはより高いパフォーマンスを持つだけでなく、WASMの統合により、RustやGoのような主流言語に精通した開発者が、Solidityや他のブロックチェーン開発言語の細部を学ぶことなく、イーサリアム上で有用なアプリケーションを開発できるようになる。Evans Data Corporationのデータによると、世界には約2700万人の開発者がいる。この数字は着実に増加しており、昨年は約3%増加し、2024年には2870万人を超えると予想されている。一方、ブロックチェーン上で開発している開発者は3万人未満であり、全開発者の約千分の一程度に過ぎない。この数字は着実に増加しているが、新しいスマートコントラクト言語を学ぶことは、依然として開発者がブロックチェーンに参入する際の障壁となっている。
しかし、ますます多くのブロックチェーンがWeb Assemblyをコンパイル済みスマートコントラクトのバイトコードとしてサポートし始めている。WASMがブロックチェーンにもたらすものは、効率性、相互運用性、幅広い応用シーンにとどまらず、開発者を解放する鍵でもある。これにより、ブロックチェーンへの参入障壁が低下する。想像してみてほしい。近い将来、Web2の開発者がブロックチェーン開発に挑戦するとき、彼らが慣れ親しんだPython、C++、JavaScriptを使ってブロックチェーン上で大規模なアプリケーションを開発できる時代が来る。これにより、ブロックチェーンの分散ネットワークの価値が最大限に引き出され、まずクリエイター（開発者）の参入障壁を下げ、次にユーザーの障壁を下げ、Mass Adoptionへと向かう。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
Foresight Ventures
