アプリのロールアップは、イーサリアムの特定のアプリケーションセットをスケーリングする上での明確な勝者として浮上しています。 これらのアプリケーションは、パーミッションレスで強力な所有権の保証の恩恵を受けますが、すべてのアプリケーション ユーザー間で同時に対話する必要はありません。 完全オンチェーンゲーム(FOG)は、この説明に当てはまる最良の例です。 FOGは、強力なゲーム内アセットの所有権、パーミッションレスのゲーム参加、パーミッションレスのゲーム改造の恩恵を受けます。 それでも、ほとんどのゲームでは、すべてのプレイヤーが同時に対話する必要はありません。 アプリのロールアップスケーリング戦略の恩恵を受けることができる他のアプリケーションには、NFTマーケットプレイス、永久取引所、オンチェーンAI推論などがあります。

アプリのロールアップは、これらのユースケースの多くですでに頼りになる実装です。 ただし、標準のロールアップ実装、つまりEVMロールアップには、依然として重要なスケーラビリティの制限があります。 おそらく、毎秒約 100 トランザクションのスループットを達成できます。 このようなスループットは、ゲーム の種類によっては、一部のオンチェーンゲームでは十分です。 ただし、ほとんどのゲームでは、多数の同時プレイヤー (> 1000 人) をサポートするには、はるかに高いスループットが必要です。 この記事では、アプリのロールアップをスケーリングして数十万人の同時参加者にリーチするアプローチに焦点を当てます。 それぞれのアプローチについて、適切なアプリケーション/ゲームの種類と、それが直面している課題について説明します。

アプリのロールアップを使用しているビルダー、またはアプリのロールアップをスケーリングするためのインフラストラクチャを構築しているビルダーは、 私 に連絡して アライアンスに申し込むことをお勧めします。 私は、これらの分野で構築している創業者と一緒に働くことを楽しみにしています。

水平スケーリング

水平方向のスケーラビリティは、アプリのロールアップをスケーリングする最も簡単なアプローチです。 ただし、シンプルさはコンポーザビリティを失うという代償を払っているため、シングルプレイヤーゲームなどの少数のアプリケーションにのみ適しています。

水平方向のスケーラビリティとは、すべてのロールアップにデプロイされた同じスマートコントラクトを使用して、複数のアプリケーションロールアップ(OPまたはZK)をデプロイすることを意味します。 アプリケーションのフロントエンドは、容量、場所、または特定のアプリケーションオプションに応じて、ロールアップの1つにユーザーをシームレスに誘導します。 Alt Layer は最近、スケーラブルな2048 FOCGを発売することで、このコンセプトを実証しました。 ゲームのフロントエンドでは、ユーザーは地理的な場所に基づいて参加するロールアップを選択できます。 Caldera のような Rollup-as-a-Service プロバイダーは、これらのロールアップのスピンと管理に関連するすべてのインフラストラクチャ作業を処理するシンプルさと可用性を備えているため、このアプローチはゲーム開発者に簡単に採用できます。

シンプルであるにもかかわらず、マルチロールアップスケーリングのアプローチにはいくつかの問題があります。 1 つ目は、ロールアップ ネットワークの切り替えです。 Metamaskなどの現在のウォレットでは、新しいネットワーク(ロールアップインスタンス)に接続するには手動承認が必要です。 これにより、同じゲームをプレイするために複数の「ネットワーク」に手動で接続する必要があるプレーヤーにとって、困難で混乱したユーザーエクスペリエンスが発生します。 幸いなことに、 AAソリューションでこの複雑さを抽象化 することは可能です。 つまり、EIP 4337、 およびPrivy や 0xPassなどの組み込みウォレットです。

もう 1 つの課題は、ロールアップ間の移行中のプレイヤーの状態の管理です。 容量の減少など、場合によっては、リソースを節約するために、アプリケーションで複数のロールアップ インスタンスを 1 つのインスタンスに統合する必要があります。 このような場合は、アクティブなプレイヤーのすべての状態を新しいインスタンスに移行する必要があります。 現在のブリッジングソリューション、特にzkブリッジは、この問題を解決する上で非常に重要です。 これらのソリューションを使用すると、プレイヤーのゲーム状態を新しいロールアップ インスタンスにブリッジしながら、この状態の有効性の証明を維持することができます。 ただし、既存のブリッジングソリューションのレイテンシーは、ゲームのユースケースには最適ではない可能性があります。

ZK ステート チャネル

ポーカーなどのマルチプレイヤーゲームにより適した別のアプリロールアップスケーリングアプローチは、zkステートチャネルです。 これらのゲームでは、プレイヤーのインタラクションは少数のプレイヤー(例:2〜10)で行われます。 これらのプレイヤー間のゲームプレイは、ゲームが進行している間のみ重要です。 ただし、ゲームの最終結果は、各プレイヤーの資産残高に影響を与えるため、より重要です。 したがって、結果を共有永続レイヤーに格納することが重要です。

この場合、アプリのロールアップは、ゲームの結果が格納され、ゲーム アセットが存在する共有情報レイヤーを表します。 ロールアップのゲームごとに、ZK State Channel を開始してこのゲームを提供できます。 ゲームプレイ中、各プレイヤーはトランザクションを生成し、ゲームのルールに従ったことを証明するZKPを作成します。 他のプレイヤーとのインタラクションからの証明は、再帰的な証明を使用して以前の証明を集約します。 ゲームが終了すると、最終的な ZKP がアプリのロールアップに送信され、ゲームプレイの有効性と最終結果の有効性が証明されます。 ゲームから得られる状態の変化は、アプリのロールアップ上のプレイヤーの状態を変更します。

ZKステートチャンネルは、ゲームのインタラクションをオフチェーンに移動します。 そのため、ゲーム内のアクティビティとトランザクションは、アプリのロールアップのスループットにはカウントされません。 このアプローチを使用すると、アプリのロールアップを大規模にスケーリングして、数万または数十万の同時プレイヤーをサポートできます。 アプリのロールアップ トランザクションは、生成された ZKP と状態更新トランザクションの検証のみであり、スケーリング ファクターは 100 から 1000 倍になります。 Ontropyを含む複数のチームが、この技術の開発に注力しています。

このアプローチの欠点は、プレイヤーがゲームロジックを実行し、デバイス上でZKPを生成する必要があることです。 多くの場合、これらの証明は軽量であり、Halo2 などの最先端の証明システムを活用することで、証明に数秒もかかりません。 ただし、これにより、リソースが限られているデバイスを使用するプレイヤーのUXが低下する可能性があります。

この問題を軽減できるこのアプローチの修正は、zk 状態チャネル参加者の 1 つを一時的なシーケンサーとして割り当てることです。 このシーケンサーは、各プレイヤーのトランザクションを受信し、対応するZKPを生成し、ZKPをすべてのチャネル参加者と共有します。 この変更は、アプリのロールアップに落ち着く一時的な ZK L3 と考えることができます。 Cartridge チームは、Katana と呼ばれる特殊なシーケンサーを設計することで、このアーキテクチャを実装してきました。

zk状態チャネルアプローチは多くの可能性を秘めています。 ただし、zk 状態チャネル内の実行環境と、証明再帰のために最適化する方法に関連するいくつかの未解決の問題があります。 現在のzkEVM環境はあまり効率的ではなく、現在、ほとんどの環境は証明再帰をサポートしていません。 代替案には、軽量のzkVMや、プレイヤーが実行できるアクションの数が限られている場合は、プレイヤーのインタラクションに専用のzk回路を使用することが含まれます。

実行環境の変更

アプリのロールアップのスケーラビリティの 3 つ目のアプローチは、ロールアップの実行環境を変更することです。 EVM開発ツールは成熟度が高く、豊富ですが、ゲームなどの高性能アプリケーションには適していません。 さらに、EVM のシングルスレッド実行およびストレージ・モデルでは、スループットが低下しますが、これは改善の余地があります。

このアプローチの主な利点は、ロールアップスループットを向上させるために、コンポーザビリティを犠牲にしたり、ユースケースの数を制限したりする必要がないことです。 このアプローチは、実行環境がアプリケーションに必要なスループットを達成できる限り、あらゆるWeb3アプリケーションで機能します。 これにより、AMM、レンディングプロトコル、その他のDeFiアプリケーションなど、共有状態にアクセスする必要があるアプリケーションにとって唯一の実行可能なソリューションになります。

プリコンパイルによる EVM 機能の拡張

第 1 のアプローチは、ロールアップが EVM との互換性を維持し、プリコンパイルによってスループットの制限の一部に対処することです。 ここでの考え方は単純です。 プリコンパイルとは、計算コストの高いEVM操作をノードレベルに下げることです。 数百または数千のEVM OPを必要とし、100k+のガスを消費する動作を、1回の動作に簡素化し、ガスコストを100倍削減できます。 プリコンパイルによるロールアップ環境の拡張は、EVM+ と呼ばれることがよくあります。 このアプローチの例としては、オンチェーンプライバシーのサポートや、BLS署名などのより効率的な署名スキームのサポートなどがあります。 例えば、 zkHoldem ポーカーゲームでは、特殊なFHEとzkのオペレーションを使用して、プライベートポーカーカードのディーリングと公開を実現しています。 これらの特殊なプリコンパイルの開発は、多くの場合、アプリ ロールアップ開発者と、アプリ ロールアップ インフラストラクチャのデプロイとメンテナンスを管理する Raas プロバイダーの間で共有作業が行われます。

非EVM実行環境の使用

ロールアップ実行環境を改善する別のアプローチは、EVMから脱却することです。 このアプローチは、イーサリアムのエコシステムに不慣れな開発者や、Solidityは複雑なアプリケーションを開発するのに最適な言語ではないと考える開発者の間で人気が高まっています。

現在、WASM、SVM、Cairo、さらにはLinuxランタイムで実行されているロールアップアプリケーションがあります。 これらのアプローチのほとんどは、開発者がRustやCなどの高級言語でスマートコントラクトを書くことを可能にします。欠点は、既存のSolidity契約との相互運用性が失われることが多いことです。 ただし、EVM との互換性を確保することは可能です。 たとえば、Aributrum のスタイラスは、Stylus コントラクトを EVM と互換性を持たせるためにコプロセッサを採用しています。 この設計により、Stylus は非 EVM よりも EVM+ アーキテクチャに近づきます。

ハイブリッド実行環境

FOGで特に人気のある3つ目のアプローチは、前の2つのアプローチの最良の機能を組み合わせることです。 このアプローチは、EVMとの互換性と特殊な非EVM実行環境を組み合わせたものです。 非EVM環境は、コア・ゲーム・プリミティブの高性能な実行に重点が置かれています。 ゲーム内のNFTの取引などのゲーム内資産管理は、標準のSolidityコントラクトで処理できます。

このアプローチの利点は、EVMの互換性により、開発者や既存製品のより大きなエコシステムとの整合性が確保されることです。 また、パーミッションレスなコンポーザビリティも可能になります。 開発者は、EVM/Solidityスマートコントラクトを追加することで、ゲームロジックを変更および拡張できます。 一方、EVMに特化した非EVMゲームエンジンは、EVMでは満足できない高いスループットを実現します。

このアプローチの例としては、Argus の World Engine や Curio の Keystone があります。 ワールドエンジンは、ゲームロジックの実行を、EVM互換レイヤーの上で動作するゲームシャードと呼ばれる別のレイヤーに分離します。 また、ゲームシャードは、水平スケーリングで需要に応じて合計ロールアップスループットを調整できるように設計されています。 同様に、Curio の Keystone アーキテクチャは、ロールアップ実行環境として EVM を備えた高スループットのゲームエンジンをバンドルしています。 ここでの課題は、EVMエンジンとゲームエンジン間のシームレスな相互運用性を実現することです。

データの可用性に関する考慮事項

前回の説明では、アプリのロールアップのスケーリングの主な側面である、ロールアップ トランザクションのスループットの向上に重点が置かれました。 このスループットの向上には、データの可用性(DA)、シーケンサーの分散化、決済速度など、他にも関連するトピックがあります。 データの可用性は、高スループットのアプリ ロールアップにとって、これらの問題の中で最も差し迫った問題です。

1 つのアプリのロールアップで、10k tps を超えるスループットを達成できる可能性があります。 これらのトランザクションのDAレイヤーとしてイーサリアムを使用することは不可能です。 まず、L1での単純なL2 ETH送金のデータを公開する平均コストは、0.10ドルを超える可能性があります。 これらのコストは、ほとんどのアプリのロールアップには高すぎます。 さらに重要なことに、イーサリアムのL1は現在、DAにL1を使用するロールアップで約8k TPS [1] 以上をサポートできません。

アプリのロールアップは、主に外部の DA ソリューションに依存します。 CelestiaとEigenDAは、現在、アプリのロールアップの最も実行可能なオプションとして位置付けられています。 たとえば、Eclipseは、高スループットのSVMベースのロールアップにCelestiaを使用する予定です。 Argusとハイスループットのゲームエンジンも、当初はCelestiaを使用する予定です。 同様に、最大10MB/秒のデータスループットを約束するEigenDAは、複数のアプリのロールアップに対して実行可能なソリューションになる可能性があります。

しかし、CelestiaやEigneDAを統合すると、経済的価値が漏れるという大きな欠点があります。 アプリのロールアップは、イーサリアムL1の決済手数料に加えて、DAレイヤーの手数料を支払う必要があります。 決済手数料は、ロールアップのセキュリティをイーサリアムのセキュリティに合わせるため、アプリのロールアップにとって重要です。 DA保証は、特にトランザクション値がはるかに小さいFOGのコンテキストでは、それほど重要ではありません。 さらに、CelestiaとEigenDAは、これらのネットワークが新しく、最初は使用率が低いため、低料金を約束します。 これらのDAネットワークが高い使用率を達成すると、DA料金も過大になる可能性があります。 私の意見では、アプリのロールアップは、代わりに単純なデータ可用性委員会(DAC)を使用して、ロールアップデータの可用性を証明する必要があります[3] 。

結論として、アプリのロールアップは、高スループットのアプリケーションを一般的に、特に完全にオンチェーンのゲームに拡張するための最良の既存のソリューションであると信じています。 これらのアプリロールアップのスケーリングは、ネイティブの暗号ユーザーを超えた主流の採用を実現するための鍵です。 アライアンスでは、このビジョンを構築する創業者を支援することで、このビジョンを実現したいと考えています

この記事に関する貴重なフィードバックをくださった Matt Katz、 Kevin Zhang、 Tarrence van As、 Larry Liu に感謝します。

[1] イーサリアムのブロックガス制限の50%は、平均txサイズ10バイトのcalldataを使用してデータを保存するためだけに行われると仮定しています。 12秒のブロック時間

免責事項：

1. この記事は[Alliance]からの転載です。 すべての著作権は原作者[Mohamed Fouda]に帰属します。 この転載に異議がある場合は、 Gate Learn チームに連絡していただければ、迅速に対応いたします。
2. 免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
3. 記事の他言語への翻訳は、Gate Learnチームによって行われます。 特に明記されていない限り、翻訳された記事を複製、配布、盗用することは禁止されています。