講師: Scott Sunarto (@smsunarto) のモジュラーサミット
記事編集者: Justin Zhao (@hiCaptainZ)
皆さん、こんにちは。本日のサミットにご参加いただきありがとうございます。私は、私たちの昨年の大部分を費やしたプロジェクトについてお話しするためにここにいます。しかし、すぐにわかるように、この物語はこの時間枠を超えて広がっています。
Argus を共同設立する前、私は Ethereum 上で最初の完全なオンチェーンゲームである Dark Forest のクリエイターの一人でした。Dark Forest の発想は、すべてのアクションがオンチェーントランザクションであるゲームを作れるかというシンプルな質問から始まりました。2020 年、これは過激な提案でした。多くの人々が、ブロックチェーン技術の遅さを考慮して、完全なオンチェーンゲームの実現可能性に疑問を呈しました。それにもかかわらず、私たちの好奇心が Dark Forest の開発へと導きました。
Dark Forest は宇宙探査ゲームで、数千人のプレイヤーがオンチェーンで戦い、自分の帝国を拡大しました。ローンチの最初の週で、私たちは 10,000 人以上のプレイヤーと、Ethereum テストネットで数兆のガスを消費しました。この高い活動レベルは、最終的に私たちをテストネットからサイドチェーンへ移行させることを余儀なくさせました。しかし、スケーラビリティを謳われたサイドチェーンでさえも不十分でした。私たちはすぐにブロックスペースを埋め尽くし、ガスコストを押し上げ、サイドチェーンを実質的に使用不可能にしました。
これらの制限にもかかわらず、オンチェーンゲームへの熱意は高いままでした。Dark Forest の後、私たちは投資家、創業者、ビルダー、ハッカーが Dark Forest の遺産を基に構築する急増を目の当たりにしました。Lattice や Primordium のような企業は、オンチェーンゲームの開発を容易にするフレームワークや、完全なオンチェーンゲームを開発しました。また、Starknet の Dojo のように、EVM を超えた他のエコシステムでの開発も見られました。
既存のブロックチェーン技術の制限は、私たちが他のすべての人とチェーンを共有しているという事実から生じています。もし Dark Forest のような別のゲームが同じチェーン上に存在するなら、そのチェーンが効果的に機能することは不可能です。これにより、私たちはオンチェーンゲームの概念を放棄すべきかどうかを疑問視しました。しかし、私たちはより良いオンチェーンゲームを構築する方法を探ることに決めました。
私たちは旅を始めましたが、重要な認識から始まりました：私たちはブロックチェーンアーキテクチャを当然のものと考えていました。L1 や L2 の多様性にもかかわらず、それらはすべて似ているように見えました。すべてが優れたコンセンサスメカニズム、より速い VM、より良い詐欺証明者、より速い ZK 証明者を主張していました。しかし、これらの主張はしばしば裏付けとなるベンチマークを欠いていました。これらのすべての努力は、別の DEX を作成するか、別の NFT をミントすることを目指しており、他のチェーンにデプロイ可能でした。
私たちは異なる視点からブロックチェーンアーキテクチャにアプローチすることに決めました。私たちは、ビットコインやイーサリアムを模倣しているように見える古典的なブロックチェーンアーキテクチャに疑問を呈しました。私たちは、L1 または L2 に関係なく、他のブロックチェーンが特定のユースケースやユーザーペルソナを考慮せずに、すべての人のためのブロックチェーンを構築しようとしていることに気づきました。
私たちは異なる道を選びました。特定のユーザーを念頭に置いた最高のブロックチェーンを構築することに決めました：ゲーム開発者とプレイヤーです。私たちは、ゲームが典型的なアプリケーションとは大きく異なることを理解しました。たとえば、Twitter のようなソーシャルメディアプラットフォームは、ブロックチェーンと同様にイベント駆動型のランタイムで動作します。ユーザーがツイートを投稿するなどのイベントをトリガーすると、状態遷移が発生します。
一方、ゲームはループ駆動型のランタイムで動作します。ユーザーの入力がなくても、状態遷移は続きます。火は燃え続け、水は流れ続け、作物は成長し続け、昼と夜のサイクルは続きます。この根本的な違いは、私たちがゲームのためにより良いブロックチェーンを構築する方法を再考するきっかけとなりました。
ここで理解すべき重要な点は、スマートコントラクトなどの Web アプリケーションにおける状態遷移は、ユーザーの入力を必要としないということです。たとえば、Uniswap では、ユーザーがトークン A をトークン B に交換したい場合、トランザクションを送信し、取引が実行されます。このプロセスはイベント駆動型です。
しかし、私たちはすぐに、従来のブロックチェーンのイベント駆動型の性質がゲーム状態マシンの実行と互換性がないことに気づきました。したがって、私たちはゲームが使用するループ駆動型のランタイムを探求しました。ゲームエンジンは、このループ駆動型のランタイムをサポートするために特別に構築されています。
ループ駆動型のランタイムでは、ゲームの進行は「ティック」と呼ばれ、時間の原子単位です。各ゲームループは単一のティックで実行されます。ティックレートが高いほど、ゲームはより応答性が高く感じられます。たとえば、Counter-Strike や Valorant のような現代のゲームは高いティックレートを持ち、より応答性が高く感じられます。対照的に、ティックレートが低い古いゲームは、しばしば鈍く感じられます。
ブロックチェーンの文脈では、これらのティックはブロックに例えることができ、状態遷移が発生する単一の時間単位です。ティックやブロックが遅く感じられると、ゲーム体験に悪影響を及ぼす可能性があります。
私たちは、ゲームがループ駆動型であると信じています。なぜなら、多くのゲーム状態遷移は外部の入力によってトリガーされないからです。たとえば、ゲーム内の重力はユーザーがボタンを押すことに依存せず、ユーザーの入力に関係なく存在し続けます。
決定論的なトランザクションの順序付けも重要です。たとえば、ユーザーにダメージを与えたい場合、ゲームは最初にユーザーにヘルス再生を適用すべきか、それとも最初にダメージを与えるべきか？従来の順序付けでは、どの状態遷移が最初に適用されるかを予測または制御することができず、ゲームループに問題を引き起こします。
ゲームのためのループ駆動型ブロックチェーンでは、コンポーザビリティを維持します。これが、私たちが最初にゲームのランタイムとしてブロックチェーンを使用したい理由です。このアプローチにより、リアルタイムのゲームプレイが可能になり、ブロックチェーンと従来のゲームサーバーの境界が曖昧になります。また、以前よりも複雑なゲームの開発も可能になります。
しかし、スケーラブルなゲームサーバーブロックチェーンを構築するには、水平スケーラビリティが必要です。ゲームは単一のサーバーでプレイされるのではなく、多くのサーバーに分散されています。ロールアップはコンピュータ上で実行され、物理的な計算制限に縛られています。したがって、トランザクションを制御するための新しい戦略が必要です。
従来のゲームサーバー、特に大規模マルチプレイヤーオンラインゲーム（MMO）のような高性能を必要とするものは、シャーディングの概念を使用します。シャーディングはツールであり、ゲームを構築するための処方箋ではありません。たとえば、位置ベースのシャーディングでは、直交座標を 4 つの図に分割できます。プレイヤーがあるシャードから別のシャードに移動すると、他のシャードにメッセージが送信され、プレイヤーはそこにテレポートされます。
2 つ目のアプローチは、複数のシャーディングという概念の使用です。これは MMO ゲームをプレイしたことがある人には馴染みのある概念です。そのようなゲームでは、ログインするとプレイヤーは選択可能な複数のサーバーが提示されます。これは、異なる状態やゲーム世界が存在し、プレイヤーが参加するものを選択できるという類似の構造です。
ループ駆動型のランタイムと水平スケーラビリティを持つことで、私たちは優れたコンポーザビリティも目指しています。しかし、ロールアップでこれを達成することは現実を超えているように思えるかもしれません。これが、私たちが World Engine を作成した理由です。標準的なロールアップは私たちが望むようには機能しないことに気づいたので、必要なソリューションを構築することにしました。これは、1990 年代に 3D ゲームエンジンが簡単に入手できなかったとき、開発者が自分でそれを構築しなければならなかったのに似ています。
World Engine は 2 つの主要な部分に分かれています。最初はコアで、2 つの重要な要素から構成されています: EVM Bayshore、シャーディングサポートを持つハイブリッド実行レイヤーとシーケンサー、そして Game Shard、高性能なゲームエンジンと実行レイヤーです。これに加えて、トランザクションリレーやクライアント - サーバー通信のためのネットコード、Dark Forest のような ZK ゲームのための ZK Cloud 証明者などの周辺コンポーネントがあります。
World Engine コアは、私たちのシーケンサーを中心に設計されています。他のシーケンサーのように、共有シーケンス再構築が原子的なコンポーザビリティを最適化するのに対し、私たちはゲームの文脈では原子的なコンポーザビリティが過大評価されていると考えています。したがって、私たちは完全に非同期にし、EVM Base Shard のランタイム下でロックの必要性を排除しました。
私たちは、プレイヤーがゲームと組み合わせるためにスマートコントラクトをデプロイできるグローバル EVM チェーンを持っています。私たちは、Polaris の上にこれを構築しました。これは Cosmos SDK 互換の EVM モジュールで、他のソリューションで達成できるよりもはるかに大きな範囲で EVM をカスタマイズできるようにしました。
EVM Base Shard シーケンサーの上で動作するのが Game Shard で、高性能なゲームサーバーとして機能するように設計された高性能なミニブロックチェーンです。Game Shard は、状態マシンと VM に依存しないように設計されています。私たちは、Cosmos SDK EBCI に似た抽象化レイヤーを構築し、シャードを好みに合わせてカスタマイズしたり、標準的なインターフェースセットを実装することで独自のものを構築したりできます。
私たちは、例を提供するために最初のゲームシャード実装も構築しました。私たちは、ゲームエンジンで一般的な機能であるエンティティコンポーネントシステムを使用し、エンティティコンポーネントシステムを第一級市民として優先する構造を持っています。これは、状態マシン自体のすべてのオブジェクトやプリミティブがエンティティのように扱われることを意味します。このシステムには、ゲームの速度をカスタマイズできる構成可能なティックレートもあります。
最良の点は、インデクサーに依存する必要がないことです。最終的な整合性の欠如に対処することなく、ブロックチェーン上で高速な読み取りを行うことができます。さらに、Go でコードを書くことができ、制限のあるスマートコントラクト言語に苦しむ必要がありません。
シャードは、私たちの抽象化レイヤーのおかげで本質的に中立であるため、固体ゲームシャードのような他のシャード構造を構築できます。カスタムルールを持つ NFT ミンティングシャード、NFT を使用してゲームアイデンティティを表現し、ゲームアイデンティティの取引を可能にするゲームアイデンティティシャードを構築することもできます。私たちはロックを使用しないため、メインスレッドをブロックする必要がなく、ゲームシャードのランタイムを可能な限り信頼性の高いものにし、ラグを回避します。もはや暗号経済的構造に依存する必要はありません。
各シャードは異なる DA バッチ圧縮戦略を持つことができます。ゲームプレイのレイテンシを減らすためにシャードを地理的に配置することもできます。また、ゲームシャードを独立したゲームサーバーとして実行できるため、デプロイメントの初日について心配する必要はありません。
私たちは、従来不可能だった Agar.io クローンのようなさまざまなゲームをゲームシャードの上に構築しました。また、既存のゲームエンジンフレームワークをソリディティで使用し、それを World Engine と組み合わせるハイブリッドモデルでも作業しました。未来はあなたが決めるものです。私たちの基本スタックを使用するか、ハイブリッドを行うか、独自のゲームシャードを構築することができます。これは、オンチェーンゲームのための Kubernetes のようなもので、あなたのゲームのためのミックスアンドマッチレゴです。
World Engine は現在、私たちの GitHub でオープンソースとして公開されており、新しい貢献者を歓迎します。最初の World Engine ゲームを構築することに興味がある場合、私たちは今日の後半にワークショップを開催します。明日も、ゲームトラック、パネル、オンチェーンゲームに関するトークを開催します。
結論として、よりクールなロールアップを構築しましょう。私たちは現在、ロールアップのルネッサンスの真っ只中にいます。ロールアップは、ブロックチェーンをスケールさせ、基盤となる L1 のセキュリティにアクセスすることを可能にします。しかし、私たちはまだ非常に EVM 中心のロールアップアーキテクチャの概念に生きています。これは始まりに過ぎず、終わりではありません。私たちは、ユーザーとアプリケーション中心のロールアップ構築を目指しています。ご清聴ありがとうございました。