Arbitrum の最近のアップデートには Stylus VM のアップグレードが含まれており、いくつかの機能強化が行われています。 拡張された言語サポート コストとメモリ使用量の削減 カスタマイズ可能なプリコンパイラ EVMの互換性 これらの改善は、クラウドネイティブ環境内での数多くの利点で知られる WASM の統合から生まれました。 WASM の役割の詳細については、後続のセクションで説明します。 パイオニア Arbitrum は WASM をチェーンに導入しましたが、これが最初のプラットフォームではありません。 Polkadot では以前、WASM スマート コントラクトの作成が許可されていました。このために 2 つの言語が提供されています。埋め込み DSL に似たアセンブリ スクリプトと、Ink と呼ばれる Rust からインスピレーションを得た言語です。 同様に、Cosmos はスマート コントラクトの実行に CosmWasm を利用しています。開発者はここで Rust を使用してスマート コントラクトを作成できます。 ブロックチェーンと WASM の親和性を探る前に、Cosmos と Polkadot が WASM を選択した根拠を確認してみましょう。 Cosmos は、WASM の次の利点を宣伝しています。 Rustライブラリの互換性 幅広い開発者コミュニティ リエントラント攻撃の防止など、セキュリティの強化 簡素化されたテスト手順 優れた性能 Polkadot の WASM ランタイムは次のような機能を紹介します。 卓越したパフォーマンス EVMの相互運用性 ハードウェアおよびソフトウェア プラットフォームの独立性 コンパクトサイズ Rust と Typescript に似たアセンブリ スクリプトのサポート Polkadot、Cosmos、および Arbitrum は、WASM によってもたらされるいくつかの利点を共有しています。ただし、Arbitrum には、Cosmos の詳細とともに、後で説明する独特のサービスがあります。 WASM WASM とは何か、そしてその背後にある動機について詳しく見てみましょう。 WASMとは何ですか? WebAssembly (WASM) はバイナリ命令形式です。これにより、特に Web ブラウザ内で、ネイティブ アプリケーションと同等の速度でコードを実行できるようになります。 C や Rust などの言語のコンパイル ターゲットとして、速度、効率、セキュリティが最適化されています。 WASM は Web パフォーマンスを大幅に向上させ、Web 機能を拡張します。 WASM はブラウザなどの JavaScript 環境内で動作するため、Web と密接に結びついています。これらの環境内では、開発者は WASM API に完全にアクセスできるだけでなく、完全な Web API サポートも利用できます。このコントロールにより、開発者は Web インタラクションを微調整できます。 WASMの進化 WASM の概念は、コードを一度作成すればどこでも実行できるという理想を中心に展開しています。 2016 年、プログラムはドメイン固有言語 (DSL) を介して新機能を頻繁に導入しました。 DSL の作成には、メンテナンス、効率、安全性のバランスが関係します。業界は、これらの側面を妥協することなく、多数のサーバーに機能を展開する方法を模索していました。 さまざまなソリューションが精査されましたが、それぞれに独自の課題がありました。 、オーバーヘッド、安全性のためのコードの可視性の欠如、および高いパフォーマンスを実現するには抽象的すぎるという問題に悩まされていました。 システム仮想マシンは もコードの可視性を欠いており、同様に抽象的であり、大幅なオーバーヘッドがありました。 コンテナ 安全性を確保するために頻繁な変更を必要とし、V8 などの組み込み VM によるオーバーヘッドが発生し、セキュリティ モデルに適合する新しい言語の導入が遅かったです。 言語レベルの仮想マシンは、 効率的なサンドボックス化のために変更するのが難しく、成熟した実装が不足していました。 命令セット アーキテクチャ (ISA) は、 WASM がソリューションとして登場しました。 WASM コンパイラーの開発が始まり、2018 年までに、さまざまなアーキテクチャーやデバイスにわたるユニバーサル コード互換性の概念が拡張されました。 Java とは異なり、安全性を犠牲にすることが目標ではありませんでした。 2019 年にコンポーネント モデルが導入され、WASM モジュールの言語間の相互運用性が向上しました。この革新により、たとえば、さまざまな言語に適用可能なユニバーサル HTTP ライブラリの作成が可能になり、複雑な問題に革新的に対処できました。 今日のWASM WASM は、次のような優れた機能を数多く備えています。 : WASM コードは効率的かつ迅速に実行されます。 ハイパフォーマンス : WASM のバイナリ形式により、設置面積が小さくなります。 コンパクトなサイズ : 同じバイトコードをあらゆる WASM 互換ランタイムで動作させることができます。 移植性 : WASM は、C/C++ や Rust から Go や Swift まで、幅広い言語をサポートしています。 言語サポート : WASM は JS エンジン内でシームレスに動作します。 JavaScript エンジンの互換性 : 堅牢なデフォルトのサンドボックスは、外部干渉を防ぐためにメモリと CPU へのアクセスを制限します。 サンドボックス : WASM モジュールは通常、ミリ秒以内に起動します。 高速スタートアップ WASM コミュニティは、さまざまなプログラミング言語間の統合とパフォーマンスを積極的に強化しています。 スタイラス WASM の可能性とブロックチェーンでのその使用を探ると、Arbitrum Stylus の限界に戻ります。 スタイラスの機能 Stylus の動作の簡単な内訳は次のとおりです。 開発者は、Clang や Rustc などの標準 WASM コンパイラーを使用して、スマート コントラクトを WASM にコンパイルします。 結果の WASM バイトコードは、圧縮された状態で Arbitrum チェーンにアップロードされます。 プリコンパイルの メソッドを通じて、バイトコードはセキュリティ、ガス計測のためのインストルメンテーションを受け、バリデーターのハードウェアに合わせて調整されたネイティブ コードにコンパイルされます。この手順は、パフォーマンスとセキュリティを強化するために重要です。 ArbWasm compileProgram 呼び出し時に、コントラクトは WASM ランタイム (Wasmer など) 上で実行されます。これは EVM よりも大幅に高速でガス効率が優れています。 追加のように見える 3 番目のステップは、実際には重要です。 WASM コードをネイティブ マシン コードに変換すると、実行速度が向上します。さらに、この追加されたコンパイル フェーズは、「コンパイル ボム」の防止に役立ちます。 「コンパイル 爆弾」は、コンパイル中にシステム リソースを使い果たし、コンパイラをクラッシュまたは停止させるように設計された悪意のあるコードです。これは、ソフトウェア開発プロセスを妨害することを目的としたサービス拒否攻撃として機能します。 スタイラスに関する懸念 言語サポート Stylus は、Arbitrum の開発者コミュニティを C++ や Rust を含むように拡大しました。ただし、今日最も普及している開発者コミュニティをまだ包含していません。ブラウザーでのスマート コントラクトの実行を容易にしますが、JavaScript と Python はまだサポートされていません。 Python と JavaScript を WASM に橋渡ししようとする初期段階のプロジェクトがあります。しかし、ガベージ コレクションやパフォーマンス上の懸念が複雑なため、これらは広く普及する準備ができていません。 言語の互換性 Stylus は現在、SDK を通じて C/C++ と Rust をサポートしています。これらの SDK は、それぞれの言語のツールと互換性があります。また、ネイティブ暗号化などのサードパーティ ライブラリの統合も可能になります。主な制約は、これらのライブラリに関連するガスコストです。 Rust SDK は初期段階にあり、いくつかの機能が欠けています。 C SDK は、ABI を使用したエクスポート機能をサポートしていません。さらに、どちらの SDK も修飾子の使用をサポートしていません。 現時点では、Stylus にはローカルのテスト環境がありません。開発者は、SDK 内でテストを実施することをお勧めします。テストネットは、Stylus でスマート コントラクトを実行するための唯一のオプションです。ただし、テストネットにはスマート コントラクトの検証がまだ実装されていません。 さまざまな ERC トークンや などのプラットフォームを Stylus に移植する作業が進行中です。 Uniswap V2 言語の選択 ドメイン固有言語 (DSL)、組み込み DSL (eDSL)、または一般的なプログラミング言語のいずれかを選択するのは困難です。開発者は、制御のために「金属に近い」作業を行う利点と、柔軟性が制限される可能性がある高レベルの抽象化によって提供される使いやすさを比較検討する必要があります。 新しい DSL を作成するには、そのツールチェーンとエコシステムを開発するのに時間がかかります。 eDSL は、一般的なプログラミング言語のサブセットとして、同じセマンティクスと構文を維持します。開発者は既存の言語とツールを使用できるため、学習プロセスが簡素化されます。 eDSL は、汎用コードとの相互運用性も向上します。たとえば、JavaScript または Python 用の eDSL は、最大の開発者コミュニティを参加させる戦略的手段となります。 一般的なプログラミング言語では、開発に SDK を使用する必要があります。これにより、ツールのレイヤーが追加され、冗長性が増し、表現力が低下します。また、API 呼び出しに時間がかかり、オブジェクトの操作が複雑になる可能性もあります。 適切な言語を選択して eDSL を作成することが、理想的な妥協策となる可能性があります。人気のコミュニティから開発者を集め、使いやすいツールを提供できる可能性がある。現在のデータは、イーサリアム コミュニティが依然として暗号通貨開発者の中で最大であることを示しています。ただし、スマート コントラクトに Rust を使用する Polkadot、Cosmos、Solana などのエコシステムも、かなりの数の開発者を惹きつけており、急速な成長を遂げています。 パフォーマンス WASM には、実行速度が大幅に向上し、バンドル サイズが削減される可能性があります。 Stylus はメインネットには導入されていませんが、他のネットワークのベンチマークは有用な参照として役立ちます。 これらのベンチマークは、実行時間が 4 ～ 8 分の 1 に短縮され、コンパイルされたサイズが半分になる可能性があることを示しています。 Stylus では、コントラクト サイズに制限があり、非圧縮で約 128 KB です。この制約により、非常に大規模なスマート コントラクトを Solidity などの言語から Stylus に移行することが困難になります。この制限は、Stylus コードベース内で明らかです。 // arbos/programs/programs.go const MaxWasmSize = 128 * 1024 // Maximum WASM size allowed const initialFreePages = 2 // Number of initial free pages const initialPageGas = 1000 // Gas cost for an initial page const initialPageRamp = 620674314 // Adjusts for a target size cost const initialPageLimit = 128 // Maximum number of pages allowed const initialInkPrice = 10000 // Ink price per EVM gas const initialCallScalar = 8 // Scalar for call cost WASM の起動とシャットダウンにはある程度のオーバーヘッドが発生することに注意することが重要です。非常に軽量な操作の場合、EVM は WASM よりもコスト効率が高い場合があります。 EVM-WASM の相互運用性 EVM と WASM は、同じストレージ スロットと状態ツリーを使用します。 Stylus は、WASM 内に EVM API を実装することにより、EVM との相互運用性を実現します。この統合は、WASM で広く採用されているホスト I/O モードを利用します。以下は、WASM でサポートされる EVM API の完全なリストであり、包括的な相互運用性のサポートを示しています。 read_args write_result storage_load_bytes32 storage_store_bytes32 call_contract delegate_call_contract static_call_contract do_call create1 create2 do_create read_return_data return_data_size emit_log account_balance account_codehash evm_gas_left evm_ink_left block_basefee block_coinbase block_gas_limit block_number block_timestamp chainid contract_address msg_reentrant msg_sender msg_value native_keccak256 tx_gas_price tx_ink_price tx_prigin memoery_grow console_log_text console_log console_tee カスタムプリコンパイル カスタム プリコンパイルは革新的な概念です。実行コストを削減しながら、高度な暗号プリミティブをオンチェーンに統合できる可能性があります。たとえば、テンソル計算をプリコンパイルして、オンチェーン機械学習のコストを削減できます。ただし、現在のコードベースにはカスタム プリコンパイル機能があるという証拠はありません。 EVM 用のプリコンパイルは存在しますが、交換できるように設計されていません。 これらの機能は、WASM の機能を活用してまだ開発中である可能性があります。これにより、EVM は WASM で作成された関数を呼び出すことができ、その後マシンコードにコンパイルされます。 リエントランシー CosmWasm のアクター モデルがリエントラントをサポートしていないのとは対照的に、Stylus の Rust SDK にはオプション機能としてリエントラントが含まれています。デフォルトでは、この機能はオフになっています。開発者は、契約で再入可能を有効にするかどうかを選択できます。 開発者は呼び出し中にストレージ キャッシュを確実にクリアし、他の安全対策を考慮する必要があるため、リエントラントを有効にすると API に影響します。この予防措置は、再入可能な呼び出しに関連する潜在的な脆弱性を防ぐために不可欠です。 結論 WASM はクラウドネイティブの分野で人気が高まっており、多くのブロックチェーンがスマート コントラクトの実行に WASM を採用しています。 Arbitrum はこの統合の先駆者ではありませんが、その実装は非常に大きな影響を与える可能性があります。 WASM は、ブロックチェーン環境を完全に見直したり、EVM を置き換えたりする立場にはありません。しかし、それは新興のzkロールアップに対するArbitrumの優位性を高める可能性があります。 Arbitrum の「EVM+」という用語は、このシナリオを適切に表しています。 EVM はスマート コントラクト プラットフォームの基盤を確立し、WASM は Arbitrum のパフォーマンスをさらに向上させることができます。
