著者: Yiping、IOSG Ventures この記事は IOSG のオリジナル コンテンツであり、業界の学習と交流のみを目的としており、投資の参考となるものではありません。引用が必要な場合は出典を明記してください。転載の場合は、IOSG チームに連絡して許可と転載の指示を求めてください。この記事で言及されているすべてのプロジェクトは、推奨または投資アドバイスを構成するものではありません。 zkSync や StarkNet などの ZKRU がメインネットを立ち上げるにつれて、レイヤー 2 の状況は急速に進化しています。従来、Arbitrum のような OPRU は最初に市場に投入されるため、より強力なエコシステムを備えています。対照的に、ZKRU は、より高いスループットとより低い料金を提供する画期的な技術です。ここ数カ月間、より高速で安価なトランザクションを求めて、より多くのアクティビティがレイヤー 1 からレイヤー 2 に移行しています。イーサリアムのTVLは過去1年間で400億ドル近くから200億ドルに減少した。ただし、レイヤー 2 の TVL は異なる状況を示しており、大幅な増加はレイヤー 2 の採用が加速していることを示しています。
Arbitrum はレイヤー 2 TVL 市場シェアの 50% 以上で首位を走っていますが、ZKRU も努力を続けています。 Arbitrum は先行者利益により、優位な地位を維持できます。
毎日のトランザクション数を分析すると、zkSync や StarkNet などの ZKRU がスループットで OPRU をわずかに上回っていることがわかります。ただし、日々の TPS ではわずかに遅れをとっていますが、Arbitrum のエコシステムの利点は依然として残っています。
毎日のトランザクション数を分析すると、zkSync や StarkNet などの ZKRU がスループットで OPRU をわずかに上回っていることがわかります。ただし、日々の TPS ではわずかに遅れをとっていますが、Arbitrum のエコシステムの利点は依然として残っています。
OPRU は ZKRU よりも長く存在しています。ただし、ZKRU はメインネットを立ち上げ、他のエコシステムからユーザーを引き付けています。 OPRU 分野のリーダーとして、Arbitrum は新しいアップデートで ZKRU の台頭に対抗することが期待されています。
アービトラム: スタイラス
開発者がゼロ知識テクノロジとコストを最適化するにつれて、ZKRU は拡張性の利点により市場シェアを獲得し続ける可能性があります。ただし、Arbitrum のネットワーク効果により、競争圧力にもかかわらず堅牢性を維持することができます。 Stylus のような革新的なソリューションを通じて、Arbitrum は独自の技術力でリーダーの地位を補完し、レイヤー 2 レースの最前線に留まり続けることができます。
つまり、Stylus は Arbitrum 用に設計された革新的な新しいスマート コントラクト環境であり、開発者が Rust、C++、Solidity などのプログラミング言語で効率的で相互運用可能なプログラムを作成できるようになります。
一般的なコンピューティングをブロックチェーンに開放し、さまざまなテクノロジー スタックを使用する開発者を歓迎します。
WASM
Stylus は、既存の Ethereum 仮想マシン (EVM) と並行して実行される WebAssembly (WASM) 仮想マシンを追加することで機能します。 WASM にコンパイルされる言語で記述されたスマート コントラクトは、Solidity よりも 10 倍以上高速にネイティブで実行できるため、ガス コストが大幅に削減されます。 EVM は引き続き完全に機能するため、既存の Solidity 契約は現在と同様に機能し続けます。 2 つの VM は同期して動作し、異なるプログラミング言語で書かれたコントラクトが相互に呼び出しながら、基礎となる同じブロックチェーンの状態を変更できるようにします。
カスタムプリコンパイル
さらに、Stylus はカスタム プリコンパイルもサポートしています。
プリコンパイルは、特定の暗号化機能またはユーティリティ機能を非常に効率的に実行するために使用される、イーサリアムおよびアービトラム上の低レベル モジュールです。たとえば、ECDSA 署名の検証と SHA256 ハッシュの計算のためのプリコンパイルがあります。
新しいプリコンパイルを追加するには、すべてのバリデーターが EVM のアップグレードを調整する必要があるため、しきい値は高くなります。 Stylus を使用すると、開発者は Rust または C++ で書かれた独自のプリコンパイラを簡単にデプロイできます。
たとえば、チームは C で書かれた暗号ライブラリを取得し、変更せずに Arbitrum にデプロイできます。これにより、これらの暗号化プリミティブを超高速のネイティブ速度で実行できるようになります。
他の契約では、暗号化テクノロジを利用するネイティブ プリコンパイルと同じように、この Stylus を「プリコンパイル」と呼ぶことができます。すべてのガス計量と不正防止は自動的に機能します。
これにより、チームは、特別なチェーンのサポートなしで、カスタム暗号化、特別なペアリングベースの曲線、その他の新しいプリミティブのプロトタイプを作成できるようになります。イーサリアムの研究者は、Arbitrum 上で EIP 提案を Stylus プリコンパイル済みバージョンとして展開することで、早期に EIP 提案を反復することもできます。
開発者が新しい暗号プリミティブをオンチェーンにネイティブに導入できるようにすることで、Stylus は構築できる範囲を大幅に拡大します。プリコンパイルは、EVM でサポートされる機能に限定されなくなりました。
スタイラスの仕組み
ブロックチェーンの世界における WASM の広範な役割を掘り下げる前に、Arbitrum が EVM と WASM の共存をどのように調整するかを理解することが重要です。それは単に 2 つの別々のエンジンを搭載しているというだけではなく、両方の長所を強化する相乗効果のある関係なのです。
Arbitrum の独自のアーキテクチャにより、統合された状態、VM 間呼び出し、および互換性のある経済モデルのおかげで、EVM と WASM 間のシームレスな同期操作が可能になります。
Solidity または他の EVM 言語で書かれたスマート コントラクトは、通常どおり EVM バイトコードにコンパイルされます。これらのコントラクトは、実行されると、現在と同様に EVM 上で実行されます。
Rust、C++、C などの WASM にコンパイルされる言語の場合、ワークフローは次のとおりです。
- 開発者は、Clang や Rustc などの既製の WASM コンパイラーを使用して、スマート コントラクトを WASM にコンパイルします。
- WASM バイトコードは、圧縮形式で Arbitrum チェーンにアップロードされます。
- コントラクト所有者は、「ArbWasm」のプリコンパイルされた「compileProgram」メソッドを呼び出します。これにより、WASM のセキュリティ ツールがセットアップされ、ガスコストが発生し、バリデーター ハードウェアに最適化されたネイティブ コードにコンパイルされます。
- コントラクトが呼び出されると、EVM よりもはるかに高速な Wasmer などの WASM ランタイムで実行されるため、ガス料金が節約されます。
WASM メータリングは、EVM のようなオペコードごとではなく、各基本ブロックの前に Gas を課金します。これはより効率的であり、契約が手に負えなくなることがなくなります。
EVM と WASM
2 つの仮想マシン (VM) は同期して実行され、同じグローバル状態を共有しながら相互に呼び出すことができます。トランザクションは部分的に EVM で、部分的に WASM で実行でき、結果はシームレスに結合されます。
ちょっと待ってください。どうすれば 2 つの VM がシームレスに同期して動作できるのでしょうか?
Polkadot は XVM を通じてこれを実現します。 Polkadot とは異なり、WASM と EVM は Arbitrum 上でシームレスかつ同期的に動作します。その理由は次のとおりです。
- 単一状態: 両方の VM が同じ基礎となるデータ構造と状態トライにアクセスします。 1 つの VM のコントラクトは、別の VM のコントラクトと同じ場所に読み取り/書き込みできます。これにより、チェーンのステータスを統一的に表示できます。
- VM 間呼び出し: トランザクションが EVM コントラクトと対話すると、Geth はそれを処理して結果を提供します。その後、EVM コントラクトが WASM プログラムを呼び出すと、WASM VM がその部分の結果の計算を引き継ぎます。
- 共有コンテキスト: ブロック データ、送信者アドレスなどのシステム情報は両方の VM で利用できます。 WASM コントラクトは、Solidity コントラクトと同様にブロック番号を取得できます。
- 単一のコンセンサス: バリデーターは 2 つの VM を実行してトランザクションを検証し、正しいチェーン状態についてコンセンサスに達します。紛争が発生した場合は、統一不正防止システムが発動されます。
- 互換性のある経済性: ガス計測などの概念が個々の VM に拡張され、どちらの環境でも適切なコンピューティング コストとリソースが確保されます。
不正行為を証明するために、ベリファイアは EVM と WASM の実行を二分して、必要に応じて無効なステップを特定します。 WASM の構造により、システムは終了を保証し、証明の有効性を強制することができます。
ブロックチェーン | WASM
WebAssembly (WASM) の変革の可能性を認識しているプラットフォームは Arbitrum だけではありません。また、Polkadot と Cosmos は WASM を自社のエコシステムに統合しており、各プラットフォームは独自のメリットと機能を提供します。
Polkadot を使用すると、ユーザーは WASM を使用してスマート コントラクトを開発でき、組み込み DSL である AssemblyScript、および Rust に似た Ink! の 2 つの言語をサポートします。
一方、Cosmos はスマート コントラクト ランタイムとして CosmWasm を使用しており、開発者が Rust でコントラクトを作成できるようにしています。
ブロックチェーン業界が WASM をこれほど受け入れている理由を掘り下げる前に、Cosmos と Polkadot の際立った具体的な利点を理解する必要があります。
Cosmos は、WASM の次の利点を強調しています。
- Rustライブラリとの互換性
- 多様な開発者コミュニティ
- 再入攻撃に対する保護など、セキュリティの強化
- テストが簡単
- ハイパフォーマンス
Polkadot の WASM ランタイムには次の機能があります。
- Rustライブラリとの互換性
- 多様な開発者コミュニティ
- 再入攻撃に対する保護など、セキュリティの強化
- テストが簡単
- ハイパフォーマンス
Polkadot の WASM ランタイムには次の機能があります。
- ハイパフォーマンス
- EVMとの相互運用性
- プラットフォームに依存しない
- コンパクトなバイナリサイズ
- Rust と AssemblyScript (TypeScript スタイル) の両方をサポート
Polkadot、Cosmos、Arbitrum は WASM によって提供されるいくつかの共通の利点を共有していますが、各プラットフォームには独自の固有の属性もあります。
これらの主要なブロックチェーン プラットフォームによる WASM の広範な採用は、業界における WASM の重要性が高まっていることを示しており、このテクノロジーが急速に現代のブロックチェーン アーキテクチャの基礎となりつつある理由を理解することが重要になっています。
WASMを選ぶ理由
WASMとは
ブロックチェーンと WebAssembly (WASM) の相乗効果を理解するには、まず WASM とは何か、そしてその開発の背後にある原動力を理解する必要があります。
WebAssembly は、Web ブラウザ内でネイティブに近い速度でコードを実行できるようにするバイナリ命令形式です。これは、C や Rust を含むさまざまなプログラミング言語のコンパイル ターゲットとして機能し、高速、効率的、安全になるように設計されています。 WASM は、Web ベースのプログラミングとシステム レベルのプログラミングの間のギャップを効果的に橋渡しし、Web のパフォーマンスと機能を向上させます。
WebAssembly の「Web」は、JavaScript 環境 (通常はブラウザーで見られる) 内で実行できる機能を強調しています。これらの設定では、開発者は WASM API に完全にアクセスでき、包括的な Web API サポートを利用できるため、Web の動作を大幅に制御できます。
WASMの歴史
「一度書けば、どこでも実行できる」という原則に従って、WASM は長年の課題に対する強力なソリューションとして登場しました。 2016 年の時点では、多くのプログラムがドメイン固有言語 (DSL) を通じて新機能を導入していますが、これにはメンテナンス、効率、セキュリティの間でトレードオフが伴うことがよくあります。これらの側面を損なうことなく、無数のサーバーに新しい機能を提供できるソリューションのニーズが高まっています。
さまざまな既存のソリューションの欠点が評価されました。
- システム仮想マシン
- 頻繁に起動とシャットダウンを行うと、過剰なオーバーヘッドが発生します
- セキュリティを確保するためのコードの可視性の欠如
- パフォーマンス要件が抽象的すぎる
- 容器
- セキュリティを確保するためのコードの可視性の欠如
- 高レベルの抽象化による非効率
- 頻繁な操作により大きなオーバーヘッドが発生する
- 言語レベルの仮想マシン
- 安全性を確保するために頻繁な変更が必要
- V8 などの組み込み VM はリソースを大量に消費します
- 新しい言語のセキュリティ モデルへの適応が遅い
- まだ抽象的すぎる
- 命令セット アーキテクチャ (ISA)
- 効果的にサンドボックス化するのが難しい
- 以前の Google プロジェクトは WASM に移行されました
- 成熟した実装の欠如
2018 年までに、WASM 開発は、さまざまなアーキテクチャ、サーバー、組み込みハードウェアでの実行、さらには複数言語のサポートに重点を置いて勢いを増しました。 Java とは異なり、WASM はセキュリティを損なうことなく設計されています。 2019 年までに、WASM モジュールを強化し、言語間の相互運用性を可能にするコンポーネント モデルが導入されました。これにより、HTTP ライブラリを一度作成すれば、それを複数の言語で使用するなどのソリューションが可能になります。
現在まで、WASM にはさまざまな機能があり、ブロックチェーンを含むクラウドネイティブのシナリオでの採用が増えています。その利点は次のとおりです。
現在まで、WASM にはさまざまな機能があり、ブロックチェーンを含むクラウドネイティブのシナリオでの採用が増えています。その利点は次のとおりです。
- ハイパフォーマンス
- コンパクトなバイナリサイズ
- クロスプラットフォームの移植性
- C/C++、Rust、AssemblyScript などの複数の言語をサポートします。
- JavaScriptエンジンで実行
- メモリと CPU の制限がある強力なサンドボックス
- 非常に速い起動時間 (通常はミリ秒以下)
WASM コミュニティは、言語間での統合とパフォーマンスの向上に向けて取り組み続けています。
WASM の歴史的進化を理解することは、Stylus のようなブロックチェーン プロジェクトを含む、さまざまな設定における WASM の現在および潜在的な役割を理解するための貴重なコンテキストを提供します。この背景により、ブロックチェーン エコシステムにおける WASM の実装に関する問題や懸念事項を調査する際に、微妙な理解を得ることができます。
スタイラスに関するQ&A
言語サポート
WASM の進化は、Stylus が Arbitrum エコシステムへの魅力的な追加である理由を明らかにしますが、同時にいくつかの制限と懸念事項も浮き彫りにします。懸念の 1 つは言語サポートです。 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](https://twitter.com/evmcheb/status/1697537852522049990)** を Stylus エコシステムに導入する取り組みが進行中です。
言語選択のジレンマ
ドメイン固有言語 (DSL)、組み込み DSL (eDSL)、および汎用言語のいずれかを選択するには、低レベルの制御と高レベルの抽象化の間のトレードオフが必要です。新しい DSL を開発するには、ツールチェーンとエコシステムの開発に多大な投資が必要です。対照的に、eDSL は汎用言語のサブセットとして、既存のツールとの統合が容易であり、学習曲線も短くなります。たとえば、JavaScript や Python などの一般的な言語で eDSL を作成すると有益です。
共通言語では SDK を使用する必要があります。SDK を使用すると、追加のツールが導入され、冗長性が増し、コードの表現力が低下し、API 呼び出しやオブジェクト操作が長くなります。
言語の選択と eDSL 開発の間の適切なバランスを見つけることが、ユーザーフレンドリーなツールを提供しながら、より広範な開発者コミュニティを引き付ける鍵となる可能性があります。現在のデータによると、トップの暗号通貨開発者コミュニティは依然としてイーサリアムに集中しています。ただし、Polkadot、Cosmos、Solana など、スマート コントラクトに Rust を活用するプラットフォームも注目を集めており、開発者コミュニティの間で急速に成長しています。
パフォーマンス
WASM は実行速度を大幅に向上させ、パケット サイズを削減します。 Stylus はまだメインネットに導入されていませんが、他のネットワークのベンチマークは有用な参考として役立ちます。実行時間は 4 ~ 8 倍速くなり、コンパイルされたサイズは約 50% 減少します。
現在、Stylus にはコントラクトのサイズ制限があり、非圧縮で約 128KB が上限です。この制限により、Solidity などの他の言語から大規模なスマート コントラクトを移植することが困難になります。 Stylus のコード ベースでは、この制限は次のように説明されています。
WASM は起動時とシャットダウン時にある程度のオーバーヘッドが発生することに注意してください。軽量の操作の場合、EVM は実際に WASM よりもコスト効率が高い場合があります。
EVMとの相互運用性
EVM と WASM は同じストレージ スロットとステート ツリーを共有するため、Stylus と EVM の相互運用性が容易になります。これは、一般的なホスト I/O パターンを使用し、WASM に実装された EVM API を通じて実現されます。サポートされている EVM API の包括的なリストは、相互運用性が完全にサポートされていることを示しています。
カスタムのプリコンパイルされた契約
この側面は未知の領域を表すため、特にエキサイティングです。カスタムのプリコンパイルされたコントラクトには、より低い実行コストで追加の暗号プリミティブをオンチェーンに導入できる可能性があります。また、テンソル計算をプリコンパイルされたコントラクトとして導入することで、推論のコストを削減することもできます。ただし、カスタムのプリコンパイルされたコントラクトに関連する既存のコードはないようです。 EVM コンポーネント用にプリコンパイルされたコントラクトが存在しますが、それらはホットスワップ可能ではありません。
この機能は、WASM の機能を利用して、まだ開発中の可能性があります。 EVM は、WASM で記述された関数を呼び出して、それらをマシンコードにコンパイルできます。
リエントラント機能
CosmWasm (リエントランシーなしで Actor モデルを使用する) とは対照的に、Stylus の Rust SDK は、デフォルトで機能フラグとしてリエントランシーをオフにします。開発者には、この機能を手動で有効にするオプションがあります。
リエントラント機能を有効にするには、API の調整が必要になります。特に、開発者は、通話中にストレージ キャッシュを更新するなどのセキュリティ上の予防策について注意する必要があります。
洞察力
Stylus は、高性能暗号化、ゲーム、AI など、EVM のみを使用するとガスを大量に消費する新しいユースケースを切り開きます。また、プリコンパイルされたコントラクトをカスタマイズできるため、開発者はアップグレードを待たずに独自の暗号化やその他の基本機能を追加できます。過去には、Cosmos や Polkadot など、一部の非イーサリアム エコシステムが WASM を採用しているのを見てきました。 WASMがイーサリアムコミュニティに採用されるのはこれが初めてです。全体として、Stylus はスマート コントラクト開発における大幅な進化を表しており、既存のすべてのアプリケーションとの相互運用性を維持しながら、イーサリアムと Arbitrum の拡張を支援します。
Stylus を Arbitrum の Layer2 SDK に統合することで、Layer 3 開発者に大きな柔軟性が提供されます。以前はガス制限を超えていた集中的な計算をチェーンに移動できるようになり、新たな可能性が開かれます。開発者はもはや Solidity に限定されず、ニーズや専門知識により適した言語であれば Rust または C++ を選択することもできます。カスタムのプリコンパイルされたコントラクトにより、最適なパフォーマンスを実現するために、優先される暗号化、ユーティリティ、およびその他のヘルパー関数をチェーンにシームレスに移行できます。それぞれのユースケースに合わせた言語で低レベルのロジックを直接記述することで、よりスムーズな開発につながります。開発者は、ガスコストを回避するために簡単な修正を行うのではなく、主要な製品機能に集中できます。 Stylus は言語とガスの制約を取り除くことで、第 3 層のビルダーが自分たちのドメインに適切なツールを使用して、最初から最も効率的なユーザー エクスペリエンスを構築できるようにします。
Stylus は、Arbitrum が大規模に革新し、新しい仮想マシンを統合できる能力も示しています。 Arbitrum & Offchain Labs の共同創設者兼主任研究員である Ed Felten 氏は、Arbitrum は業界で人気のあるツールとプログラミング言語に基づいて開発されていると述べました。より迅速にテストを作成し、レガシー システム上で新しい機能を開発できます。 OP は ZK 化の道をさらに進み、ハイブリッド ロールアップのアイデアに徐々に移行しています。 Optimism は現在、Risc0 と協力して、Zeth を使用して OPRU のゼロ知識証明を生成しています。このソリューションを使用すると、Optimism は OPRU に追加の変更を加える必要がありません。 Zeth に興味がある場合は、私が以前に書いたものを読むことができます [Twitter](https://x.com/glazecl/status/1709947992168710174?s=20)。
私たちは Arbitrum で AI アプリケーションを見ることを非常に楽しみにしています。現在、チェーン上で機械学習を実行すると大量のガスを消費するため、開発コストが高くなります。ゼロ知識 ML はコストを削減できますが、開発者にとってはさらに複雑さが増します。 Stylus を介してテンソル演算をカスタムのプリコンパイルされたコントラクトとして実装し、数分の 1 のコストでネイティブに実行できれば、高パフォーマンスのオンチェーン機械学習の新たな可能性が開かれるでしょう。開発者が使い慣れた言語 (Python など) で簡単に統合できるプリコンパイルされたコントラクトとして ML アルゴリズムを迅速に構築してデプロイできるようにすることで、Arbitrum は DeFi や GameFi などで次世代の AI イノベーションを推進できます。 Stylus のパフォーマンスと柔軟性により、ガスの最適化ではなく革新的な ML アーキテクチャに集中できるようになります。私たちは、コミュニティの創造性がこの新たなパラダイムに適用されることを楽しみにしています。
全てのコメント