なぜArbitrum Stylusが今年のL2における最も重要な技術革新なのか？

2023.10.09

共有先

TechFlow厳選深潮セレクト

なぜArbitrum Stylusが今年のL2における最も重要な技術革新なのか？

StylusをArbitrumのLayer2 SDKに統合することで、第3層の開発者に大きな柔軟性を提供できる。

2023.10.09 - 10:51:09

Web3業界の深掘り報道に専念し潮流を洞察

StylusをArbitrumのLayer2 SDKに統合することで、第3層の開発者に大きな柔軟性を提供できる。

著者：Yiping, IOSG Ventures

zkSyncやStarkNetといったZKRUsが本格的にメインネットを展開する中、Layer2の構造は急速に進化している。従来、OPRUsであるArbitrumが市場投入の先駆者として、より強力なエコシステムを築いてきた。一方で、ZKRUsは技術的な突破により、高いスループットと低コストを実現している。

ここ数ヶ月、高速かつ低コストのトランザクションを求めて、Layer1からLayer2への移行が加速している。イーサリアムのTVLは過去1年間で約400億ドルから200億ドルに減少した。しかし、Layer2のTVLは異なる状況を示しており、大幅な成長はLayer2の採用が加速していることを示している。

ArbitrumはLayer2 TVLの50％以上を占めるシェアでリードしているが、ZKRUsも着実に努力を重ねている。Arbitrumの先行者メリットがその支配的地位を維持させている。

日次取引件数を分析すると、zkSyncやStarkNetのようなZKRUsがスループットにおいてわずかにOPRUsを上回っている。しかし、Arbitrumのエコシステム上の優位性は依然として強く、日次TPSではやや後れを取っている。

OPRUsはZKRUsよりも早く登場したが、ZKRUsは現在本格的なメインネット展開を進め、他のエコシステムからユーザーを引き寄せつつある。OPRU分野のリーダーであるArbitrumは、今後のアップデートを通じてZKRUsの台頭に対抗していくと予想される。

Arbitrum：Stylus

開発者がゼロナレッジ技術の最適化とコスト削減を進める中、拡張性の利点からZKRUsのシェアはさらに拡大する可能性がある。しかし、Arbitrumのネットワーク効果は競争圧力の中でも安定した地位を維持できる能力を提供している。Stylusのような革新的なソリューションにより、Arbitrumは独自の技術力を補完し、Layer2の競争でリードし続けることができる。

簡単に言えば、StylusはArbitrum向けに設計された画期的な新しいスマートコントラクト環境であり、Rust、C++、Solidityなどのプログラミング言語を使って、効率的で相互運用可能なプログラムを作成できるようにするものだ。

これによりブロックチェーンへの汎用計算が開放され、さまざまな技術スタックを持つ開発者が参加できるようになる。

WASM

Stylusは、既存のイーサリアム仮想マシン（EVM）と並列して動作するWebAssembly（WASM）仮想マシンを追加することで機能する。WASMにコンパイル可能な言語で書かれたスマートコントラクトは、Solidityよりも最大10倍以上の速度でネイティブ実行され、ガス費用を大幅に削減できる。EVMは完全に機能し続けるため、既存のSolidityコントラクトはこれまで通り正常に動作する。二つのVMは同期して動作し、異なる言語で書かれたコントラクトが互いに呼び出し合いながら、同じ基本的なブロックチェーン状態を変更できる。

カスタムプリコンパイル

また、Stylusはカスタムプリコンパイル（Precompiles）もサポートしている。

プリコンパイルとは、EthereumおよびArbitrum上で特定の暗号化処理やユーティリティ関数を非常に効率的に実行するための低レベルモジュールである。例えば、ECDSA署名検証やSHA256ハッシュ計算のためのプリコンパイルが存在する。

新たなプリコンパイルを追加するには、すべてのバリデータがEVMのアップグレードを協調して行う必要があり、ハードルが高い。しかし、Stylusを使えば、開発者はRustやC++で自作のプリコンパイルを簡単にデプロイできる。

たとえば、あるチームがC言語で書かれた暗号ライブラリをそのままArbitrumにデプロイできる。これにより、これらの暗号プリミティブが超高速なネイティブ速度で実行可能になる。

他のコントラクトは、このStylus「プリコンパイル」を、本来のプリコンパイルのように呼び出して、その暗号技術を利用できる。すべてのガス計測と詐欺証明は自動的に機能する。

これにより、特別なチェーンサポートなしに、カスタム暗号、ペアリングベースの特殊曲線、新しいタイプのプリミティブなどをプロトタイピングできる。イーサリアム研究者さえも、EIP提案をArbitrum上でStylusプリコンパイルとして先行的に展開・反復できる。

開発者がチェーン上でネイティブに新しい暗号プリミティブを導入できるようにすることで、Stylusは構築可能なものの範囲を大きく広げた。プリコンパイルはもはやEVMがサポートする機能に限定されない。

Stylusの仕組み

WASMがブロックチェーン宇宙で果たすより広範な役割を深く探る前に、ArbitrumがEVMとWASMの共存をどのように調整しているかを理解することが重要である。これは単に二つの独立したエンジンを持つだけでなく、双方の強みを高める相乗関係なのだ。

Arbitrumの独自アーキテクチャにより、統一された状態、VM間呼び出し、互換性のある経済モデルのおかげで、EVMとWASMの間でシームレスかつ同期した操作が可能になる。

Solidityやその他のEVM言語で書かれたスマートコントラクトは、通常通りEVMバイトコードにコンパイルされる。実行時には、これらは今日と同じようにEVM上で動作する。

WASMにコンパイル可能な言語（Rust、C++、Cなど）の場合、ワークフローは以下の通り：

開発者はClangやRustcなどの既存のWASMコンパイラを使って、スマートコントラクトをWASMにコンパイルする。
WASMバイトコードは圧縮形式でArbitrumチェーンにアップロードされる。
コントラクト所有者は`ArbWasm`プリコンパイルの`compileProgram`メソッドを呼び出し、WASMに対してセキュリティチェックを行い、ガスコストを計測し、バリデータのハードウェアに最適化されたネイティブコードにコンパイルする。
コントラクトが呼び出されると、WasmerのようなWASMランタイム上で実行され、EVMよりもはるかに高速に動作し、ガス代を節約する。

WASMのガス計測は、EVMのようにオペコードごとに課金するのではなく、各基本ブロックの前でガスを徴収する。これにより、より効率的になり、コントラクトが暴走しないことが保証される。

EVM vs WASM

二つの仮想マシン（VM）は同期して動作し、同じグローバル状態にアクセスしながら互いに呼び出すことができる。あるトランザクションの一部がEVMで実行され、別の部分がWASMで実行され、結果がシームレスに統合される。

待てよ、二つのVMはどうやってシームレスかつ同期的に動けるのか？

PolkadotはXVMによってこれを実現している。Polkadotとは異なり、WASMとEVMは以下の重要な理由により、Arbitrum上でシームレスかつ同期的に動作できる：

単一の状態：両VMは同じ基盤となるデータ構造とステートトライにアクセスする。一方のVM内のコントラクトは、他方のVM内のコントラクトと同じ位置に読み書きできる。これにより、チェーン状態に対する統一されたビューが得られる。
VM間呼び出し：EVMコントラクトとやり取りするトランザクションはGethが処理し、結果を提供する。その後EVMコントラクトがWASMプログラムを呼び出す場合、WASM VMがその部分の計算を引き継ぐ。
共有コンテキスト：ブロックデータ、送信者アドレスなどのシステム情報は両VMで利用可能。WASMコントラクトもSolidityコントラクトと同様にブロック番号を取得できる。
単一共有：バリデータは両VMを実行してトランザクションを検証し、正しいチェーン状態について合意する。紛争時には統一された詐欺証明システムが呼び出される。
互換性のある経済モデル：ガス計測のような概念が両VMに拡張され、いずれの環境でも適切な計算コストとリソース管理が保証される。

詐欺証明については、バリデータがEVMとWASMの実行を細分化（bisect）し、無効なステップを特定できるようにする。WASMの構造により、システムは終了を保証し、証明の正当性を強制できる。

ブロックチェーン | WASM

Arbitrum以外にも、WebAssembly（WASM）の変革的ポテンシャルを認識しているプラットフォームは多い。PolkadotやCosmosもそれぞれWASMをエコシステムに統合しており、独自の優位性と機能を持っている。

PolkadotはWASMでスマートコントラクトを開発でき、二つの言語をサポートしている：埋め込みDSLのAssemblyScriptとRust風のInk!。

一方、CosmosはCosmWasmをスマートコントラクトランタイムとして使用し、開発者がRustでコントラクトを書けるようにしている。

ブロックチェーン業界がなぜWASMをこれほど受け入れているかを掘り下げる前に、CosmosとPolkadotが特に強調する利点を見てみよう：

Cosmosが強調するWASMの利点：

Rustライブラリとの互換性
多様な開発者コミュニティ
再入攻撃防止など、強化されたセキュリティ
テストの容易さ
高性能

PolkadotのWASMランタイムの特徴：

高性能
EVMとの相互運用性
プラットフォーム非依存性
コンパクトなバイナリサイズ
RustとAssemblyScript（TypeScript風）の同時サポート

Polkadot、Cosmos、ArbitrumはWASMが提供するいくつかの共通の利点を共有しているが、それぞれ独自の特性も持っている。

主要なブロックチェーンプラットフォームがWASMを広く採用していることは、業界内での重要性が高まっていることを示しており、なぜこの技術が現代のブロックチェーンアーキテクチャの基盤となりつつあるかを理解することが極めて重要である。

なぜWASMなのか

WASMとは何か

ブロックチェーンとWebAssembly（WASM）の相乗効果を理解するには、まずWASMとは何か、そしてその発展の背後にある原動力について理解する必要がある。

WebAssemblyは、コードをWebブラウザ内でほぼネイティブ速度で実行できるバイナリ命令フォーマットである。CやRustなど複数のプログラミング言語のコンパイルターゲットとして設計され、高速・効率的・安全を目的としている。WASMはWebベースとシステムレベルのプログラミングのギャップを埋め、Webの性能と機能を高めた。

「Web」はJavaScript環境（通常ブラウザ内）での実行能力を強調している。このような環境では、開発者はWASM APIに完全にアクセスでき、包括的なWeb APIサポートにより、Webの挙動を高度に制御できる。

WASMの歴史

「一度書けばどこでも動く」という原則に従い、WASMは長年の課題に対する有力な解決策として登場した。2016年時点で、多くのプログラムはドメイン固有言語（DSL）を通じて新機能を導入していたが、これは保守性、効率性、セキュリティのトレードオフを伴っていた。これらの要素を犠牲にせず、多数のサーバーに新機能を提供するソリューションが求められていた。

既存のソリューションの不足が評価された：

- システム仮想マシン

起動・停止の頻発による過剰なオーバーヘッド
安全性確保のためのコード可視性の欠如
性能要件に対して抽象度が高すぎる

- コンテナ

安全性確保のためのコード可視性の欠如
高レベル抽象による非効率性
頻繁な操作による大きなオーバーヘッド

- 言語レベル仮想マシン

安全性確保のための頻繁な修正が必要
V8のような埋め込みVMはリソース集約的
新言語のセキュリティモデルへの適応が遅い
依然として抽象度が高すぎる

- 命令セットアーキテクチャ（ISA）

効果的なサンドボックス化が困難
Googleの過去のプロジェクトはこれからの転換を遂げた
成熟した実装の欠如

2018年までに、WASM開発はさまざまなアーキテクチャ、サーバー、組み込みハードウェアでの実行、さらには多言語サポートに注力して勢いを得た。Javaとは異なり、WASMは安全性を妥協せずに設計された。2019年には、WASMモジュールの相互運用性を高めるコンポーネントモデルが導入された。これにより、HTTPライブラリを一回書くだけで複数言語で使えるようになった。

今日、WASMは一連の機能を持ち、クラウドネイティブ（ブロックチェーン含む）のシーンでますます採用されている。主な利点は以下の通り：

高性能
コンパクトなバイナリサイズ
クロスプラットフォーム移植性
C/C++、Rust、AssemblyScriptなど多言語サポート
JavaScriptエンジン内での実行
メモリとCPU制限付きの強力なサンドボックス
極めて短い起動時間（通常ミリ秒以下）

WASMコミュニティは、言語横断的な統合とパフォーマンス向上に向けて引き続き努力している。

WASMの歴史的進化を理解することで、Stylusのようなブロックチェーンプロジェクトを含むさまざまな環境における現在および将来の役割を理解する貴重な背景が得られる。この背景により、WASMがブロックチェーンエコシステムに実装される際に生じる問題や懸念を、繊細な視点で探求できる。

Stylus Q&A

言語サポート

WASMの発展過程は、なぜStylusがArbitrumエコシステムにとって魅力的な追加機能であるかを明らかにする一方で、いくつかの制限や懸念も浮き彫りにする。その一つが言語サポートである。Stylusは確かにArbitrumの開発者層をC++やRustへと広げているが、JavaScriptやPythonといった人気言語の採用にはまだ届いていない。

PythonやJavaScriptをWASMに持ち込む初期プロジェクトは存在するが、ガベージコレクションやパフォーマンスの課題から、広範な採用にはまだ至っていない。

言語互換性

現在、StylusはC/C++およびRust SDKをサポートしており、これらの言語のツールチェーンとシームレスに統合できる。開発者はスマートコントラクト構築時にネイティブ暗号化実装などのサードパーティライブラリを統合することも可能だが、主な制限はそれに関連するガス費用である。

Rust SDKはまだ初期段階にあり、RustとCのSDKともに一部機能が欠けている。たとえば、C SDKはABIエクスポート関数をサポートしておらず、修飾子はどちらのSDKでも未サポートである。

現時点では、ネイティブのStylusテスト環境は存在せず、開発者はSDK内でのみテストを実行できる。スマートコントラクトのデプロイに関しては、テストネットのみが利用可能であり、コントラクトの検証はまだサポートされていない。現在、各種ERCトークンや **[Uniswap V2]** をStylusエコシステムに導入する取り組みが進行中である。

言語選択のジレンマ

ドメイン固有言語（DSL）、埋め込みDSL（eDSL）、汎用言語の間の選択は、低レベル制御と高レベル抽象の間のトレードオフを伴う。新しいDSLを開発するには、ツールチェーンとエコシステム開発への大きな投資が必要になる。一方、汎用言語のサブセットであるeDSLは、既存ツールとの統合が容易で学習曲線も緩やかだ。たとえば、JavaScriptやPythonのような人気言語内でeDSLを作成することは有益だろう。

汎用言語はSDKの使用を必要とし、余分なツールを導入し、冗長性を増し、コードの表現力を低下させる。また、長いAPI呼び出しやオブジェクト操作も伴う。

言語選択とeDSL開発の間で適切なバランスを見つけることは、より広範な開発者コミュニティを惹きつけ、ユーザーフレンドリーなツールを提供する鍵となる。現状のデータによれば、トップの暗号開発者コミュニティは依然としてイーサリアム周辺に集中している。しかし、Rustを用いたスマートコントラクトのプラットフォーム（Polkadot、Cosmos、Solanaなど）も注目を集め、開発者コミュニティで急速に成長している。

パフォーマンス

WASMは実行速度の大幅な向上とパッケージサイズの削減を実現している。Stylusはまだメインネットに展開されていないが、他のネットワークのベンチマークは有用な参考となる。実行時間は4～8倍速くなり、コンパイル後のサイズは約50％削減される。

Stylusは現在、コントラクトサイズに制限を設けており、非圧縮時で上限約128KBとなっている。この制限により、Solidityなどの他の言語から大型スマートコントラクトを移植することが難しくなる。Stylusのコードベースでは、この制限は以下のように記述されている：

なお、WASMは起動・停止時にいくらかのオーバーヘッドを生じる。軽量な操作では、EVMの方がむしろガス面でコスト効率が良い場合もある。

EVMとの相互運用性

EVMとWASMは同じストレージスロットとステートツリーを共有しており、これがStylusとEVMの相互運用性を助けている。これはWASM内でEVM APIを実装することで達成されており、一般的なHost I/Oパターンを使用している。サポートされるEVM APIの完全なリストは、相互運用性が十分にサポートされていることを示している。