アプリケーション Rollup 技術詳解：高スループット APP が主流に採用されるための鍵

執筆：Mohamed Fouda

原文タイトル：《アプリケーション Rollup のスケーリング方法》

編纂：深潮 TechFlow

アプリケーション Rollup は、特定のイーサリアムアプリケーションの拡張において明らかな勝者となりつつあります。これらのアプリケーションは、許可不要で強力な所有権保証の恩恵を受けますが、すべてのアプリケーションユーザーが同時に相互作用する必要はありません。完全にオンチェーンのゲームが最良の例です。オンチェーンゲームは、ゲーム資産の強力な所有権の恩恵を受け、匿名でゲームに参加し、匿名でゲームを変更することを可能にします。それにもかかわらず、ほとんどのゲームはすべてのプレイヤーが同時に相互作用する必要はありません。アプリケーション Rollup の拡張戦略の恩恵を受ける他のアプリケーションには、NFTマーケットプレイス、パーペチュアルスワップ、オンチェーンAI推論が含まれます。

アプリケーション Rollup は、これらの多くのユースケースのための優先実装となっています。しかし、標準的な Rollup 実装である EVMRollup には、依然として重要なスケーラビリティの制限があります。彼らは毎秒約 100 トランザクションのスループットに達する可能性があります。特定のオンチェーンゲームにとっては、このスループットは十分かもしれませんが、ゲームの種類によります。しかし、ほとんどのゲームは、1,000 を超える多数の同時プレイヤーをサポートするために、より高いスループットを必要とします。本稿では、数十万の同時参加者をカバーするためのアプリケーション Rollup のスケーリング方法に焦点を当てます。各方法について、適切なアプリケーション/ゲームの種類と直面する課題について議論します。

水平スケーリング

水平スケーラビリティは、アプリケーション Rollup を拡張する最も簡単な方法です。しかし、この単純さは、組み合わせ性を犠牲にすることを意味し、それにより、単一プレイヤーゲームなどの一部のアプリケーションにのみ適しています。

水平スケーリングとは、単に複数のアプリケーション Rollup（Optimistic または ZK）を展開し、すべての Rollup に同じスマートコントラクトを展開することを意味します。アプリケーションのフロントエンドは、容量、位置、または特定のアプリケーションオプションに基づいて、ユーザーをシームレスにいずれかの Rollup に誘導します。Alt Layer は最近、スケーラブルな 2048 FOCG ゲームを立ち上げることでこの概念を実証しました。ゲームのフロントエンドでは、ユーザーは自分の地理的位置に基づいてどの Rollup に参加するかを選択できます。そのシンプルさと、Caldera などの Rollup as a Service プロバイダーの可用性により、これらのプロバイダーは、これらの Rollup の回転と管理に関連するすべてのインフラストラクチャ作業を処理するため、ゲーム開発者がこのアプローチを簡単に採用できます。

それにもかかわらず、マルチ Rollup スケーリングアプローチにはいくつかの問題があります。最初の問題は、Rollup ネットワークの切り替えです。現在のウォレット、例えば Metamask は、新しいネットワーク、つまり Rollup インスタンスへの接続を手動で承認する必要があります。これにより、プレイヤーは同じゲームをプレイするために複数の「ネットワーク」に手動で接続する必要があるため、困難で混乱したユーザー体験をもたらします。幸いなことに、アカウント抽象化（AA）ソリューションを使用してこの複雑さを解消できます。例えば、EIP 4337 や Privy、0xPass のような埋め込みウォレットです。

もう一つの課題は、Rollup 間の移行中にプレイヤーの状態を管理することです。容量が低下するなどの特定の状況では、アプリケーションは複数の Rollup インスタンスを単一のインスタンスに統合する必要があるかもしれません。これにより、すべてのアクティブプレイヤーの状態を新しいインスタンスに移行する必要があります。現在のブリッジソリューション、特に zk ブリッジは、この問題を解決する上で重要な役割を果たすことができます。これらのソリューションを使用すると、プレイヤーのゲーム状態を新しい Rollup インスタンスにブリッジし、その状態の有効性の証明を維持できます。しかし、既存のブリッジソリューションの遅延は、ゲームユースケースには最適ではないかもしれません。

ZK 状態チャネル

もう一つの、特にマルチプレイヤーゲーム（例えばポーカー）に適したアプリケーション Rollup の拡張方法は、ZK 状態チャネルです。これらのゲームでは、プレイヤーの相互作用は少数のプレイヤー間（例えば 2-10 人）で発生します。これらのプレイヤー間のゲームプレイは、ゲームが進行中のときだけ重要です。しかし、ゲームの最終結果はより重要であり、それは各プレイヤーの資産残高に影響を与えます。したがって、結果を共有の永続層に保存することが重要です。

この場合、アプリケーション Rollup は共有情報層を表し、ゲーム結果がここに保存され、ゲーム資産もここに存在します。Rollup 上の各ゲームに対して、そのゲームをサービスするために ZK 状態チャネルを開始できます。ゲームプレイ中、各プレイヤーはトランザクションを生成し、ゲームルールに従ったことを証明する ZKP を作成します。他のプレイヤーの相互作用の証明は、再帰的証明を使用して前の証明を集約します。ゲームが終了すると、最終 ZKP がアプリケーション Rollup に提出され、ゲームプレイと最終結果の有効性を証明します。ゲームによって生成された状態変化は、アプリケーション Rollup 上のプレイヤーの状態を変更します。

ZK 状態チャネルは、ゲームの相互作用をオフチェーンに移動させます。したがって、ゲーム内のアクティビティとトランザクションは、アプリケーション Rollup のスループットにはカウントされません。この方法を使用すると、アプリケーション Rollup は大規模にスケールし、数千の同時プレイヤーをサポートできます。アプリケーション Rollup のトランザクションは、生成された ZKP と状態更新トランザクションの検証だけであり、スケーリングファクターは 100-1000 倍です。Ontropy を含む複数のチームがこの技術の開発に取り組んでいます。

この方法の一つの欠点は、プレイヤーが自分のデバイス上でゲームロジックを実行し、ZKP を生成する必要があることです。通常、これらの証明は軽量であり、Halo2 などの最先端の証明システムを利用することで、証明は数秒で完了することができます。しかし、これでもリソースが限られたデバイスのプレイヤー体験が低下する可能性があります。

この問題を緩和するための一つの修正方法は、zk 状態チャネルの参加者の一人を一時的なオーダラーとして指定することです。このオーダラーは、各プレイヤーのトランザクションを受け取り、対応する ZKP を生成し、すべてのチャネル参加者と ZKP を共有します。この修正は、アプリケーション Rollup に対する決済の一時的な ZK L3 と見なすことができます。Cartridge チームは、Katana と呼ばれる専用のオーダラーを設計することでこのアーキテクチャを実現しました。

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

実行環境の変更

アプリケーション Rollup を拡張する第三の方法は、Rollup の実行環境を変更することです。EVM 開発ツールの成熟と豊富さにもかかわらず、これらはゲームのような高性能アプリケーションには適していません。さらに、EVM のシングルスレッド実行とストレージモデルはスループットの低下を引き起こし、改善によって向上させることができます。

この方法の主な利点は、Rollup のスループットを向上させるために、組み合わせ性を犠牲にしたり、ユースケースの数を制限したりする必要がないことです。実行環境がアプリケーションに必要なスループットを達成できる限り、この方法は任意の Web 3 アプリケーションに使用できます。これにより、共有状態にアクセスする必要があるアプリケーション、例えば AMM、貸付プロトコル、その他の DeFi アプリケーションにとって、唯一の実行可能なソリューションとなります。

EVM 機能をプリコンパイルで拡張する

まず、Rollup は EVM 互換性を維持し、プリコンパイルアドレスを通じてスループットのいくつかの制限を克服します。ここでのアイデアはシンプルです。プリコンパイルは、計算集約型の EVM 操作をノードレベルに下げることです。数百または数千の EVM オペコードを必要とし、10 万以上のガスを消費する操作は、1 つの操作に簡素化され、ガスコストは 100 倍に削減されます。Rollup 環境を拡張するためのプリコンパイルは通常 EVM+ と呼ばれます。この方法の例には、オンチェーンプライバシーのサポートや、BLS 署名のようなより効率的な署名スキームのサポートが含まれます。例えば、zkHoldem ポーカーゲームは、専用の FHE および zk 操作を使用してプライベートなポーカーデッキの配布と表示を実現しています。これらの専用プリコンパイルの開発は、アプリケーション Rollup 開発者とアプリケーション Rollup インフラストラクチャの展開と維持を管理する Raas プロバイダーとの共同作業です。

非 EVM 実行環境の使用

Rollup の実行環境を改善するもう一つの方法は、EVM を排除することです。この方法は、イーサリアムエコシステムの新しい開発者や、Solidity が複雑なアプリケーションを開発するための最良の言語ではないと考える開発者の間でますます人気を集めています。

今日、私たちは WASM、SVM、Cairo、さらには Linux ランタイム上で動作する Rollup アプリケーションを持っています。これらの方法のほとんどは、開発者が高級言語（Rust や C など）を使用してスマートコントラクトを書くことを可能にします。欠点は、既存の Solidity コントラクトとの相互運用性が失われることがよくあります。しかし、EVM との互換性を持つものを作成することは依然として可能です。例えば、Arbitrum の stylus は、コプロセッサを使用して Stylus コントラクトを EVM 互換にしています。この設計により、Stylus は非 EVM よりも EVM+ アーキテクチャに近づきます。

ハイブリッド実行環境

第三の方法は、特に FOG に人気があり、前の二つの方法の最良の特性を組み合わせることです。この方法は、EVM 互換性を専用の非 EVM 実行環境と組み合わせます。非 EVM 環境は、コアゲーム原語の高性能実行に焦点を当てます。ゲーム資産管理、例えばゲーム内 NFT 取引は、標準の Solidity コントラクトによって処理できます。

この方法の利点は、EVM 互換性がより大きな開発者エコシステムおよび既存の製品との整合性を確保することです。また、許可不要の組み合わせ性を可能にします。開発者は、EVM/Solidity スマートコントラクトを追加することで、ゲームロジックを変更および拡張できます。一方で、専用の非 EVM ゲームエンジンは、EVM では満たせない高スループットを実現します。

この方法の例には、Argus の World Engine と Curio の Keystone が含まれます。World Engine は、ゲームロジックの実行を Game Shard と呼ばれる別のレイヤーに分離し、EVM 互換レイヤーの上で動作します。Game Shard は、需要に応じて総 Rollup スループットを調整するために水平スケーリングを許可するように設計されています。同様に、Curio の Keystone アーキテクチャは、高スループットゲームエンジンを EVM と組み合わせて Rollup 実行環境として提供します。ここでの課題は、EVM エンジンとゲームエンジン間のシームレスな相互運用性を実現することです。

データ可用性の考慮事項

前述の議論では、Rollup トランザクションのスループットを増加させることに焦点が当てられており、これはアプリケーション Rollup の拡張の主要な側面です。この増加したスループットに関連する他のトピックには、データ可用性（DA）、オーダラーの分散化、決済速度が含まれます。高スループットのアプリケーション Rollup にとって、データ可用性はこれらの問題の中で最も緊急のものです。

単一のアプリケーション Rollup のスループットは、毎秒 1 万トランザクションを超える可能性があります。これらのトランザクションのデータ可用性層としてイーサリアムを使用することは不可能です。まず、L1 上で単純な L2 ETH 転送データを発行する平均コストは 0.1 ドルを超える可能性があります。これらのコストは、ほとんどのアプリケーション Rollup にとって高すぎます。さらに重要なのは、イーサリアムの L1 は、データ可用性の Rollup を利用するために毎秒約 8 千トランザクションを超えることができません。

アプリケーション Rollup は、主に外部 DA ソリューションに依存します。Celestia と EigenDA は、現在アプリケーション Rollup の最も実行可能な選択肢として位置付けられています。例えば、Eclipse は、Celestia をその高スループット SVM ベースの Rollup のデータ可用性層として使用する計画を立てています。Argus と高スループットゲームエンジンも、最初に Celestia を使用する計画を立てています。同様に、EigenDA が約毎秒 10MB のデータスループットを約束しており、これも複数のアプリケーション Rollup に対する実行可能なソリューションを提供できます。

しかし、Celestia または EigenDA を統合する主な欠点は、経済的価値の漏洩です。アプリケーション Rollup は DA 層に対して料金を支払わなければならず、またイーサリアム L1 上の決済料金も支払わなければなりません。決済料金はアプリケーション Rollup にとって重要です。なぜなら、それは Rollup のセキュリティをイーサリアムのセキュリティと結びつけるからです。DA の保証は、FOG の背景で取引価値がこれらのネットワークのそれよりもはるかに小さい場合にはあまり重要ではありません。さらに、Celestia と EigenDA は、これらのネットワークがまだ立ち上がったばかりで、初期の利用率が非常に低いことから、低料金を約束しています。これらの DA ネットワークが高い利用率を実現すると、DA 料金も過剰になる可能性があります。私の見解では、アプリケーション Rollup は、Rollup データの可用性を証明するためにシンプルなデータ可用性委員会（DAC）を使用すべきです。

要するに、アプリケーション Rollup は、高スループットアプリケーション（特に完全オンチェーンゲーム）を拡張するための最良の既存ソリューションであると考えています。これらのアプリケーション Rollup を拡張することは、ネイティブな暗号ユーザーを超えた主流の採用を実現するための鍵です。