Aribitrum Stylus の詳細分析: これが今年のレイヤー 2 の最も重要な技術革新である理由は何ですか?

著者: Yiping、IOSG Ventures
この記事は IOSG のオリジナルのコンテンツであり、業界の学習と交流のみを目的としており、投資の参考となるものではありません。引用する必要がある場合は、出典を明記してください。転載については、IOSG チームに連絡して許可と転載の指示を取得してください。この記事で言及されているすべてのプロジェクトは、推奨または投資アドバイスを構成するものではありません。
zkSync や StarkNet などの ZKRU がメインネットを立ち上げるにつれて、レイヤー 2 の状況は急速に進化しています。従来、Arbitrum のような OPRU は最初に市場に投入されるため、より強力なエコシステムを備えています。対照的に、ZKRU は、より高いスループットとより低い料金を提供する画期的な技術です。
最近数ヶ月で、より多くの活動が Layer1 から Layer2 に移行し、より迅速で安価な取引を求めています。Ethereum の TVL はこの一年で約 400 億ドルから 200 億ドルに減少しました。しかし、Layer2 の TVL は異なる状況を示しており、大幅な成長が Layer2 の採用が加速していることを示しています。
Arbitrum は 50% 以上の Layer2 TVL 市場シェアを持ってリードしていますが、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 は、既存の Ethereum 仮想機（EVM）と並行して動作する WebAssembly（WASM）仮想機を追加することで機能します。WASM にコンパイル可能な言語で書かれたスマート契約は、Solidity よりも 10 倍以上の速度でネイティブに実行でき、ガス費用を大幅に削減します。EVM は引き続き完全な機能を持ち、既存の Solidity 契約は今日と同じように正常に動作します。二つの VM は同期して動作し、異なるプログラミング言語で書かれた契約が互いに呼び出すことを可能にし、同時に同じ基盤のブロックチェーン状態を変更することができます。
カスタム事前コンパイル
さらに、Stylus はカスタム事前コンパイル（Precompiles）もサポートしています。
事前コンパイルは、Ethereum と Arbitrum 上で特定の暗号または実用関数を非常に効率的に実行するための基盤モジュールです。例えば、ECDSA署名検証や SHA256ハッシュ計算のための事前コンパイルがあります。
新しい事前コンパイルを追加するには、すべてのバリデーターが EVM のアップグレードを調整する必要があり、ハードルは非常に高いです。ただし、Stylus を使用することで、開発者は Rust または C++ で書かれた独自の事前コンパイルを簡単にデプロイできます。
例えば、あるチームは C 言語で書かれた暗号ライブラリを使用し、変更を加えることなく Arbitrum にデプロイできます。これにより、これらの暗号原語は超高速のネイティブ速度で実行されることが可能になります。
他の契約は、この Stylus の「事前コンパイル」を呼び出すことができ、ネイティブな事前コンパイルを呼び出すのと同様に、この暗号技術を利用できます。すべてのガス計量と詐欺証明は自動的に機能します。
これにより、チームは特別なチェーンサポートなしでカスタム暗号、特別なペアリングベースの曲線、および他の新しい原語のプロトタイプを作成できます。Ethereum の研究者は、Arbitrum 上に Stylus 事前コンパイルの形でそれらをデプロイすることで、EIP 提案を事前に反復することさえできます。
開発者にチェーン上で新しい暗号原語をネイティブに導入する能力を与えることで、Stylus は構築できるコンテンツの範囲を大幅に広げました。事前コンパイルはもはや EVM によってサポートされる機能に限定されません。
Stylus の仕組み
WASM がブロックチェーン宇宙におけるより広範な役割を深く探求する前に、Arbitrum が EVM と WASM の共存をどのように調整しているかを理解することが重要です。これは単に二つの独立したエンジンを持つことではなく、両者の利点を強化する協力関係です。
Arbitrum の独自のアーキテクチャにより、EVM と WASM の間でシームレスかつ同期的な操作が可能となります。これは、統一された状態、VMを越えた呼び出し、および互換性のある経済モデルのおかげです。
Solidity や他の EVM 言語で書かれたスマート契約は、従来通り EVM バイトコードにコンパイルされます。実行時、これらの契約は EVM 上で動作し、今日と同じように動作します。
WASM にコンパイルされた言語、たとえば Rust、C++、C のワークフローは次のようになります：
開発者は、Clang や Rustc などの既成の WASM コンパイラを使用して、スマート契約を WASM にコンパイルします。
WASM バイトコードは圧縮形式で Arbitrum チェーンにアップロードされます。
契約の所有者は、`ArbWasm` 事前コンパイルの `compileProgram` メソッドを呼び出し、WASM のための安全なツールを設定し、ガスコストを計量し、検証者ハードウェアに最適化されたネイティブコードにコンパイルします。
契約が呼び出されると、それは Wasmer のような WASM ランタイム上で実行され、EVM よりもはるかに高速で、ガス費用を節約します。
WASM 計量は各基本ブロックの前にガスを請求し、EVM のようにオペコードごとに請求するのではありません。これにより、効率的で、契約が制御不能になることを防ぎます。
EVM と 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 の実行を二分し、必要に応じて無効なステップを特定します。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」は、WebAssembly において、JavaScript 環境（通常はブラウザ内）で実行される能力を強調しています。これらの設定では、開発者は完全に WASM API にアクセスでき、包括的な Web API サポートを得て、Web の動作を大きく制御できる能力を持ちます。
WASM の歴史
「一度書いてどこでも実行」の原則に従い、WASM は長期的な課題に対する強力なソリューションとして登場しました。2016年までに、多くのプログラムがドメイン固有言語（DSL）を通じて新機能を導入し、通常は保守性、効率性、安全性の間でトレードオフが行われました。これらの側面を損なうことなく無数のサーバーに新機能を提供するソリューションの需要が高まっています。
さまざまな既存のソリューションの不足を評価しました：
- システム仮想機
頻繁な起動と停止は過剰なオーバーヘッドを引き起こします
セキュリティを確保するためのコードの可視性が不足しています
性能要求が過度に抽象的
- コンテナ
セキュリティを確保するためのコードの可視性が不足しています
高レベルの抽象化による効率の低下
頻繁な操作により著しいオーバーヘッドが発生します
- 言語レベルの仮想機
セキュリティを確保するために頻繁に修正が必要
V8 などの埋め込み VM はリソース集約型です
新しい言語に対するセキュリティモデルへの適応が遅い
依然として過度に抽象的
- 命令セットアーキテクチャ（ISA）
効果的なサンドボックス化が難しい
以前の Google プロジェクトが WASM に移行した
成熟した実装の欠如
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 は、C++ や Rust のような言語を含む Arbitrum 開発者コミュニティを拡大しましたが、JavaScript や Python のような人気のある言語の受け入れには不十分です。
Python や JavaScript を WASM に持ち込むことを目指した初期プロジェクトがありましたが、ガベージコレクションや性能問題の課題により、これらの努力は広く採用される準備が整っていません。
言語の互換性
現在、Stylus は C/C++ と Rust SDK をサポートしており、これらの言語のツールチェーンとシームレスに統合されています。開発者は、ネイティブな暗号実装のようなサードパーティライブラリをスマート契約を構築する際に統合することもできます。このようなことを行う際の主な制限は、関連するガス費用です。
Rust SDK はまだ初期段階にありますが、Rust と C SDK にはいくつかの欠けた機能があります。例えば、C SDK は ABI エクスポート関数をサポートしておらず、修飾子は両方の SDK でまだサポートされていません。
現在、ネイティブな Stylus テスト環境はありませんが、開発者は SDK 内で直接テストを実行できます。スマート契約をデプロイするには、現在のところテストネットのみが唯一の選択肢であり、スマート契約の検証もサポートされていません。さまざまな ERC トークンと **[Uniswap V2](https://twitter.com/evmcheb/status/1697537852522049990)** を Stylus エコシステムに導入するための努力が進行中です。
言語選択のジレンマ
ドメイン固有言語（DSL）、埋め込み DSL（eDSL）、および一般的な言語の間で選択することは、低レベルの制御と高レベルの抽象化の間でトレードオフを必要とします。全く新しい DSL を開発するには、ツールチェーンとエコシステムの開発に多大な投資が必要です。それとは対照的に、一般的な言語のサブセットとしての eDSL は、既存のツールとの統合を容易にし、学習曲線も低くなります。例えば、JavaScript や Python のような人気のある言語で eDSL を作成することは有益です。
一般的な言語を使用するには SDK が必要で、これにより追加のツールが導入され、冗長性が増し、コードの表現性が低下し、より長い API 呼び出しやオブジェクト操作が伴います。
言語選択と eDSL 開発の間の適切なバランスを見つけることは、より広範な開発者コミュニティを引き付ける鍵かもしれませんが、同時にユーザーフレンドリーなツールを提供します。現在のデータによると、トップクラスの暗号開発者コミュニティは依然として Ethereum の周りに集中しています。しかし、Rust を使用したスマート契約のプラットフォーム、Polkadot、Cosmos、Solana も注目を集めており、彼らの開発者コミュニティは急成長しています。
性能
WASM は実行速度を大幅に向上させ、パッケージサイズを縮小します。Stylus はまだメインネットにデプロイされていませんが、他のネットワークのベンチマークは有用な参考になります。観察された実行時間は4-8倍速く、コンパイル後のサイズは約50%縮小しました。
Stylus は現在、その契約にサイズ制限を設けており、未圧縮時の上限は約128KBです。この制限により、他の言語（Solidityなど）から大規模なスマート契約を移植することが困難になります。Stylus コードベースでのこの制限は以下の通りです：
WASM は起動と停止の際にいくつかのオーバーヘッドを生じることに注意が必要です。軽量な操作の場合、EVM は実際には WASM よりもコスト効果が高い可能性があります。
EVM との相互運用性
EVM と WASM は同じストレージスロットと状態ツリーを共有しており、これにより Stylus と EVM の相互運用性が促進されます。これは、WASM で実装された EVM API によって実現され、一般的なホスト I/O モデルを使用しています。サポートされている EVM API の包括的なリストは、相互運用性が完全にサポートされていることを示しています。
カスタム事前コンパイル契約
この側面は特に興奮をもたらすもので、未知の領域を代表しています。カスタム事前コンパイル契約は、より低い実行コストで追加の暗号原語をオンチェーンに導入する可能性があります。また、推論コストを削減するために、テンソル計算を事前コンパイル契約として導入することもできます。しかし、現在のところ、カスタム事前コンパイル契約に関連する既存のコードは存在していないようです。EVM コンポーネントには事前コンパイル契約がありますが、これらはホットスワップ可能ではありません。
この機能は、WASM の能力を活用してまだ開発中である可能性があります。EVM は WASM で書かれた関数を呼び出し、それをマシンコードにコンパイルできます。
再入機能
CosmWasm（再入機能のないアクターモデルを採用）とは対照的に、Stylus の Rust SDK はデフォルトで再入機能をオフにしており、開発者は手動でこの機能を有効にするオプションを持っています。
再入機能を有効にするには、いくつかの API 調整が必要です。特に、呼び出しプロセス中にストレージキャッシュを更新するなどの安全対策において、開発者は慎重になる必要があります。
洞察
Stylus は、高性能な暗号、ゲーム、AI など、EVM のみを使用する場合にはガスが過剰に消費される新しいユースケースを開放しました。また、開発者が自分の暗号やその他の基本機能を追加できるカスタム事前コンパイル契約も許可し、アップグレードを待つ必要がありません。過去には、Cosmos や Polkadot のような非 Ethereum エコシステムが WASM を採用しました。これは、Ethereum コミュニティによる WASM の初めての採用です。全体として、Stylus はスマート契約開発の重要な進化を表しており、Ethereum と Arbitrum のスケーラビリティを実現しつつ、すべての既存アプリケーションとの相互運用性を維持するのに役立ちます。
Stylus を Arbitrum の Layer2 SDK に統合することで、第三層の開発者により大きな柔軟性が提供されます。彼らは現在、以前はガス制限を超えていた集中的な計算をチェーン上に移動でき、新たな可能性を開くことができます。開発者はもはや Solidity の使用に制限されず、Rust や C++ が彼らのニーズや専門知識により適している場合は、これらの言語を選択することができます。カスタム事前コンパイル契約は、最適なパフォーマンスを得るために、好ましい暗号、ユーティリティ、その他のアシスタント関数をシームレスにチェーンに移行することを許可します。各ユースケースに適した言語で低レベルのロジックを直接書くことで、よりスムーズな開発が可能になります。開発者はガスコストを回避するための妥協をすることなく、コア製品機能に集中できます。言語とガスの制限を取り除くことで、Stylus は第三層の構築者が最初から彼らの分野に適した正しいツールを使用して、最高のユーザー体験を構築できるようにします。
Stylus は、Arbitrum が大規模な革新を行う能力を持つことを証明し、新しい仮想機を統合しています。Ed Felten、Arbitrum & Offchain Labs の共同創設者兼最高科学者は、Arbitrum が業界で人気のあるツールやプログラミング言語に基づいて開発されていることを示しました。彼らはより迅速にテストを作成し、従来のシステムの上に新機能を開発することができます。OP は ZK 化の道を進み、徐々にハイブリッドロールアップの考え方に移行しています。Optimism は現在、Risc0 と提携し、Zeth を使用して OPRU にゼロ知識証明を生成しています。このソリューションを使用することで、Optimism は OPRU に特別な変更を加える必要はありません。Zeth に興味がある場合は、私が以前書いた[ツイート](https://x.com/glazecl/status/1709947992168710174?s=20)をご覧ください。
私たちは Arbitrum 上での AI アプリケーションの登場を非常に楽しみにしています。現在、オンチェーンでの機械学習は非常にガスを消費し、開発コストが高くなっています。ゼロ知識 ML はコストを削減できますが、開発者にとっては追加の複雑さをもたらします。Stylus を通じてテンソル操作をカスタム事前コンパイル契約として実現し、僅かなコストでネイティブにそれらを実行できれば、オンチェーンでの高性能な機械学習の新たな可能性が開けるでしょう。開発者が慣れ親しんだ言語（Python など）を使って迅速に ML アルゴリズムを構築・デプロイできるようにすることで、Arbitrum は DeFi、GameFi などの分野における次世代の AI イノベーションを推進することができます。Stylus のパフォーマンスと柔軟性は、私たちがガスの最適化ではなく、革新的な ML アーキテクチャに集中できるようにします。私たちはコミュニティの創造性がこの新興パラダイムに適用されるのを楽しみにしています。