UTXOモデルによる並列実行：FuelVMの利点とは？

著者：Fuelchina; ソース：Fuel Network

ネットワーク使用量の増加に伴い、イーサネット仮想マシン（EVM）は徐々にパフォーマンスの限界を露呈しつつある。.現在、イーサネットは1秒間に約15～30トランザクションしか処理できず、ピーク時には十分でないため、トランザクション手数料が高騰し、ユーザー・エクスペリエンスが損なわれている。さらに、より多くのアプリケーションやユーザーが利用するようになると、イーサネットの状態データは劇的に拡大し、ノード全体の運用にコストがかかり、保守が困難になる。これらの問題は、イーサが大規模な分散型アプリケーションをサポートする可能性を制限しています。

これらの問題に対処するため、レイヤー2のソリューションであるRollupsは、計算とストレージ作業の多くをオフチェーンに移し、その結果をイーサネットのメインチェーンに提出することで、効率を高め、コストを削減する方法を提供します。ロールアップには主に2つのタイプがある。トランザクションの有効性を検証するためにチャレンジ期間に依存するオプティミスティック・ロールアップと、ゼロ知識証明によって直接検証されるZKロールアップである。これらのソリューションはスケーラビリティの点では優れているが、最終結果は依然としてメインチェーン上で処理・検証される必要があり、EVMのアーキテクチャと設計によって制限されている。

基礎となるプロトコルが処理できるトランザクション数に制限がある場合、高速でなくてもEVMで十分です。しかし、イーサネットは、カンクンのアップグレードでEIP-4844が導入されるなど、技術的な手段によってその基礎となるプロトコルのスケーラビリティを劇的に向上させている。イーサネットのベースレイヤーがより多くのトランザクションを処理できるようになると、EVMの実行速度が新たなボトルネックとなる。したがって、EVMの実行効率を向上させることが、将来的にシステム全体のパフォーマンスを向上させるカギとなるだろう。

この新たなボトルネックに対処するため、Fuelチームは、効率的な並列処理とモジュール実行のために設計された、より効率的な仮想マシンアーキテクチャであるFuelVMを開発しました。処理速度を大幅に向上させます。

FuelVMのユニークな利点を理解する

Fuelはイーサロールアップ用に設計されたモジュール式実行レイヤです。FuelVMはFuelシステムの中核となる仮想マシンで、高い計算帯域幅と並列処理用に設計されています。FuelVMはUTXOモデルを採用することで並列処理を可能にし、アクセスリストを利用することでトランザクションの競合を回避し、組み込みのネイティブアセットシステムによってトランザクションの競合を回避します。FuelVMは、UTXOモデルを採用することで並列処理を可能にし、アクセスリストを利用することでトランザクションの衝突を回避し、ネイティブなアセットシステムを内蔵することでスマートコントラクトへの依存を低減します。

• 並列処理のためのUTXOモデル：UTXOモデルはビットコインから派生したもので、資産は有向非循環グラフ（DAG）で表されます。資産はアドレス間に格納される。FuelはUTXOモデルを使用してトランザクションの並列処理を実装する。UTXOモデルはステートを独立した要素に分割するため、各トランザクションはどのUTXOを使用するかを明示的に指定する必要があり、競合しない複数のトランザクションを同時に実行できる。さらにFuelVMは、スマート・コントラクトのチューリング完全性を高めるために、述語とスクリプトの概念を導入している。述語はUTXOを使用できる条件を定義し、スクリプトは複数のスマート・コントラクトの呼び出しの実行に使用される手続きです。UTXOモデルのステートはアトミックであり、各UTXOは一度しか使用できず、その後新しいUTXOが生成されます。したがって、スクリプトと述語はデータを永続的に保存しないため、ステートの増加を抑えることができます。そのため、スクリプトと述語はデータを永続的に保存せず、状態の増大を抑えます。これは、ブロックチェーン上の状態の肥大化の問題を軽減し、ノードの実行コストを削減するのに役立ちます。

• アクセスリストが並列トランザクション間の競合を回避：FuelVMでは、各トランザクションがアクセスするUTXOを明示的に指定する必要があります。これらの指定に関する情報がアクセスリストを構成します。アクセスリストを使用すると、FuelVMは、各トランザクションが影響を与える状態を事前に把握することで、トランザクション間の競合を回避し、競合しないトランザクションを複数のCPUスレッドで同時に並列実行できます。

• ネイティブ資産システム: FuelVM は仮想マシン レベルでネイティブ資産を直接処理します。各ネイティブ・アセットは、アセットの作成、転送、破棄処理を実行する特定のオペコードのセットによって定義されるため、各アセットごとにスマート・コントラクトを記述して展開する必要がありません。このアプローチにより、スマート・コントラクトの呼び出しの回数と複雑さが減り、トランザクションのガス・コストが削減される。これは、資産の頻繁な移動を伴うアプリケーションにとって特に重要である。さらに、複雑なスマート・コントラクトへの依存を減らすことで、潜在的なスマート・コントラクトの脆弱性のリスクも低減します。

• アカウント抽象化のサポート：アカウント抽象化により、開発者は、プロトコルで事前に定義された検証ルールに依存することなく、アプリケーション層でカスタマイズされたトランザクション検証スキーム（マルチ署名、多要素認証など）を定義できます。ルールに依存する必要がありません。FuelVMでは、この柔軟性は述語によって実現される。述語は、UTXOを使用できるかどうかを決定するためにプログラムできる検証条件として機能します。述語はチェーン上のステートを保存する必要がなく、トランザクション検証中にのみ評価されるため、述語とUTXOモデルの組み合わせはチェーン上のステートの増加を抑えます。

FuelVMの挑戦：テクノロジーからマーケットへの二重のテスト

。FuelVMのアーキテクチャ機能を最大限に活用するために、Fuelプロジェクト・チームはSway言語と開発者ツールチェーンForcを開発しました。SwayはRustとSolidityにインスパイアされ、FuelVMのために特別に設計された新しいプログラミング言語で、構造体、特性ベースの継承、ジェネリック型などの最新のプログラミング言語の機能を提供します、Forcツールチェーンは、パッケージマネージャ、VSCodeプラグイン、テストインフラ、ブロックエクスプローラを含む、Swayコードの開発、デプロイ、テストのためのオールインワンソリューションを提供します。FuelVMは新しいプログラミング言語を使用するため、開発者にとっては全く新しい開発環境となり、初期の採用率に影響を与える可能性がある。その結果、Fuelプロジェクト・チームは、強力で活発な開発者コミュニティを構築して、この技術の採用をサポートし推進する必要があります。

また、FuelVMはEVMと互換性がないため、既存のEVMアプリケーションを直接FuelVMに移行することはできません。このため、初期ユーザーや開発者によるFuelVMの採用が制限される可能性がある。この障壁を克服するために、Fuel プロジェクトは、開発者が既存のアプリケーションを FuelVM プラットフォームに移行できるように、移行ツールやリソースを提供する必要がある。これらのツールやリソースには、開発者が新しいプラットフォームにスムーズに移行できるように、コード変換ツール、互換性レイヤー、および詳細な移行ガイドを含めることができます。

FuelVMはまた、すでに比較的成熟したRollupsソリューションと競合することで、独自の技術的優位性と市場価値を証明する必要があります。例えば、状態インフレやスマートコントラクト攻撃のリスクの低下などだが、この新しいVMアーキテクチャとプログラミング言語は、そのパフォーマンスと安定性を検証する時間も必要となるだろう。

将来の展望：並列実行は必然になった

ますます多くのDAppsが登場しています。従来のシングルスレッド実行モデルでは、もはや大規模アプリケーションのニーズを満たすことはできません。そのため、並列実行を模索することは、技術開発において避けられないトレンドとなっている。今年前半には、並列実行が話題となり、ブロックチェーン技術の発展にとって重要な方向性となり、その可能性に気づき、積極的に取り組むプロジェクトが増えている。FuelVMは、並列実行の革新的な実践として、UTXOモデルと組み合わせることで並列実行機能を実現し、ネットワーク全体のスループットとパフォーマンスを向上させます。この機能は、デリバティブ取引所やオールチェーン・ゲームなど、高頻度取引と低レイテンシーを必要とするアプリケーションに特に適しています。状態の肥大化を抑え、リソース効率を向上させることで、FuelVMは分散型アプリケーションによりスケーラブルで効率的な実行環境を提供します。