全チェーンゲームのコア分析：MUDエンジンとWorld Engine
TechFlow厳選深潮セレクト
全チェーンゲームのコア分析：MUDエンジンとWorld Engine
インフラの整備が進むにつれて、さまざまな複雑なアイデアの構築と実現がMUDを通じて行われ、より高度なRollupスキーム上で相互に融合・連携していくだろう。ブロックチェーンの新しいパラダイムは、全チェーンゲームから始まる可能性がある。
Web3業界の深掘り報道に専念し潮流を洞察著者: Solaire, YBB Capital
過去、ブロックチェーンのリンクリスト構造という制約により、オンチェーンで実用的なDAppを構築することは簡単ではなかった。しかし、そのような制限がある中でも探求者は前進を止めることなく、「x * y = k」という有名な定数積プール式が世に登場したことで、たった数百行のコードで構成されるUniswapがDeFiを牽引し、Cryptoのナラティブを根本から変えてしまった。シンプルなDAppですら開発者の工夫次第でここまで到達できるのであれば、より複雑なアプリケーションはどうだろうか？たとえばゲームやソーシャルプラットフォームを完全にオンチェーンに構築することなどは、かつては狂気じみた考えに思えたかもしれないが、Rollupsによってスケーラビリティが開かれた今日、その可能性は現実味を帯び始めている。
DeFiはCryptoにもたらしたTVL（総価値供託額）は数千億ドルに達した。それよりもさらに複雑性が高いDAppはどのようにして実現されうるのか？そしてそれはCryptoを再び新たな高みへと導くことができるのだろうか？おそらく、まだ発展初期にある全チェーンゲームがその答えを与えてくれるかもしれない。本稿では、全チェーンゲームの歴史、現在の定義、創造・運営の仕組み、およびCryptoの未来における意義という四つの観点から、全チェーンゲームについて分析を行う。
全チェーンゲームの起源と発展
全チェーンゲームの歴史は10年前に遡る。Mikhail SindeyevはNamecoinをフォークし、世界初のブロックチェーンゲーム『Huntercoin』を構築した。『Huntercoin』は2013年に実験的プロトタイプとして始まり、すぐにオンライン上で熱狂的な支持者層を獲得し、bitcointalk.orgの多くの著名メンバーからも支援を受けた。技術愛好家たちがビデオゲームに抱く情熱により、最も人気のあるHuntercoinの掲示板は38万回以上閲覧された。しかしあれから不幸にも、Mikhail Sindeyevは2014年2月に脳卒中で亡くなり、『Huntercoin』の開発は頓挫、トークンHUCは2015年にはほぼ価値を失った。全チェーンゲームの最初の試みは成功しなかったものの、幸いなことに物語はここで終わらなかった。
2020年、Gubsheep（Brian Gu）、Alan Luo、SCOTT SUNARTOは小説『三体：ダーク・フォレスト』にインスピレーションを得て、同名のMMORTS宇宙征服ゲーム『Dark Forest』を開発した。このゲームはイーサリアム上に構築され、すべてのルールやロジックがスマートコントラクトに記述されており、すべてのアクションがオンチェーン取引となる全チェーンゲームである。また、ゲームの核となる部分ではZK-Snarks（ゼロ知識証明）技術を用いて「戦争の霧」を実装し、『三体』小説中の「ダーク・フォレスト理論」（ある宇宙文明が発見されれば、他文明から攻撃を受ける必然性がある）を再現している。
例えばプレイヤーが行動を起こす際、ダーク・フォレスト理論の影響で自らの座標を露呈せず、A惑星からB惑星へ移動する必要があるとする。このとき、AとBの座標が有効であることを証明するために情報を提出しなければならないが、イーサリアムのブロック情報は完全に透明であるため、『Dark Forest』は以下のような方法で情報隠蔽を実現している。まずプレイヤーは出発惑星と目的惑星を選択するが、これらの位置情報はプライベートデータである。次に、これら二つの惑星の位置のハッシュ値を計算し、そのハッシュ値をブロックチェーンに提出する。この段階がコミット段階（Commit Phase）であり、ハッシュ関数の一方向性により、提出されたハッシュ値から実際にどの惑星にいるかを特定することはできない。その後の公開段階（Reveal Phase）では、プレイヤーは自身の行動が有効であることを証明するゼロ知識証明を生成・提出する。この証明は誰でも検証可能だが、プレイヤーの惑星位置に関する情報は一切漏れない。
こうして、情報が完全にオープンなイーサリアム上で情報を隠蔽する初の全チェーンゲームが誕生した。この狂気じみたほど独創的な実験は、Cryptoコミュニティ全体に大きな衝撃を与え、イーサリアム創設者VitalikですらTwitterで直接リツイートし、称賛している。
しかし、『Dark Forest』はリリース直後、1万人以上のプレイヤーが殺到したことで限界を迎える。イーサリアムのパフォーマンスでは、このような複雑なアプリケーションを支えることは不可能だった。ゲームのローンチ当日、ブロックチェーン全体が詰まり、何兆Gasものコストが発生した。また、ゲームはDeFiアプリケーション用のライブラリとアーキテクチャに基づいて設計されていたため、後の最適化も一時的な緩和に留まり、根本的な解決にはならなかった。
この実験を通じて得られたZK-Snarksの将来性への着想と、全チェーンゲームの課題に対する考察を踏まえ、開発者の一人であるBrian Guは、ゼロ知識証明の研究機関0xPARCを設立し、ZK技術の発展を推進した。また、0xPARC傘下の別組織Latticeは、全チェーンゲームエンジン「MUD」の設計と保守を担当。もう一人の共同創業者SCOTT SUNARTOは、全チェーンゲーム専用のシャーディングRollupフレームワーク「World Engine」の開発に着手した。
今日、ゼロ知識証明は広く知られ、活用され始めているが、ここからは主に後者の二つ、すなわち「MUDエンジン」と「World Engine」、つまり「創造」と「運営」について議論していく。ただし、その前に0xPARCが提唱する全チェーンゲームの定義と新たな認識方法を理解しておく必要がある。
Autonomous Worlds（自律的世界）
0xPARCの暗号ゲーム論文集『Autonomous Worlds』の見解によれば、全チェーンゲームは少なくとも以下の五つの基準を満たさなければならない：
-
データがブロックチェーン由来であること：ブロックチェーンは単なる補助的データストレージではなく、「専用サーバー上のデータのミラー」としても機能しない。意味のあるすべてのデータがブロックチェーン上でアクセス可能でなければならない。これにより、ゲームはプログラマブルなブロックチェーンの利点（透明なデータ保存、無許可での相互運用性）を最大限に活用できる；
-
ロジックとルールがスマートコントラクトで実装されていること：たとえばゲーム内の戦闘処理など、所有権以外の処理もオンチェーンで行われること；
-
ゲーム開発がオープンエコシステム原則に従うこと：ゲームのコントラクトとクライアントがすべてオープンソースであること。第三者の開発者はプラグイン、サードパーティクライアント、相互運用可能なスマートコントラクトなどを通じて、完全に再展開・カスタマイズ・フォークすることが可能。これにより、開発者は（インセンティブが一致した）コミュニティ全体の創造的成果を活用できる；
-
ゲームが永久にオンチェーンに存在すること：これは上記三点と密接に関連しており、暗号ネイティブなゲームかどうかの試金石となる。もし明日、コア開発者が提供するクライアントが消滅しても、ゲームは遊べるか？その答えが「はい」になるのは、（そして唯一）データストレージが無許可であり、ロジックの実行が無許可で可能であり、コミュニティがコアチームのインターフェースに依存せずにコアスマートコントラクトとやり取りできる場合のみである；
-
ゲームが我々が価値を持つと考えるものと相互に作用できること：ブロックチェーンは価値概念自体にネイティブなAPIを提供しており、デジタル資産はデフォルトで他の重要な資産と相互運用可能。これはゲームの深さと意義を反映するだけでなく、それを高め、ゲーム世界を「現実」の世界と結びつける。
このような基準に基づいて構築された全チェーンゲームは、ブロックチェーンを基盤とする世界、いわゆるAutonomous Worlds（自律的世界）と見なすことができる。
では、「世界」とは何だろうか？世界とは現実世界だけを指すわけではない。その媒体は小説、映画、ゲーム、詩、あるいは法体系にもなりうる。しかし、いずれの世界も、中央（作者、開発者、または集団）が枠組みとルールを定めて私たちに伝える形で成立している。これらの世界における自律性の度合いはさまざまである。たとえば、オープンワールドゲームの代表作『Minecraft（マインクラフト）』では、プレイヤーは非常に高い自律性を持ち、さまざまなブロックを組み合わせたりルールを変更したりすることで、自分だけの世界を創造できる。一方、自律性の低い例としては小説世界があり、**『Harry・Potter』の魔法世界は、JKローリングが作り出したルールと枠組みに完全に依存している。
ブロックチェーンを世界の基盤とすれば、ブロックチェーンはその状態に含まれるすべてのノードエンティティの集合を曖昧なく保持する。さらに、コンピュータコードによってルールを正式に定義する。ブロックチェーンを基盤とする世界では、住民が合意形成に参加できる。コンピュータネットワークを稼働させ、新しいエンティティが追加されるたびに合意が形成される。
世界の視点から、次の二つのブロックチェーン概念を定義しておく必要がある：
-
ブロックチェーン状態ルート：状態ルートは世界内のすべてのエンティティを圧縮したもの。この状態ルートがあれば、任意のエンティティが架空のものかどうかを判断できる。ある世界の状態ルートを信じることは、その世界そのものを信じることに等しい。0x411842e02a67ab1ab6d3722949263f06bca-20c62e03a99812bcd15dce6daf26e は、2022年7月21日07:30:10PM UTC時点のイーサリアム――すなわちブロックチェーン基盤を持つ世界の状態ルートである。この状態ルートの計算には、イーサリアム世界のすべてのエンティティが考慮されており、当該時間におけるその世界の全内容を表している；
-
ブロックチェーン状態遷移関数：すべてのブロックチェーンは状態遷移関数を定義している。これは明確な導入ルールと見なせるもので、「世界」の前の状態――仮想エンティティの集合――が、人間やマシンの入力を通じて新しい仮想エンティティをいかに導入するかを定義している。ビットコインの場合、状態遷移関数は残高がアドレス間で消費・移転される方法を定義している。
このように、全チェーンゲームをブロックチェーンを基盤とする世界と捉えれば、この非中央集権的な世界は無限の自律性を持つ。これを「自律的世界（Autonomous World）」と呼ぶこともできる。
創造の苦境
全チェーンゲームの初期設計において、開発者は繰り返し、伝統的なDAppアーキテクチャやDeFiアプリ構築用ライブラリの制約に悩まされた。『Dark Forest』をはじめとする初期の全チェーンゲームは、当時のDeFiアプリ用アーキテクチャとライブラリをやむなく採用せざるを得ず、それが全チェーンゲーム構築の事実上の標準となってしまった。
初期の全チェーンゲーム開発パターンは以下の四点に要約できる：
-
異なるコントラクトが同じ状態にアクセスする場合：複数のスマートコントラクトが同一のデータや状態を変更しようとした場合、データ不整合などの問題が生じる可能性がある。これを回避するためにDiamond Pattern（ダイヤモンドパターン）が使われることもある（Solidityにおける多重継承問題の解決手法）；
-
多様なデータ構造の作成：各エンティティ（ゲーム内の兵士、惑星など）ごとに独自のデータ構造と型を定義する；
-
Getter関数の作成：データ構造から一括して要素を取得する関数。オンチェーンから初期状態やデータを取得するために使用される。例えばgetPlanets()関数はすべての惑星リストを返す；
-
イベントの利用：各データ構造にはイベントが含まれており、これはスマートコントラクトの特定機能で、新しいブロックがチェーンに追加されたときにアプリの状態を同期・更新できる。たとえば新しい惑星が作成されるとイベントがトリガーされ、アプリ側がそれを監視して表示中の惑星リストを更新する。
このようなパターンで全チェーンゲームを構築するのは極めて困難であり、いくら最適化しても、真の汎用エンジンを使った開発とは程遠い。
世界の創造者――MUDエンジン
MUDエンジンの誕生は、開発者たちによる過去および現在の問題への深い考察から生まれた。MUDは複雑なアプリケーションをイーサリアム上で構築するためのフレームワークであり、データとロジックの整理に関する規約を提供し、低レベルの複雑性を抽象化することで、開発者がアプリ機能に集中できるようにする。また、オンチェーンデータの保存方式を標準化しており、この標準データモデルにより、MUDはコントラクトとクライアントの状態を同期するためのすべてのネットワークコードを提供できる。
最新版のMUDは以下の五つのコンポーネントを備えている：
-
Store：オンチェーンデータベース；
-
World：標準化されたアクセス制御、アップグレード、モジュールを提供するエントリーポイントフレームワーク；
-
tools：Foundryに基づく超高速開発ツール；
-
クライアントデータストレージ：オンチェーン状態を自動的に反映する；
-
MODE：SQLでクエリ可能なPostgresデータベース。
EVM完全互換性と極めて高い自由度
MUDの汎用性はイーサリアムメインネットにとどまらず、言語サポートがあれば、Polygon、Arbitrum、Optimism、Gnosis Chainなど、あらゆるEVM互換チェーンでシームレスに動作する。
さらに、MUDはAutonomous Worlds（自律的世界）およびオンチェーンゲームコミュニティで好まれるフレームワークであるが、その用途はそれだけに限らない。また、MUDは非常に高い自由度を提供しており、特定のデータモデルに縛られない。簡単に言えば、Solidityのマッピングや配列で実現可能なすべての機能は、MUDでも容易に実装できる。データ可用性の面でも、メインネットやRollupsに展開されたMUDアプリは、ENSやUniswapといった従来のイーサリアムアプリケーションと同等の性能を発揮する。
核心思想
MUDは、オンチェーンの複雑なアプリケーション向けに設計された高度に協調されたライブラリとツールのセットであり、その中心思想は以下の三点に集約される：
-
すべてのオンチェーン状態はMUDのオンチェーンデータベースStoreに保存される：StoreはSQLiteのような埋め込み型EVMデータベースで、テーブル、カラム、行の概念を持つ。Storeを使うことでデータをより構造化して管理でき、Solidityコンパイラが提供するストレージメソッドに依存する必要がなくなる。また、実行時にテーブルを作成でき、インデックスビューを自動生成するフックを登録できるため、柔軟性が高まる；
-
ロジックはステートレスであり、カスタム権限によって異なるコントラクト間で分割される：「World」はエントリーポイントとして機能し、異なるスマートコントラクトが「Store」にアクセスするのを調整する。ある「World」がデプロイされると同時に「Store」が作成され、Store内の各テーブルは特定の名前空間に登録される。機能（たとえばアドレス間の送金ロジック）が「World」に追加されるときも、名前空間に登録され、「システム」と呼ばれる。これらの「システム」は実態はスマートコントラクトだが、従来のものと異なりステートレスであり、データを直接保持しない。代わりに「World Store」を使ってデータの読み書きを行う。この設計により、同じチェーン上にあれば、異なる「World」間で「システム」を再利用できる；
-
インデクサーまたはサブグラフが不要。フロントエンドでも同期可能：Store（および拡張されたWorld）を使用すると、オンチェーンデータが自動的に内省（Introspection）され、すべての変更が標準イベントを通じてブロードキャストされる。「MODE」ノードを通じて、オンチェーン状態がリアルタイムでSQLデータベースに変換され、常に最新の状態を保つ（ミリ秒レベルの遅延）。さらに、MUDはMUD QDSLやGraphQLなどのクエリツールを提供し、フロントエンドの同期を簡素化している。React開発者向けには専用のHooksも提供されており、コンポーネントの状態を自動的にバインド・更新できる。
枷からの脱却
上記の三つの核心思想をもとに、過去の課題を振り返り、MUDがいかに複雑アプリケーションの枷を打ち破ったかを見てみよう。
-
異なるコントラクトが同じ状態にアクセスする場合：「World」と「Store」の構造を用いてオンチェーン状態を集中管理する。すべてのスマートコントラクト（MUDでは「システム」と呼ぶ）は「World」を通じて「Store」のデータにアクセス・変更を行う。これにより、すべての状態変更が一元的なエントリーポイントを経由するため、データ不整合や競合のリスクが低減される。名前空間とパスにより、データへの細粒度なアクセス制御が可能となり、異なる「システム」に異なる権限を設定できるため、特定のデータや状態を変更できるのは許可された「システム」だけとなる；
-
データ構造：従来のSolidityストレージ方式とは異なり、MUDの「Store」はSQLite風のテーブル、カラム、行の概念を提供するため、データをより構造化して保存・管理できる。各エンティティ（兵士、惑星など）ごとに個別のテーブルを持ち、それぞれの属性を複数のカラムで保存できる；
-
Getter関数：MUDの「Store」は構造化されたデータストレージを提供するため、データ取得がよりシンプルかつ直感的になる。開発者はSQL風のクエリ言語を使ってデータを取得でき、専用のgetter関数を書く必要はない。たとえばすべての惑星を取得したい場合、惑星テーブルをクエリするだけでよく、getPlanets()関数を書く必要はない；
-
イベント：MUDは自動内省機能を提供しており、データの変更はすべてシステムによって自動検知され、対応するイベントがトリガーされる。アプリはこれらのイベントをリッスンして状態を同期・更新できるため、各データ構造ごとに手動でイベントを定義する必要はない。
以上はMUDの基本構成要素と一部の使用方法の説明であり、MUDはさらに複雑なシナリオやアプリケーションの構築も可能にしている。
世界を走らせる――World Engine
全チェーンゲームの実行は、イーサリアムにとって長らく大きな課題であった。しかしRollupsの急速な発展とカンクンアップグレードの近づきにより、コストは大幅に低下し、速度は大きく向上する未来が見えてきた。全チェーンゲームは今まさに動き出そうとしている。だが現在の主流Rollupsは基本的に取引向けに設計されており、全チェーンゲーム専用のRollupは存在していない。
Argusの主力製品であるWorld Engineは、まさに全チェーンゲームのために設計されたシャーディングアーキテクチャのRollupである。現時点では公開テストは行われていないため、プロジェクトのブログや講演資料からWorld Engineを分析する。
全チェーンゲームに必要なRollupとは
-
高スループットと高TPS：より速いトランザクション処理、より低いレイテンシ、より優れたスケーラビリティ；
-
読み書きの拡張性：ほとんどのLayer2は高並列処理のために大量の書き込みを前提に設計されているが、ゲームではプレイヤー位置の取得など、読み取りも同様に重要である；
-
水平方向に拡張可能なチェーン：水平スケーラビリティとは、より多くのノードやリソースを追加することでシステムの処理能力を高める仕組みであり、需要の増大に対応できる。これにより、Noisy Neighbor問題（あるアプリやエンティティの活動が他のものに悪影響を及ぼし、リソース争奪やパフォーマンス低下を引き起こす）を回避できる；
-
柔軟性とカスタマイズ性：柔軟でカスタマイズ可能であり、ステートマシンを容易に修正してゲーム向けに設計できる。ゲームループを持ち、自己実行可能にするなど；
-
Tick rate（ティックレート）：ティックはゲーム時間における原子単位であり、十分に低いレイテンシを実現するには、より高いティックレート、つまり1秒あたりのブロック数を増やす必要がある。
シャーディングアーキテクチャ
上記の目標を達成するため、開発チームは21世紀初頭および1990年代末のオンラインゲーム黎明期に着想を得た。当時、MMOのようなオンラインゲームが台頭し始めたが、サーバーやネットワーク技術が限られていた中で、多数のプレイヤーが同時にインタラクトできる仕組みが必要とされた。「シャーディング」はその一つの解決策であり、その中心思想は、プレイヤーを異なるサーバーまたは「シャード」に分散させ、各シャードが独立して一定数のプレイヤー、マップ、データをホストすることにある。
たとえば、Ultima Onlineは初期のMMORPGであり、サーバー上でシャーディングの概念を実装していた。ゲーム内の異なるシャードは異なる仮想世界を表し、各シャードは一定数のプレイヤーを収容できる。これによるメリットは以下の通り：
-
拡張性：プレイヤーを異なるシャードに分散させることで、より多くのプレイヤーに対応できる；
-
負荷の低減：シャードにより、単一サーバーのプレイヤー数とデータ量が削減され、サーバー負荷が下がり、パフォーマンスが向上；
-
混雑の回避：プレイヤーが同一エリアに集中するのを防ぎ、スムーズなゲーム体験を提供；
-
地理的最適化：プレイヤーを地理的に近いシャードに割り当てることで、ネットワークラグを削減し、ゲームの応答速度を向上。
この概念をWorld Engineにどう適用するか？過去の多くのシャーディングソーターとは異なり、「World Engine」の設計は特定のニーズに最適化されている。その最適化ポイントはスループットと実行時間。効率的な「ティックレート」（1秒あたりの更新頻度）とブロック時間を確保するため、デフォルトで同期的である。取引が迅速に処理され、ゲーム体験やシステム性能が維持されることが目的。ソート方式は完全順序ではなく、部分的順序を採用。すべての取引に絶対的な順序を強制しないことで、ソートの負担を減らし、高スループットと短ブロック時間の要求に応える。
ここには二つのキーコンポーネントがある。EVM Base Shard（EVM分岐）とGame Shard（ゲーム分岐）だ。EVM分岐は純粋なEVMチェーンである。一方、真の秘密兵器はゲーム分岐であり、高性能ゲームサーバーとして設計されたミニブロックチェーンである。World Engineはbring-your-own-implementationインターフェースを備えており、好みに応じてこの分岐をカスタマイズできる。構築した分岐をベース分岐に注入するだけでよく、標準インターフェースを実装すればよい。これはCosmosに似ており、CosmosはIBCインターフェースを持っている。同様の仕様に統合でき、独自の分岐をWorld Engineスタックに持ち込める。
CardinalはWorld Engine初のゲーム分岐実装である。Entity-Component-System (ECS) ゲームアーキテクチャを採用しており、データ指向のアーキテクチャにより、ゲーム処理の並列化と計算スループットの向上を実現している。設定可能な「ティックレート」は最大毎秒20回。つまりブロックチェーンとして見れば毎秒20ブロックである。さらに、外部インデクサーを必要とせず、自己索引化が可能。
また、分岐は地理的配置によってレイテンシをさらに低減できる。たとえば、アメリカにソーターがある場合、アジアのプレイヤーはトランザクションがソーターに届くまで300ミリ秒の遅延を強いられる。これはゲームにおいて深刻な問題であり、300ミリ秒は非常に長い。200ミリ秒の遅延でFPSゲームをプレイしようとすれば、ほぼPPTを見ているようなものだ。
結論：全チェーンゲームへの考察
全チェーンゲームは、アジアの暗号コミュニティではこれまで比較的マイナーな分野であった。しかしStarknetのゲームエンジンDojoの登場や、OP Stackに基づくプロトタイピング用ティックチェーンのデモンストレーションをきっかけに、議論が活発化している。本稿で扱ったのは『Dark Forest』から派生したエコシステムであり、現時点で最も強力な全チェーンゲームエコシステムと言える。
その歴史と技術的背景を考察することで、RollupやDAppにはまだ非常に高い潜在能力があることがわかる。もっと広い視野で見れば、インフラ整備の進展とともに、ゲームに限らず、さまざまな複雑なアイデアの構築と実装がMUDを通じて行われ、より洗練されたRollup上で相互作用するようになるだろう。ブロックチェーンの新パラダイムは、もしかすると全チェーンゲームから始まるかもしれない。
全チェーンゲームにはまだまだ発展可能なテーマが多数ある。たとえばLootから派生した全チェーンゲームエコシステムがStarknetの発展を後押しした事例や、状態同期の実現方法、ECSアーキテクチャの応用などである。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@YBBCapital
