によって書かれた モハメド・フーダ 編集 テックフロー
! Dappロールアップテクノロジーの解釈:高スループットAPPを主流にする方法は?
アプリケーションロールアップは、イーサリアムアプリケーションの特定のセットをスケーリングする上で明確な勝者として浮上しています。 これらのアプリケーションは、アクセス許可のない強力な所有権の保証の恩恵を受けますが、すべてのアプリケーション ユーザー間で同時に対話する必要はありません。 完全にオンチェーンのゲームが最良の例です。 オンチェーンゲームは、ゲームアセットの強力な所有権の恩恵を受け、ゲームへの匿名の参加を可能にし、ゲームの匿名の変更を可能にします。 それでも、ほとんどのゲームでは、すべてのプレイヤーが同時に対話する必要はありません。 アプリのロールアップスケーリング戦略の恩恵を受けることができる他のアプリケーションには、NFTマーケットプレイス、永続的な交換、オンチェーンAI推論などがあります。
アプリケーションのロールアップは、これらのユース ケースの多くで既に推奨される実装です。 ただし、標準のロールアップ実装である EVMRollup には、依然として重要なスケーラビリティの制限があります。 毎秒約 100 トランザクションのスループットに達する可能性があります。 このスループットは、ゲームの種類によっては、一部のオンチェーンゲームで十分な場合があります。 ただし、ほとんどのゲームでは、多数の同時プレイヤー (1,000 人以上) をサポートするために、より高いスループットが必要です。 この記事では、数十万人の同時参加者に到達するためにアプリケーション ロールアップを拡張する方法について説明します。 それぞれのアプローチについて、適切な種類のアプリケーション/ゲームとそれが直面する課題について説明します。
水平方向のスケーラビリティは、アプリケーションのロールアップをスケーリングする最も簡単な方法です。 ただし、この単純さは構成可能性を犠牲にするため、シングルプレイヤーゲームなどのアプリケーションの小さなサブセットにのみ適しています。
水平方向のスケーラビリティとは、単に複数のアプリケーションロールアップ(オプティミスティックまたはZK)をデプロイし、すべてのロールアップに同じスマートコントラクトをデプロイすることを意味します。 アプリケーションのフロントエンドは、容量、場所、または特定のアプリケーション オプションに基づいて、ロールアップの 1 つにユーザーをシームレスに誘導します。 Alt Layerは最近、スケーラブルな2048 FOCGゲームをリリースすることで、このコンセプトを実証しました。 ゲームのフロントエンドでは、ユーザーは地理的な場所に基づいて参加するロールアップを選択できます。 Caldera のようなサービスとしてのロールアップ プロバイダーは、これらのロールアップのスピンと管理に関連するすべてのインフラストラクチャ作業を処理するため、このアプローチはゲーム開発者が簡単に採用できます。
それでも、マルチロールアップ拡張機能のアプローチにはいくつかの問題があります。 最初の問題は、ロールアップネットワークスイッチです。 Metamaskなどの現在のウォレットでは、新しいネットワークであるロールアップインスタンスに接続するために手動の承認が必要です。 これにより、プレイヤーは同じゲームをプレイするために複数の「ネットワーク」に手動で接続する必要があるため、プレイヤーにとって困難で混乱を招くユーザーエクスペリエンスが作成されます。 幸い、この複雑さは、アカウント抽象化(AA)ソリューションで解消できます。 例としては、EIP 4337や、Privyや0xPassなどの埋め込みウォレットなどがあります。
別の課題は、ロールアップ間の遷移中のプレイヤーの状態を管理することです。 容量の低下など、場合によっては、リソースを節約するために、アプリケーションで複数のロールアップ インスタンスを 1 つのインスタンスに統合する必要があります。 この場合、すべてのアクティブなプレイヤーの状態を新しいインスタンスに移行する必要があります。 現在のブリッジングソリューション、特にZKブリッジは、この問題を解決する上で重要な役割を果たすことができます。 これらのソリューションを使用すると、プレイヤーのゲームの状態を新しいロールアップ インスタンスにブリッジしながら、その状態の有効性の証明を維持できます。 ただし、既存のブリッジングソリューションのレイテンシは、ゲームのユースケースには最適ではない場合があります。
ポーカーなどのマルチプレイヤー ゲームにより適した別のアプリケーション ロールアップ拡張機能は、ZK 状態チャネルです。 これらのゲームでは、プレイヤーの相互作用は、2〜10人などの少数のプレイヤー間で発生します。 これらのプレイヤー間のゲームプレイは、ゲームの進行中にのみ重要です。 ただし、ゲームの最終結果は、各プレイヤーの資産残高に影響を与えるため、より重要です。 そのため、結果を共有永続化レイヤーに格納することが重要です。
この場合、アプリケーション ロールアップは、ゲームの結果が保存され、ゲーム アセットも存在する共有情報レイヤーを表します。 ロールアップのゲームごとに、ZK 状態チャネルを開始してゲームを提供できます。 ゲームプレイ中、各プレイヤーはトランザクションを生成してZKPを作成し、ゲームのルールに従ったことを証明します。 他のプレイヤーのインタラクションの証明は、再帰的な証明を使用して前の証明を集約します。 ゲームが終了すると、最終的なZKPがアプリケーションロールアップに送信され、ゲームプレイの有効性と最終結果が証明されます。 ゲームによって生成される状態の変更により、アプリケーション Rollup のプレイヤーの状態が変更されます。
ZK状態チャネルは、ゲームのインタラクションをオフチェーンに移動します。 そのため、ゲーム内のアクティビティとトランザクションは、アプリケーション ロールアップのスループットにはカウントされません。 このアプローチを使用すると、アプリケーション ロールアップは、数千人の同時プレイヤーをサポートするように大規模に拡張できます。 アプリケーション ロールアップのトランザクションは、生成された ZKP トランザクションとステータス更新トランザクションのみを 100 から 1000 倍のスケーリング ファクターで検証します。 Ontropyを含むいくつかのチームがこの技術を開発しています。
このアプローチの欠点の1つは、プレイヤーが自分のデバイスでゲームロジックを実行し、ZKPを生成する必要があることです。 多くの場合、これらの証明は軽量であり、Halo2などの最先端の証明システムで数秒で完了できます。 ただし、これにより、リソースが限られているデバイスのプレーヤーエクスペリエンスが低下する可能性があります。
この問題を軽減する方法の 1 つは、zk 状態チャネル参加者の 1 つを一時的なシーケンサーとして指定することです。 シーケンサーは各プレイヤーのトランザクションを受信し、対応するZKPを生成し、ZKPをすべてのチャンネル参加者と共有します。 この変更は、アプリケーション ロールアップに対する有効期間の短い ZK L3 決済と考えることができます。 カートリッジチームは、Katanaと呼ばれる専用のシーケンサーを設計することで、このアーキテクチャを実装しました。
zkステートチャネルアプローチは大きな可能性を秘めています。 ただし、zk状態チャネル内の実行環境と再帰的証明を最適化する方法に関連するいくつかの未解決の問題があります。 現在のzkEVM環境は効率的ではなく、現在ほとんどが証明再帰をサポートしていません。 代替案には、軽量のzkVMが含まれ、プレーヤーの可能な動きの数が限られている場合は、特殊なzk回路を使用してプレーヤーの相互作用を処理することもできます。
アプリケーション ロールアップを拡張する 3 つ目の方法は、ロールアップの実行環境を変更することです。 EVM開発ツールの成熟度と豊富さにもかかわらず、ゲームなどの高性能アプリケーションには適していません。 さらに、この EVM のシングル・スレッド実行およびストレージ・モデルではスループットが低下しますが、これは改善によって改善できます。
このアプローチの主な利点は、ロールアップのスループットを上げるために、構成可能性を犠牲にしたり、ユース ケースの数を制限したりする必要がないことです。 このアプローチは、実行環境がアプリケーションに必要なスループットを達成できる限り、任意の Web 3 アプリケーションに使用できます。 これにより、AMM、貸付プロトコル、その他のDeFiアプリケーションなど、共有状態へのアクセスを必要とするアプリケーションにとって唯一の実行可能なソリューションになります。
プリコンパイルによる EVM 機能の拡張
まず、ロールアップはEVM準拠を維持し、プリコンパイル済みアドレスのスループットに関するいくつかの制限を通過します。 ここでの考え方は簡単です。 プリコンパイルとは、コンピューティング集中型の EVM 操作をノード レベルに下方に移動することです。 数百または数千のEVMオペコードを必要とし、100,000+ガスを消費する操作は、ガスコストを100倍削減して単一の操作に簡素化できます。 ロールアップ環境を拡張するプリコンパイルは、多くの場合、EVM+ と呼ばれます。 このアプローチの例には、オンチェーンプライバシーのサポートや、BLS署名などのより効率的な署名スキームのサポートが含まれます。 たとえば、zkHoldemポーカーは専用のFHEおよびzk操作を使用して、プライベートカードの取引と提示を可能にします。 これらの特殊なプリコンパイルの開発は、通常、アプリケーションロールアップ開発者と、アプリケーションロールアップインフラストラクチャの展開と保守を管理するRaasプロバイダーとの共同作業です。
EVM以外の実行環境の使用
ロールアップ実行環境を改善する別の方法は、EVMを削除することです。 このアプローチは、イーサリアムエコシステムの新しい開発者や、Solidityが複雑なアプリケーションの開発に最適な言語ではないと考える開発者の間で人気を集めています。
現在、ロールアップアプリケーションはWASM、SVM、カイロ、さらにはLinuxランタイムで実行されています。 これらのメソッドのほとんどは、開発者がRustやCなどの高水準言語を使用してスマートコントラクトを書くことを可能にします。 欠点は、既存のSolidity契約との相互運用性が失われることが多いことです。 ただし、EVMとの互換性は引き続き作成できます。 たとえば、Aributrumのスタイラスはコプロセッサを使用して、スタイラスコントラクトEVMと互換性を持たせます。 この設計により、スタイラスは非EVMよりもEVM+アーキテクチャに近づきます。
混合実行環境
FOGで特に人気のある3番目のアプローチは、最初の2つを組み合わせた最高の機能です。 このアプローチは、EVM互換性と専用の非EVM実行環境を組み合わせたものです。 非EVM環境は、コアゲームプリミティブの高性能実行に重点を置いています。 ゲーム内NFTトランザクションなどのゲーム資産管理は、標準のSolidity契約で処理できます。
このアプローチの利点は、EVMとの互換性により、より大規模な開発者エコシステムや既存の製品との整合性を確保できることです。 また、パーミッションレスのコンポーザビリティも可能です。 開発者は、EVM/Solidityスマートコントラクトを追加することで、ゲームロジックを変更および拡張できます。 同時に、EVM以外の専用ゲーム・エンジンは、EVMでは実現できない高スループットを実現します。
このアプローチの例としては、アーガスのワールドエンジンやキュリオのキーストーンがあります。 World Engine は、ゲーム ロジックの実行を、EVM 互換レイヤーの上で実行されるゲーム シャードと呼ばれる別のレイヤーに分割します。 また、Game Shard は、水平スケーリングで需要に基づいてロールアップの合計スループットを調整できるように設計されています。 同様に、CurioのKeystoneアーキテクチャは、高スループットのゲームエンジンとEVMをロールアップ実行環境としてバンドルしています。 ここでの課題は、EVMエンジンとゲーム・エンジン間のシームレスな相互運用性を実現することです。
前の説明では、アプリケーション ロールアップのスケーリングの主な側面であるロールアップ トランザクションのスループットの向上に重点が置かれました。 このスループットの向上に関連するその他のトピックには、データ可用性(DA)、注文者の分散化、決済速度などがあります。 高スループットのアプリケーション ロールアップの場合、データの可用性はこれらの問題の中で最も差し迫った問題です。
1 つのアプリケーション ロールアップのスループットは、1 秒あたり 10,000 トランザクションを超える可能性があります。 これらのトランザクションのデータ可用性レイヤーとしてイーサリアムを使用することは不可能です。 まず、L2で単純なL2 ETH転送データを公開する平均コストは0.1ドルを超える可能性があります。 これらのコストは、ほとんどのアプリケーション ロールアップには高すぎます。 さらに、イーサリアムのL1は現在、毎秒約8,000トランザクションでデータの可用性のためにL1を利用するロールアップをサポートできません。
アプリケーションのロールアップは、主に外部 DA ソリューションに依存します。 セレスティアとEigenDAは現在、アプリケーションロールアップの最も実行可能なオプションとして位置付けられています。 たとえば、Eclipse は、高スループットの SVM ベースロールアップのデータ可用性レイヤーとして Celestia を使用する予定です。 Argusとハイスループットのゲームエンジンも、最初はCelestiaを使用する予定です。 同様に、EigenDAは毎秒最大10MBのデータスループットを約束し、複数のアプリケーションロールアップに実行可能なソリューションを提供することもできます。
ただし、セレスティアまたはEigneDAを統合することの主な欠点は、経済的価値の漏洩です。 アプリケーションのロールアップでは、DAレイヤーの料金とイーサリアムL1の決済料金を支払う必要があります。 決済手数料は、ロールアップのセキュリティをイーサリアムのセキュリティに結び付けるため、アプリケーションロールアップの鍵となります。 DA保証は、トランザクション値がこれらのネットワークよりもはるかに小さいFOGのコンテキストではそれほど重要ではありません。 さらに、セレスティアとEigenDAは、これらのネットワークが稼働したばかりで、最初は使用率が低くなるため、低料金を約束します。 これらのDAネットワークが高い使用率を達成すると、DA料金も法外なものになる可能性があります。 私の意見では、アプリケーションのロールアップでは、単純なデータ可用性ボード (DAC) を使用して、ロールアップ データの可用性を証明する必要があります。
結論として、アプリケーションロールアップは、高スループットアプリケーション、特に完全にオンチェーンゲームをスケーリングするための最良の既存のソリューションだと思います。 これらのアプリケーションをロールアップで拡張することは、ネイティブの暗号ユーザーを超えて主流の採用を達成するための鍵です。
46k 人気度
49k 人気度
34k 人気度
9k 人気度
2k 人気度
Dappロールアップテクノロジーの解釈:高スループットAPPを主流にする方法は?
によって書かれた モハメド・フーダ 編集 テックフロー
! Dappロールアップテクノロジーの解釈:高スループットAPPを主流にする方法は?
アプリケーションロールアップは、イーサリアムアプリケーションの特定のセットをスケーリングする上で明確な勝者として浮上しています。 これらのアプリケーションは、アクセス許可のない強力な所有権の保証の恩恵を受けますが、すべてのアプリケーション ユーザー間で同時に対話する必要はありません。 完全にオンチェーンのゲームが最良の例です。 オンチェーンゲームは、ゲームアセットの強力な所有権の恩恵を受け、ゲームへの匿名の参加を可能にし、ゲームの匿名の変更を可能にします。 それでも、ほとんどのゲームでは、すべてのプレイヤーが同時に対話する必要はありません。 アプリのロールアップスケーリング戦略の恩恵を受けることができる他のアプリケーションには、NFTマーケットプレイス、永続的な交換、オンチェーンAI推論などがあります。
! Dappロールアップテクノロジーの解釈:高スループットAPPを主流にする方法は?
アプリケーションのロールアップは、これらのユース ケースの多くで既に推奨される実装です。 ただし、標準のロールアップ実装である EVMRollup には、依然として重要なスケーラビリティの制限があります。 毎秒約 100 トランザクションのスループットに達する可能性があります。 このスループットは、ゲームの種類によっては、一部のオンチェーンゲームで十分な場合があります。 ただし、ほとんどのゲームでは、多数の同時プレイヤー (1,000 人以上) をサポートするために、より高いスループットが必要です。 この記事では、数十万人の同時参加者に到達するためにアプリケーション ロールアップを拡張する方法について説明します。 それぞれのアプローチについて、適切な種類のアプリケーション/ゲームとそれが直面する課題について説明します。
水平方向に拡大縮小する
水平方向のスケーラビリティは、アプリケーションのロールアップをスケーリングする最も簡単な方法です。 ただし、この単純さは構成可能性を犠牲にするため、シングルプレイヤーゲームなどのアプリケーションの小さなサブセットにのみ適しています。
水平方向のスケーラビリティとは、単に複数のアプリケーションロールアップ(オプティミスティックまたはZK)をデプロイし、すべてのロールアップに同じスマートコントラクトをデプロイすることを意味します。 アプリケーションのフロントエンドは、容量、場所、または特定のアプリケーション オプションに基づいて、ロールアップの 1 つにユーザーをシームレスに誘導します。 Alt Layerは最近、スケーラブルな2048 FOCGゲームをリリースすることで、このコンセプトを実証しました。 ゲームのフロントエンドでは、ユーザーは地理的な場所に基づいて参加するロールアップを選択できます。 Caldera のようなサービスとしてのロールアップ プロバイダーは、これらのロールアップのスピンと管理に関連するすべてのインフラストラクチャ作業を処理するため、このアプローチはゲーム開発者が簡単に採用できます。
! Dappロールアップテクノロジーの解釈:高スループットAPPを主流にする方法は?
それでも、マルチロールアップ拡張機能のアプローチにはいくつかの問題があります。 最初の問題は、ロールアップネットワークスイッチです。 Metamaskなどの現在のウォレットでは、新しいネットワークであるロールアップインスタンスに接続するために手動の承認が必要です。 これにより、プレイヤーは同じゲームをプレイするために複数の「ネットワーク」に手動で接続する必要があるため、プレイヤーにとって困難で混乱を招くユーザーエクスペリエンスが作成されます。 幸い、この複雑さは、アカウント抽象化(AA)ソリューションで解消できます。 例としては、EIP 4337や、Privyや0xPassなどの埋め込みウォレットなどがあります。
別の課題は、ロールアップ間の遷移中のプレイヤーの状態を管理することです。 容量の低下など、場合によっては、リソースを節約するために、アプリケーションで複数のロールアップ インスタンスを 1 つのインスタンスに統合する必要があります。 この場合、すべてのアクティブなプレイヤーの状態を新しいインスタンスに移行する必要があります。 現在のブリッジングソリューション、特にZKブリッジは、この問題を解決する上で重要な役割を果たすことができます。 これらのソリューションを使用すると、プレイヤーのゲームの状態を新しいロールアップ インスタンスにブリッジしながら、その状態の有効性の証明を維持できます。 ただし、既存のブリッジングソリューションのレイテンシは、ゲームのユースケースには最適ではない場合があります。
ZK ステータスチャンネル
ポーカーなどのマルチプレイヤー ゲームにより適した別のアプリケーション ロールアップ拡張機能は、ZK 状態チャネルです。 これらのゲームでは、プレイヤーの相互作用は、2〜10人などの少数のプレイヤー間で発生します。 これらのプレイヤー間のゲームプレイは、ゲームの進行中にのみ重要です。 ただし、ゲームの最終結果は、各プレイヤーの資産残高に影響を与えるため、より重要です。 そのため、結果を共有永続化レイヤーに格納することが重要です。
この場合、アプリケーション ロールアップは、ゲームの結果が保存され、ゲーム アセットも存在する共有情報レイヤーを表します。 ロールアップのゲームごとに、ZK 状態チャネルを開始してゲームを提供できます。 ゲームプレイ中、各プレイヤーはトランザクションを生成してZKPを作成し、ゲームのルールに従ったことを証明します。 他のプレイヤーのインタラクションの証明は、再帰的な証明を使用して前の証明を集約します。 ゲームが終了すると、最終的なZKPがアプリケーションロールアップに送信され、ゲームプレイの有効性と最終結果が証明されます。 ゲームによって生成される状態の変更により、アプリケーション Rollup のプレイヤーの状態が変更されます。
! Dappロールアップテクノロジーの解釈:高スループットAPPを主流にする方法は?
ZK状態チャネルは、ゲームのインタラクションをオフチェーンに移動します。 そのため、ゲーム内のアクティビティとトランザクションは、アプリケーション ロールアップのスループットにはカウントされません。 このアプローチを使用すると、アプリケーション ロールアップは、数千人の同時プレイヤーをサポートするように大規模に拡張できます。 アプリケーション ロールアップのトランザクションは、生成された ZKP トランザクションとステータス更新トランザクションのみを 100 から 1000 倍のスケーリング ファクターで検証します。 Ontropyを含むいくつかのチームがこの技術を開発しています。
このアプローチの欠点の1つは、プレイヤーが自分のデバイスでゲームロジックを実行し、ZKPを生成する必要があることです。 多くの場合、これらの証明は軽量であり、Halo2などの最先端の証明システムで数秒で完了できます。 ただし、これにより、リソースが限られているデバイスのプレーヤーエクスペリエンスが低下する可能性があります。
この問題を軽減する方法の 1 つは、zk 状態チャネル参加者の 1 つを一時的なシーケンサーとして指定することです。 シーケンサーは各プレイヤーのトランザクションを受信し、対応するZKPを生成し、ZKPをすべてのチャンネル参加者と共有します。 この変更は、アプリケーション ロールアップに対する有効期間の短い ZK L3 決済と考えることができます。 カートリッジチームは、Katanaと呼ばれる専用のシーケンサーを設計することで、このアーキテクチャを実装しました。
zkステートチャネルアプローチは大きな可能性を秘めています。 ただし、zk状態チャネル内の実行環境と再帰的証明を最適化する方法に関連するいくつかの未解決の問題があります。 現在のzkEVM環境は効率的ではなく、現在ほとんどが証明再帰をサポートしていません。 代替案には、軽量のzkVMが含まれ、プレーヤーの可能な動きの数が限られている場合は、特殊なzk回路を使用してプレーヤーの相互作用を処理することもできます。
実行環境を変更する
アプリケーション ロールアップを拡張する 3 つ目の方法は、ロールアップの実行環境を変更することです。 EVM開発ツールの成熟度と豊富さにもかかわらず、ゲームなどの高性能アプリケーションには適していません。 さらに、この EVM のシングル・スレッド実行およびストレージ・モデルではスループットが低下しますが、これは改善によって改善できます。
このアプローチの主な利点は、ロールアップのスループットを上げるために、構成可能性を犠牲にしたり、ユース ケースの数を制限したりする必要がないことです。 このアプローチは、実行環境がアプリケーションに必要なスループットを達成できる限り、任意の Web 3 アプリケーションに使用できます。 これにより、AMM、貸付プロトコル、その他のDeFiアプリケーションなど、共有状態へのアクセスを必要とするアプリケーションにとって唯一の実行可能なソリューションになります。
プリコンパイルによる EVM 機能の拡張
まず、ロールアップはEVM準拠を維持し、プリコンパイル済みアドレスのスループットに関するいくつかの制限を通過します。 ここでの考え方は簡単です。 プリコンパイルとは、コンピューティング集中型の EVM 操作をノード レベルに下方に移動することです。 数百または数千のEVMオペコードを必要とし、100,000+ガスを消費する操作は、ガスコストを100倍削減して単一の操作に簡素化できます。 ロールアップ環境を拡張するプリコンパイルは、多くの場合、EVM+ と呼ばれます。 このアプローチの例には、オンチェーンプライバシーのサポートや、BLS署名などのより効率的な署名スキームのサポートが含まれます。 たとえば、zkHoldemポーカーは専用のFHEおよびzk操作を使用して、プライベートカードの取引と提示を可能にします。 これらの特殊なプリコンパイルの開発は、通常、アプリケーションロールアップ開発者と、アプリケーションロールアップインフラストラクチャの展開と保守を管理するRaasプロバイダーとの共同作業です。
EVM以外の実行環境の使用
ロールアップ実行環境を改善する別の方法は、EVMを削除することです。 このアプローチは、イーサリアムエコシステムの新しい開発者や、Solidityが複雑なアプリケーションの開発に最適な言語ではないと考える開発者の間で人気を集めています。
現在、ロールアップアプリケーションはWASM、SVM、カイロ、さらにはLinuxランタイムで実行されています。 これらのメソッドのほとんどは、開発者がRustやCなどの高水準言語を使用してスマートコントラクトを書くことを可能にします。 欠点は、既存のSolidity契約との相互運用性が失われることが多いことです。 ただし、EVMとの互換性は引き続き作成できます。 たとえば、Aributrumのスタイラスはコプロセッサを使用して、スタイラスコントラクトEVMと互換性を持たせます。 この設計により、スタイラスは非EVMよりもEVM+アーキテクチャに近づきます。
! Dappロールアップテクノロジーの解釈:高スループットAPPを主流にする方法は?
混合実行環境
FOGで特に人気のある3番目のアプローチは、最初の2つを組み合わせた最高の機能です。 このアプローチは、EVM互換性と専用の非EVM実行環境を組み合わせたものです。 非EVM環境は、コアゲームプリミティブの高性能実行に重点を置いています。 ゲーム内NFTトランザクションなどのゲーム資産管理は、標準のSolidity契約で処理できます。
このアプローチの利点は、EVMとの互換性により、より大規模な開発者エコシステムや既存の製品との整合性を確保できることです。 また、パーミッションレスのコンポーザビリティも可能です。 開発者は、EVM/Solidityスマートコントラクトを追加することで、ゲームロジックを変更および拡張できます。 同時に、EVM以外の専用ゲーム・エンジンは、EVMでは実現できない高スループットを実現します。
このアプローチの例としては、アーガスのワールドエンジンやキュリオのキーストーンがあります。 World Engine は、ゲーム ロジックの実行を、EVM 互換レイヤーの上で実行されるゲーム シャードと呼ばれる別のレイヤーに分割します。 また、Game Shard は、水平スケーリングで需要に基づいてロールアップの合計スループットを調整できるように設計されています。 同様に、CurioのKeystoneアーキテクチャは、高スループットのゲームエンジンとEVMをロールアップ実行環境としてバンドルしています。 ここでの課題は、EVMエンジンとゲーム・エンジン間のシームレスな相互運用性を実現することです。
! Dappロールアップテクノロジーの解釈:高スループットAPPを主流にする方法は?
データの可用性に関する考慮事項
前の説明では、アプリケーション ロールアップのスケーリングの主な側面であるロールアップ トランザクションのスループットの向上に重点が置かれました。 このスループットの向上に関連するその他のトピックには、データ可用性(DA)、注文者の分散化、決済速度などがあります。 高スループットのアプリケーション ロールアップの場合、データの可用性はこれらの問題の中で最も差し迫った問題です。
1 つのアプリケーション ロールアップのスループットは、1 秒あたり 10,000 トランザクションを超える可能性があります。 これらのトランザクションのデータ可用性レイヤーとしてイーサリアムを使用することは不可能です。 まず、L2で単純なL2 ETH転送データを公開する平均コストは0.1ドルを超える可能性があります。 これらのコストは、ほとんどのアプリケーション ロールアップには高すぎます。 さらに、イーサリアムのL1は現在、毎秒約8,000トランザクションでデータの可用性のためにL1を利用するロールアップをサポートできません。
アプリケーションのロールアップは、主に外部 DA ソリューションに依存します。 セレスティアとEigenDAは現在、アプリケーションロールアップの最も実行可能なオプションとして位置付けられています。 たとえば、Eclipse は、高スループットの SVM ベースロールアップのデータ可用性レイヤーとして Celestia を使用する予定です。 Argusとハイスループットのゲームエンジンも、最初はCelestiaを使用する予定です。 同様に、EigenDAは毎秒最大10MBのデータスループットを約束し、複数のアプリケーションロールアップに実行可能なソリューションを提供することもできます。
ただし、セレスティアまたはEigneDAを統合することの主な欠点は、経済的価値の漏洩です。 アプリケーションのロールアップでは、DAレイヤーの料金とイーサリアムL1の決済料金を支払う必要があります。 決済手数料は、ロールアップのセキュリティをイーサリアムのセキュリティに結び付けるため、アプリケーションロールアップの鍵となります。 DA保証は、トランザクション値がこれらのネットワークよりもはるかに小さいFOGのコンテキストではそれほど重要ではありません。 さらに、セレスティアとEigenDAは、これらのネットワークが稼働したばかりで、最初は使用率が低くなるため、低料金を約束します。 これらのDAネットワークが高い使用率を達成すると、DA料金も法外なものになる可能性があります。 私の意見では、アプリケーションのロールアップでは、単純なデータ可用性ボード (DAC) を使用して、ロールアップ データの可用性を証明する必要があります。
結論として、アプリケーションロールアップは、高スループットアプリケーション、特に完全にオンチェーンゲームをスケーリングするための最良の既存のソリューションだと思います。 これらのアプリケーションをロールアップで拡張することは、ネイティブの暗号ユーザーを超えて主流の採用を達成するための鍵です。