FuelVMを探る：スマートコントラクトの実行のために特別に構築されたカスタム仮想マシン
FuelVMはモジュール化の特性を持ち、任意のブロックチェーンの実行エンジンとして機能します。原文标题：《FuelVMの探求》
作者：ライアン・スプロール
編纂：老雅痞
SwayとFuelVMの紹介
Fuel Labsは、次世代ブロックチェーンアプリケーションを拡張するための新しい実行レイヤーを構築しています。FuelVMはモジュール化された性質を持つように設計されており、任意のブロックチェーンの実行エンジンとして機能することができます。最初に、FuelVMはEthereumの第2層ロールアップとして展開されますが、理論的にはL2や別のL1としてどこにでも展開することができます。FuelVMは、ノードの要求を増やすことなくEthereumを拡張することを目的としており、既存のハードウェアからより多くの内容を引き出すことによって実現されます。
Fuel Labsはまた、契約を書くための新しいDSLであるSwayをFuelVMのために構築しています。SwayはRustとSolidityからインスパイアを受けており、理想的なスマートコントラクトプログラミング言語を作成しています。
FuelVMとは何ですか？
FuelVMは、スマートコントラクトを実行するために完全に特化して構築されたカスタム仮想マシンです。Fuel VMは、最初から詐欺防止が容易にできるように設計されており、オプティミスティックロールアップの取引実行レイヤーとして使用されます。
FuelVMは、取引実行のスループットを向上させるためにハードウェアをより良く活用できるように最適化されています。具体的には、UTXOに基づいており、各取引がどのUTXOにアクセスするかを明示的に定義することを強制します。実行エンジンは、各取引が触れる状態を正確に識別できるため、争いのない取引を簡単に見つけて並行処理することができます。
なぜVMが重要なのか？
スマートコントラクトブロックチェーンシステムにおいて、VMはスマートコントラクトコードを理解し、そのコードで定義されたルールに基づいて状態遷移を実行するシステムです。VMはスマートコントラクトブロックチェーンのオペレーティングシステムです。
これまでのところ、スマートコントラクトVMはEthereumが提供する初期バージョン以外に何のイテレーションもありません。現在広く使用されているすべてのスマートコントラクトチェーン（Solanaを除く）は、Ethereumと同じVMであるEVMを使用しています。
現在、EVMは「十分良い」とされています。なぜなら、拡張の主なボトルネックは取引実行の速度ではなく、コンセンサスエンジンがサポートできる帯域幅（ブロックスペース）だからです。第2層拡張ソリューションやCelestia、EIP-4844、Danksharding、EigenDAなどのDAソリューションの発展に伴い、ロールアップ取引データをL1に公開するコストはもはや主要な制約要因ではなくなります。
この帯域幅が安価になる環境では、次のボトルネックは計算スループットになります：基盤となるハードウェアの要求を十分に低く保ちながら、システムがどれだけ迅速に取引を実行できるかが、十分な分散化を実現するための鍵となります。FuelVMの利点は、設計時にこれらの将来の要因を考慮し、それに応じて最適化できることです。
FuelVMの差別化された利点
実行+検証の並行化
FuelVMの並行仮想マシンの背後にある秘密は、その厳格なアクセスリストです。これは、ユーザーに取引がどの契約に関与するかを示すことを要求します。FuelVM内の取引の正確な構成を確認することは非常に役立ちます。
入力：取引が触れるすべての契約UTXOのリスト + アンロックUTXOまたは述語スクリプトのデータ。
出力：作成されるUTXOを定義。
ガス情報：ガス価格 + ガス制限。
証人：メタデータ + デジタル署名の承認。
ここでの重要なポイントは、消費されるすべてのUTXOを列挙した明確な「入力」リストです。これには「特別な」契約UTXOも含まれます。VMがコードを実行する前に、取引がどの契約に触れるかを判断できれば、他の争いのない状態アクセス取引を安全に並行実行できます。
取引出力が検証に明示的に含まれているため、他のノードが提出したブロックが正しいかどうかを主張する過程で、重複する取引を順番に実行する必要はありません。これは、状態の競合がどのようであれ、検証が完全に並行して行えることを意味します。実際には、ノードがネットワークと同期する際に、より大きな並行性を実現し、より迅速に追いつくことができます。
ネイティブアセットシステム
EVMにはネイティブアセットとしてETHがあります。他のすべてのアセットは、残高会計（ERC20）を処理するスマートコントラクトを通じて実現されています。Fuelでは、開発者はスマートコントラクト内でアセットを自由に実装できますが、VMがネイティブにそれを処理するオプションもあります。
残高管理の観点から、ネイティブアセットはERC20スタイルのスマートコントラクトに比べていくつかのかなり大きな利点があります。まず、ネイティブアセットの操作は、スマートコントラクト内の状態を操作するよりも安価です。これは、より低いレベルの原始的な操作で実行されるためです（UTXOシステムがストレージを操作する代わりに使用されます）。次に、ネイティブアセットは、ETHを送信するのがERC20を送信するよりもはるかに簡単であるのと同様に、より良いユーザーエクスペリエンスを提供します（承認の設定が不要です）。
ネイティブアカウント抽象化 + 述語
アカウント抽象化は研究のホットトピックであり、EthereumコミュニティはEIP（EIP-86、EIP-2938、EIP-3074、EIP-4337、EIP-5003）において何度も試みを行ってきました。Ethereumをアカウント抽象化をサポートするように実装およびアップグレードすることは困難であり、これは主にコアチームのエンジニアリングの帯域幅/技術的負債と関連する複雑さ、そして優先度の高いプロジェクトの長いリストによるものです。多くのロールアップは、その新しい実行環境でアカウント抽象化を実装する機会を持っています。FuelVMもその一つであり、ネイティブアカウント抽象化に加えて、興味深い新しい原始的な機能である述語を含む予定です。
述語は、状態にアクセスしない純粋な契約スクリプトであり、単に真偽値（trueまたはfalse）を返します。UTXOは述語の背後にロックされることができるため、述語で定義された条件が満たされるまで使用できません。これにより、ユーザーは取引を特定の条件下でのみ実行するように設定でき、述語が満たされると自動的に取引が実行されるという興味深いUXの機会が生まれます。さらに、述語は破棄されると削除されるため、状態の膨張を引き起こすことはありません。
簡単なデモの例：ユーザーは、価格が述語で定義された閾値を満たす限り、Xトークンを購入する取引を設定します。見てください、pièce de résistance、完全にチェーン上の信頼不要のリミットオーダーで、状態の膨張を引き起こしません！
多次元リソース価格設定
リソース価格設定は、スマートコントラクトブロックチェーンの最も重要な構成要素の一つです。チェーン上のリソース需要を合理的で手頃なレベルに保つことで、分散化を維持します。リソース価格設定は、システムがネットワーク内のノードの「作業」に対してユーザーに料金を請求できるようにします。
EVMにおいて、EIPを導入する最も一般的な理由の一つは、オペコードの再価格設定です。これは、オペコードがハードコーディングされたガス価格を持ち、リソースの基礎価格が比例して拡張されないためです（歴史的に、CPUの改善はSSDよりも早く進んできました）。理想的には、これらのシステムは各リソースの価格を完全に独立して設定でき、全体の料金システムが基盤となるハードウェアシステムの変化に応じて動的に調整されることができます。
FuelVMは、動的な多リソース価格設定を実現でき、ノード運営者が基盤となるハードウェアをより良く最適化することを促進しつつ、「ブロックごとの効用」を最大限に最適化します。
この図は、スマートコントラクトの需要が他のスマートコントラクトよりも明らかに高い状況を示しています。ローカライズされたリソース価格設定により、他の契約は同じ程度の影響を受けません。NFTエアドロップはその良い例です。これはリソース価格設定と契約価格設定（Solanaスタイル）が完全に同じではありませんが、非常に似た効果を持ちます。特定のリソースプロファイルを持つスマートコントラクトは、他の契約とは異なる価格設定を持ちます。NFTエアドロップの例では、ホットコントラクトはストレージ集約型ですが、計算コストが非常に低いリソースプロファイルを持つ可能性があります。ストレージに対して計算量の要求が高いスマートコントラクトは、騒がしいNFTエアドロップの影響を受けません。
Solanaがアカウントや契約の料金市場を打破する戦略は、実際の基盤リソースとそれらの需要の間に抽象化の層を追加します。これは、非常に低い料金が存在する可能性があるが、ノード上の圧力が非常に高い状況を意味します。たとえば、イベント（たくさんの異なるNFTが同時にミントされるなど）によって、システム上のストレージ負荷が非常に高くなる可能性がありますが、すべてのトラフィックが1つのアカウントで発生するわけではないため、料金は非常に低くなります。各アカウントの料金モデルは、アカウントのホットパーティショニングの問題を確かに解決しますが、システムが基盤リソースを正確に価格設定できない状況を残します。したがって、失敗を引き起こす可能性があります。
基盤となるハードウェアリソースに基づいてシステムを価格設定することは、特定のネットワークに基づく抽象化層を追加しようとするよりも、より簡潔で正確です。
状態膨張に関する考慮事項
gethチームが何度も指摘しているように、gethの現在のボトルネックは状態の読み書きのI/Oです。最初の考えは、100%のMerkle Patricia trie（MPT）状態が標準デバイスのRAMに収まることでした。現在の状況は異なり、状態は900GBを超えて成長しており、年間約50-100GBの成長が予想されています。これは誰にとっても非現実的であり、ほとんどのノードは状態を保存するためにSSDに移行しています。歴史的に、SSDは状態サイズの増加に伴って急速に改善されないため、このコストはネットワークの分散化に影響を与え続けます。これはEthereumの研究者がしばらくの間議論してきた重要な問題です。
逆に、FuelVMは構築時にこの問題を考慮しています。Fuel Labsの共同創設者であるジョン・アドラーは、スマートコントラクトが状態や他のリソースを消費する過程でリソース価格設定が果たす役割について何度も言及しています。適切なリソース価格設定とより明確なデータモデルをUTXOシステムと組み合わせることで、FuelVMは状態を制御されたまま維持し、ノードの運営コストを削減し、ネットワークの分散化を増加させることができます。
「ソーター」の分散化
第2層は、メインチェーンから計算作業をオフロードすることを可能にしますが、取引をソートするメカニズムを提供する必要があります。多くの第2層ソリューションは、いわゆる「ソーター」を使用して起動されます。ソーターは、取引をソートし、状態遷移を実行し、状態ルートを更新して圧縮された取引情報を第一層のEthereumに提出する責任を持つ特権ノードです。注目すべきは、取引の同じシーケンスを冗長に実行する小型コンピュータよりも、ソートを担当するスーパーコンピュータが各エポックでより多くの取引を実行できることです。
この集中化されたソートの役割には、より多くの注意が必要な重要な問題がいくつかあります！
取引の順序を制御することは非常に利益をもたらします。Ethereumや他のブロックチェーンで観察されるように、MEVはソートされたブロックの人々の主要な収入源の一つです。今日、私たちが伝統的な金融で見ているように、一方的にソートを制御し、MEVをキャッチすることは、最終的にユーザーの実行能力の低下を引き起こします。
可用性と規制の観点から、集中化されたソーターは単一障害点となる可能性があります。1つまたは少数の組織がソーターを運営している場合、それらはダウンしたり、シャットダウンされたりする可能性があります。これはネットワークにとって生きたリスクです。
集中化されたソーターは第2層の取引を検閲する可能性があります。ソーターは任意の取引を選択し、ブロックを構築する過程で任意の順序で配置することができるため、検閲の能力が生まれます。多くのL2は、ユーザーがソーターを回避し、L1を利用して取引を直接含めることを許可する「強制取引」メカニズムを提供することでこの状況に対処しています。
ソーターはロールアップユーザーに対して一貫性のないチェーン状態の約束をする可能性があります。これは通常、equivocationと呼ばれ、基本的にはソーターがL2の特定の状態に対して誤解を招く約束をする可能性があることを意味します。これは、ロールアップの迅速な確定が信頼できるステップであり、ソーターがその信頼を悪用する可能性があるため、ユーザーが意図しないことをする結果を招くことがあります。
Fuelはこれらの問題をどのように解決しますか？
まず、Fuelは単なるロールアップやL1ブロックチェーンではなく、状態遷移をアプリケーションするシステムです。ロールアップとして構成されるか、L1としてネットワーク内でコンセンサスを実現する場合、状態遷移をL1に公開することができます。重要な違いは、Fuelの実行エンジンはコンセンサスや取引のソートを気にしないことです。Fuelは、できるだけ早く取引を適用することだけを担当します。しかし、Fuelは非常に軽量なハードウェア上で実行でき、検証が非常に安価であるため、Fuelは多様で分散化されたコンセンサスネットワークを導くことができ、EVMのような性能が劣る実行エンジンを持つ同等のシステムよりもはるかに安価です。
さらに、Fuelチームは分散化、MEV、その他の考慮事項を組み合わせた第2層のトークンエコノミクスを検討しています。Fuelの共同創設者であるジョン・アドラーは、1月に第2層ブロックチェーンのトークンモデルに関する記事を書き、ロールアップがブロック生産者として料金を請求する権利を通じてブロックスペースの希少性をトークン化することを許可することで、ブロック生産の分散化を助けるトークン設計を説明しました。料金はブロック生産者の収入の一部に過ぎず、他のチェーンで見られるように、MEVは収入のもう一つの大きな部分です。ブロックスペースの希少性と同様に、MEV収入もブロック生産権を通じてトークン化されるでしょう。
状態モデル：UTXO vs アカウントベース
UTXOデータモデルとアカウントモデルの違いを概念化する最良の方法は次のとおりです：UTXOは現金の紙幣に例えることができ、アカウントモデルは銀行の帳簿に似ています。アカウントシステムは自然に状態の膨張を引き起こします。なぜなら、各取引が同じアカウントにアクセスしようとするからです。一方、UTXOは正しく設計されていれば、争いが少なくなります。この特性により、並行化がより良く実現でき、状態の膨張を防ぐために状態の切り捨てのプロセスを簡素化することができます。
現金対銀行の帳簿の比喩を続けると、UTXOの並行化がはるかに容易である理由が明確になります。2つの現金取引は同時に発生でき、互いに何の情報も必要としませんが、1つの帳簿に2つのアカウントの更新がある場合、両方の取引は同じ共有帳簿を更新する必要があります。
VM戦争
Fuelの他にも、Mysten LabsやAptosのような他のチームがスマートコントラクトブロックチェーンの次世代仮想マシンを開発しています。後者は、Facebookのエンジニアによって設計されたLibraプロジェクトの一部を使用してMoveVMを開発しています。これは、次世代ブロックチェーンアプリケーションをサポートするために新しい実行環境が必要であるという主張をさらに支持しています。これらのすべてのプロジェクトは興味深いアプローチを持ち、異なるトレードオフを行っています。
MoveVMが停滞していた数年間、Libraが訴訟に忙しい間に、暗号通貨の世界は多くの変化を遂げました。Fuelはこれらの変化に適応し、急速に変化する業界で敏捷性を保つことができましたが、Moveはやや遅れをとっています。それでも、MoveはFacebookから分離され、新しい大型の資金調達ラウンドが完了したため、彼らは確かに戦う準備が整っています！
結論
他のL2とは異なり、Fuelは最初からVMを設計することでソーターの役割を分散化することを計画しており、高価なハードウェアを追加する必要はありません。
Fuelは柔軟です。多くの環境に展開できますが、最優先事項はEthereumと整合性のあるオプティミスティックロールアップとしての展開です。
FuelのユーザーエクスペリエンスはEVMよりもはるかに優れており、アカウント抽象化、スクリプト、述語などのネイティブで新しい方法でチェーンと対話します。
UTXOデータモデルの争いは、アカウントデータモデルよりも自然に少なく、より多くの並行性と少ない状態の膨張をもたらします。
