Arbitrum Stylus:スマートコントラクトのコンポーザビリティの新基準

紹介

Etherscanでのバイトコードとの格闘から、Solidityでのあらゆる種類のコードエクスプロイトに対する保護まで、ブロックチェーン開発のEVM技術スタックは、多くの開発者にとってWeb2技術スタックのそれとは大きく異なるため、Solidity-EVM技術スタックとRust、C++、Pythonなどの主流言語との間に「ギャップ」が生じています。 ブロックチェーン空間が成熟し続ける中、この開発者のギャップを埋め、より構成可能なWeb3開発を可能にすることが大きなニーズとなっています。

本記事では、Stanford Blockchain WeekのBlockchain Applications Stanford Summit(BASS)カンファレンスで発表されたOffchain Labsの最新プロジェクト「Arbitrum Stylus」について紹介します。 Arbitrum Stylusは、EVMの実行環境をWASMの実行環境と統一することで、スマートコントラクトのコンポーザビリティの新しい標準を作成することを目的とした画期的なプロジェクトです。 まず、このプロジェクトの背後にあるいくつかの動機について説明し、その後、プロジェクトの実装の詳細を掘り下げ、最後にWeb3空間におけるプロジェクトの影響について説明します。

Arbitrum Stylusの動機

Arbitrum Stylusは、ブロックチェーン開発における2つの重要な問題、すなわち(1)ブロックチェーン開発のアクセシビリティ、および(2)スマートコントラクトの実行効率に対処するために開発されました。

ブロックチェーン開発をより身近なものにする

Electric Capitalによる開発者レポート。 画像は出典 [1] より。 2023年10月20日閲覧。

Electric Capitalの開発者レポートによると、現在、毎月約20,000人のアクティブなブロックチェーン開発者がいます[1]。 この数はここ数年で大幅に増加していますが、RustやC++などの汎用言語を主流にしている数百万人(または数千万人)の開発者にはまだ桁違いに遅れをとっています。 ブロックチェーン分野が成長し続けるにつれて、何百万人もの新しいスマートコントラクト開発者をオンボーディングするためのプロセスを合理化する必要性が高まっています。

そのための最良の方法の1つは、スマートコントラクトの開発プロセスをRustやC++などの既存の主流言語と統合することです。 これは、SolanaやCosmosなど、EVM以外の多くのエコシステムが採用しているアプローチであり、Rustはこれらのエコシステムにおける事実上のスマートコントラクト言語として浮上しています。 しかし、EVMエコシステムは、これまで、主に独自のプログラミング言語であるSolidityに依存してスマートコントラクトを作成していました。 しかし、Arbitrum Stylusは、ブロックチェーン開発者がRustなどの主流言語でスマートコントラクトを作成し、EVM互換チェーンにデプロイできるようにすることで、この状況を変えようとしています。

スマートコントラクトの実行をより効率的にする

ここ数年、分散型アプリケーションの人気が爆発的に高まるにつれ、特にイーサリアムネットワークでは、オンチェーン計算の需要が劇的に高まっています。 このネットワーク需要の急増により、ガス価格が高騰しています。 これにより、パブリックブロックチェーンのトランザクションスループットを向上させるイノベーションが次々と発生し、Arbitrumはこの分野で最も著名なプロジェクトおよびエコシステムの1つです。 これには、フラッグシップの Arbitrum One L2チェーンと Arbitrum Nitro 技術スタックが含まれます。

Arbitrum Stylusは、これらすべての自然な拡張であり、Arbitrumのツールキットの最新ソリューションです。 トランザクションのトランザクション間効率の最適化 (ロールアップによるトランザクションのバッチ処理など) に重点を置いた以前のソリューションと比較して、Stylus はトランザクション内レベル、特に各トランザクションの実行方法の最適化に重点を置いています。 WebAssembly(WASM)でコントラクトを実行できることで、Stylusコントラクトは桁違いに高速になり、ガス料金の低減が約束され、EVMを使用するよりも最大100〜500倍安価なメモリにアクセスできます[2]。

スタイラス:WASM + EVMのコンポーザビリティを提供

WebAssembly と Arbitrum Nitro

Stylus が従来の EVM エンジンよりもはるかに効率的でコンポーザブルである理由を理解するには、まず WebAssembly (WASM) の役割を理解する必要があります。 WASMはアセンブリ言語の一種であり、RustやC++などの人間が読める言語ではなく、基本的に機械可読のバイナリコードです。 代わりに、これらの人間が読める言語は、実行前に機械可読の「アセンブリ言語」に変換するための「コンパイラ」を必要とします。

特にWASMは、その名前が示すように、主にJavascriptベースのWebアプリケーションの実行速度を向上させるために、Webブラウザ用に最適化されたアセンブリ言語です。 WASMは、移植性があり、モジュール化され、簡単に実行可能なアセンブリ言語であるため、開発者はRustやC++などのさまざまな主流言語でコードスニペットを直接記述できます[3]。

ArbitrumのNitroアップグレードでは、オンチェーンのすべての紛争がWASMで行われるため、Nitroは任意のWASMに対して機能する不正システムを持っていることになります[2]。また、Arbitrum NitroはあらゆるWASMコードに対して不正の証拠を提供できるため、WASMにコンパイルされるすべてのプログラムに対して不正の証拠を提供できることを意味します。

Arbitrum Stylusは、Arbitrum Nitroから継承された既存のWASM不正防止エンジンの上にWASM実行エンジンを追加し、 Wasmerと呼ばれる主要なWASMエンジンの1つに基づいており、GethがEVMバイトコードを実行するよりもはるかに高速にコードを実行します[2]。 実行エンジンとプルーフエンジンの両方により、スマートコントラクトを完全にWASMで記述、実行、証明することができます。 RustやC++などの多くの主流言語がWASMに直接コンパイルできることを考えると、Arbitrum Stylusを使用すると、ブロックチェーン開発者はさまざまな主流の汎用言語でスマートコントラクトを作成、デプロイ、実行できます。

評価基板 (EVM) と Stylus の評価基板 (EVM+) の比較 画像は出典[2]より。

EVM+エンジンのコヒーレンス

Arbitrum Stylusは、Solidityでスマートコントラクトを記述して実行する能力を犠牲にすることなく、Rustやその他のWASM互換言語でコントラクトを書くための追加オプションを開発者に提供します。 Stylusは、EVMとWASMという2つの同等の実行エンジンを持つことで、アプリケーションの一部をSolidityで記述し、別の部分をRustで記述するオプションを開発者に提供する。

しかし、ここで疑問が湧いてきます:Stylus VM は 2 つの異なるエンジン間の一貫性をどのように管理するのでしょうか? EVMとWASM VMを切り替えるタイミングはどのようにして判断されるのでしょうか?

まず、Solidityとその他のEVMベースのコントラクトを同じバイトコードにコンパイルし、純粋なEVMエンジンで通常行うように実行します。 例えば、Rustで書かれたようなWASMベースのスマートコントラクトは、コントラクトの冒頭に追加の「ヘッダー」で注釈が付けられます。 したがって、これらのコントラクトが呼び出されると、Stylus VM は、どのコントラクトに EVM エンジンが必要で、どのコントラクトに WASM エンジンが必要かを判断できます。 また、この設計では、WASMで記述されたコントラクトがSolidityで記述されたコントラクトを呼び出すことができ、その逆も可能になるという、高度な相互運用性も考慮されています。 これは、StylusがWASM実行エンジンを採用した他のブロックチェーンと異なる主な点でもあります:Stylusは、WASMコントラクトが完全にコンポーザブルであり、EVMコントラクトと相互運用可能であることを保証し、下位互換性とWASMコントラクトがEVMの流動性を利用することを可能にします。

StylusのEVMとWASMのデュアルエンジンを見るもう一つの視点は、ブロックチェーンをEVMで定義された特定のステートトランザクションを受ける「ワールドステートマシン」と見なすことです。 イーサリアムでは、オンチェーンの状態は、データを効率的に保存および取得するために使用されるTrie構造、またはツリー状のデータ構造によって表されます[4]。 Stylus の EVM エンジンと WASM エンジンは、どちらも同じトライ構造を使用して、「ワールド ステート マシン」との間でデータの読み取りと書き込みを行います。 どちらのエンジンも、ワールド ステートを更新するために、特定のステート変更を生成します。唯一の違いは、この状態変化の計算方法です。

EVM+ エンジンのコスト削減

以前、WASMエンジンを使用すると、実行効率が向上するため、大幅なコスト削減が可能になることをすでに示唆しました。 ここで、これがどのように達成されるかを調べることができます。 そのために、1 つの ADD 命令、たとえば 2 + 3 について考えてみましょう。

この評価基板 (EVM) では、以下のステップを実行する必要があります [5]。

1. ガス代を支払い、メモリ内テーブルを複数回検索する必要がある
2. 無効になっている場合でもトレースを検討する
3. シミュレートされたスタックの 2 つの項目をポップします
4. それらを一緒に追加します
5. 結果をプッシュする

ステップ4だけがこれら2つの整数を加算するものであり、他のすべてのステップはEVMシステム内の「定型命令」であり、計算自体に比べて法外な量のガスがかかることがわかります。

一方、この単純な ADD 操作に WASM を使用したとします。 必要なステップは 1 つだけです。

1. x86 または ARM ADD 命令を 1 つ実行する

EVM ADDとWASM ADDの比較 画像は出典 [7] より。

これは、EVMアドオンよりも150倍安いことがわかります。 これらすべてのガス節約を考慮して、Stylus VMは「インク」と呼ばれる新しい「ガス」サブユニットを導入し、現在デフォルトで1ガスの1/10000と定義されており、チェーンの所有者によって設定することもできます[5]。

ただし、これらすべてのガス節約には1つの注意点があり、それは、現在1億1,400万ガスの固定レートに設定されているStylus VMを最初に起動するためにガスが必要であるということです。 さらに、スタイラスプログラム自体を呼び出すには、現在約128〜2048ガスが必要です[5]。 したがって、2 つの整数に対する 1 つの ADD 操作を最適化するためだけに WASM 環境を活動化することは、必ずしも経済的に意味をなさない場合があります。 しかし、メモリを大量に消費するスマートコントラクトの場合、これらの節約はすべて複合的に行われ、この「アクティベーションコスト」を相殺します。 たとえば、EVM で 3.8 MB の RAM を割り当てる呼び出しには ~3,200 万ガスのコストがかかりますが、Stylus WASM VM では ~64,000 ガスしかかからず、500 倍の節約になります [6]。 当然の帰結として、メモリを大量に消費するアプリケーションは、バニラEVMでは、あらゆる種類のガス制限にすぐにぶつかるため、不可能です。 ただし、WASMランタイムを使用するとRAMが桁違いに安価になることを考えると、これはStylus VMで完全に可能になります。

スタイラスで新しいユースケースを解き放つ

1. メモリを大量に消費するアプリケーション

前述したように、Arbitrum Stylusの最もエキサイティングな部分の1つは、メモリを大量に消費するアプリケーションをオンチェーンで実現できることです。 これにより、ジェネレーティブAI NFT、高頻度取引、オンチェーンゲームなど、まったく新しいクラスのアプリケーションが解き放たれます[7]。 実際、Stylus VMは、高いメモリ需要で悪名高いAIをオンチェーンで計算可能にし、EVMコントラクトと完全に相互運用できるようにする画期的な技術かもしれません。

2. EVM流動性によるAlt-VMのコンポーザビリティ

さらに、StylusのEVM互換性と、WASMベースのコントラクトをネイティブのSolidityコントラクトと相互運用できる能力は、これらのWASMコントラクトがEVMの大規模な流動性とユーザーベースを十分に活用できることを意味します。 SolanaやCosmosなどの多くの代替VMは、RustなどのWASM互換言語を使用してスマートコントラクトを実行していることを以前に述べたことを思い出してください。 StylusのWASMエンジンは、これらの代替VMの開発者が契約をEVMエコシステムに簡単に移植し、EVMの流動性をすぐに活用できることを意味します。

3. 汎用ライブラリ、プリコンパイル、およびデバッグ インフラストラクチャ

開発者がRustやC++などの主流言語を使用してスマートコントラクトを作成できるようにするStylusのもう一つの利点は、開発者がオンチェーン計算から暗号化プリミティブ、ファイルI/Oまですべてを含むこれらの主流言語をサポートする膨大な量の汎用ライブラリを利用できることです。

さらに重要なことは、開発者は、これらの主流言語用に構築された高度なツールインフラストラクチャの恩恵を受けることができることです。 これには、高度なパッケージ マネージャーだけでなく、C/C++ の GDB ツールキットなどの使い慣れたデバッグ インフラストラクチャも含まれます。 これらすべてにより、web3の開発の親しみやすさが大幅に向上し、ブロックチェーン開発とEVMスタックへのオンボーディングプロセスが大幅に簡素化される可能性があります。

4. DePINのためのオンチェーン計算をIoTに導入

WASMの実行効率の向上により、Stylus VMは、信号機からスマート冷蔵庫、スマートウォッチまで、あらゆるものを含むモノのインターネット(IoT)のポータブルデバイスとオンチェーン計算を統合するための扉を開く可能性があります。 WASMはもともとブラウザ環境を対象としていましたが、その移植性のあるモジュール式アーキテクチャと効率的な実行により、小型で効率的なランタイムを必要とするIoTデバイスに最適です[8]。

したがって、Arbitrum StylusのWASM VMは、WiFiシステムから太陽光発電バッテリーまで、物理インフラストラクチャを維持するためにブロックチェーンネットワークと新しいトークンインセンティブを使用しようとする分散型物理インフラストラクチャネットワーク(DePIN)の成長トレンドに自然に適合します[9]。 DePINの多くはブロックチェーンスタックとIoTデバイスの統合に依存しているため、Arbitrum Stylusは、これらのデバイスがWASMベースの計算を効率的に実行し、Arbitrumエコシステムを通じてEVM流動性を活用できるようにするための重要なゲートウェイとして機能する可能性があります[10]。

結論

この記事では、Arbitrumの動機、実装、影響について詳しく説明してきました。 スタイラス。 Stylusは、開発者がさまざまな主流言語でスマートコントラクトを作成および展開できるようにすることで、ブロックチェーン開発をよりアクセスしやすく効率的にし、主流の構成可能性とEVMの流動性を組み合わせて、幅広い新しいアプリケーション、特にメモリを大量に消費するアプリケーションを解き放ちます。 このように、Stylusは、次世代のコンポーザブルスマートコントラクトを定義する上で間違いなく画期的なプロジェクトであり、Web2とWeb3の開発の境界を曖昧にして、より効率的で統合されたパフォーマンスの高いブロックチェーン開発スタックを作成できるプラットフォームになります。

免責事項：

1. この記事は[STANFORD BLOCKCHAIN CLUB]からの転載です。 すべての著作権は原作者[Rachel Bousfield;Jay Yu]に帰属します。 この転載に異議がある場合は、 Gate Learn チームに連絡していただければ、迅速に対応いたします。
2. 免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
3. 記事の他言語への翻訳は、Gate Learnチームによって行われます。 特に明記されていない限り、翻訳された記事を複製、配布、盗用することは禁止されています。