MUDインデクサーは酷い設計なのか？
TechFlow厳選深潮セレクト
MUDインデクサーは酷い設計なのか？
MUDエンジンのIndexerは最も悪くない設計である。本稿ではこの結論を詳細に説明し、より優れた解決策の可能性を探る。
Web3業界の深掘り報道に専念し潮流を洞察執筆：ck、MetaCat
はじめに
このタイトルを掲げたのは注目を集めるためではなく、最近MUDフレームワーク（より正確には「フレームワーク」と呼ぶべき）を使用している中で、率直な感想として湧いた思いだからだ。その初步的な結論は次の通りである：MUD Indexerは、「最悪ではない」設計である。本稿ではこの結論を詳細に説明し、より優れた代替案の可能性についてもごく初歩的な考察を行いたい。満足できる答えはまだ見つかっていないが、思いついたことを記録しておき、参考意見を呼び寄せる意味での「抛砖引玉」になれば幸いだ。
出典：https://mud.dev/
データベース中心主義
『フルチェーン版2048：MUDエンジンの使用から学んだこと』（リンク）においても述べたように、MUDフレームワークの設計思想は「データベース中心主義」に基づいている。MUDフレームワークでは、物語の主軸がオンチェーンデータの読み書きに置かれており、データの「書き込み」はStoreが担当する。一方、データの「読み取り」は主にIndexerが担う。ここで「主に」という表現を使うのは、オンチェーンにおけるデータ読み取りはStoreが行うが、オフチェーン（あるいはクライアント側）でのデータ読み取りはIndexerが担当するためである。
出典：https://mud.dev/introduction
ユーザーの待機時間
Indexerの本質は、オンチェーンデータ（リレーショナルデータベースに類似した形式で存在）のクライアント側コピーである。ブラウザベースのDAppという文脈では、これはページを再読み込みするたびに、クライアント側で再度データのコピーを構築しなければならないことを意味する。データが「チェーン上に蓄積される」性質を持つため、時間が経過するにつれてコピー構築に要する時間が増加し、結果としてユーザーの待機時間が長くなり、ユーザーエクスペリエンスが低下していく。
出典：https://www.mud2048.fun/
mud2048.funを例に挙げると、現在ゲームのメイン画面に到達するまでに約10〜20秒の待機が必要であり、この体験は非常に苛立たしいものだ。本稿ではここを出発点として、MUD Indexerの設計の長所と短所、改善の余地があるかどうか、そしてどのようにしてオンチェーンアプリケーション開発フレームワークにおけるデータ読み書きのパターンを設計すべきかについて議論したい。
イーサリアムLayer 2上でアプリケーションの爆発的普及が期待されている状況下では、こうした議論は極めて現実的な意義を持つ。むしろ、Layer 2上のアプリケーションが本当に爆発的に普及するかどうかを決める「根本問題」とさえ言える。もし本問題が解決されれば、イーサリアムLayer 2アプリケーションの爆発的普及に対するインフラ障壁は解消され、あとは新たなビジネスモデルの登場を待つだけとなるだろう。
MUD Storeはオンチェーン書き込みのより優れた選択肢
Storeによるデータ書き込み方式は、Solidityネイティブのデータパッケージング（Data Packaging）よりもコンパクトであり、これによりストレージコストを削減できる。さらに、オンチェーンデータの保存を、ソフトウェア工学分野で十分に検証された「リレーショナルデータベース」にマッピングすることで、開発者にとって非常に使いやすい設計となっている。したがって、Solidityネイティブのデータ書き込み方法と比較すれば、Storeの方式は明らかに優れている。ただし、この設計は一定程度、データ読み取りの効率性という課題を引き起こしており、タゴールの言葉を借りれば、「最高のものは独りで来るのではない。すべてのものと共にやって来るのだ」。
出典：https://mud.dev/store/tables
このようなデータ書き込み方式、言い換えればブロックチェーンへのデータ書き込みは、データ読み取り／照会に対して以下の2つの手段しか残さない：
方法1：直接オンチェーンから読み取る。欠点は効率が低く、複雑な照会をサポートできないこと。
方法2：オンチェーンデータをオフチェーンに「コピー」し、オフチェーンで複雑な照会を行う（MUDが採用している方式）。しかし、これには2つの問題が生じる：
1＞ 時間が経つにつれて、データの同期・コピーに要する時間が増大し、ユーザーエクスペリエンスが徐々に悪化する；
2＞ 各クライアントのコピー上で、ランキングのようなグローバルな照会／計算をそれぞれ繰り返すことで、ある程度のリソースの無駄遣いが発生する。
mud2048.funの開発中に、問題1に関してMUDチームと簡単なやり取りを行い、一時的な対処法を得たが、根本的な解決には至らなかった。下図の赤枠部分が、MUDフレームワーク内蔵のオンチェーンデータ「コピー」プロセスである。
出典：https://www.mud2048.fun/
究極の問い：フルチェーンアプリケーションはいかにして効率的なデータ読み取りを実現するのか？
インターネット製品の発展過程からわかっているのは、ほとんどの製品において90％以上の時間がデータ読み取りに費やされ、データ書き込みに使われる時間は10％未満ということだ。したがって、効率的なデータ読み取りの仕組みは、製品のユーザーエクスペリエンスを直接左右する。
このデータ読み取りの問題は、ブロックチェーン領域では「データ可用性層（Data Availability Layer）」という類似の概念がある。厳密には同じ次元の話ではないが、現在の問題を考える上で参考になるかもしれない。ここではそれを借りて考えてみよう。
出典：https://www.alchemy.com/overviews/data-availability-layer
ブロックチェーン分野における代表的なDA（Data Availability）のアプローチは、大別して「オンチェーンDA」と「オフチェーンDA」の二種類に分けられる。ビットコインのインスクライブ（Inscriptions）はオンチェーンDAの例であり（データはビットコインブロックチェーン上に保存され、解釈はチェーン外で行われる）、イーサリアムLayer 2はオフチェーンDAの例である（ZK RollupおよびOP Rollupは、イーサリアムLayer 1上でCALLDATA形式でデータを保存する）。これら二つのアプローチは現在も競合中であり、どちらが優勢かは定まっていないが、まさにそれゆえに、我々が今考えている問題に対する正反対の参考事例を提供してくれている。
Web2の手法はそのまま適用できない
Web2の世界では、データベースの読み取り性能が不足する場合、通常はキャッシュ層（Cache）をデータベース前に配置したり、複数のデータベースリプリカ（従属データベース）を追加することで読み取り能力を向上させる。
典型的なWeb2サービスアーキテクチャ。出典：https://smartbuilds.io/scaling-web3-social-media-blockchain-cache-layer/
しかしブロックチェーンの世界では、これらの手法は現時点ではいずれも通用しない。サービス提供の形態が中央集権型から分散型へと変化し、データの保存も構造化されたものからチェーン式へと変わったことで、基盤となるモデルが大きく異なっているため、それに応じた解決策もまた変わっていなければならない。だが、ブロックチェーン向けの「キャッシュ」や「リプリカ」の解決策は、まだ見つかっていない。
Web2のキャッシュ方式を参考にしたDAppの試みもあるが、汎用性に欠ける。MUDフレームワークの視点から見れば、このようなアプローチはさらに多くの中央集権的要素を導入してしまうため、理想的とはいえず、むしろ望ましくない。
キャッシュを統合したDAppアーキテクチャ。出典：https://smartbuilds.io/scaling-web3-social-media-blockchain-cache-layer/
Indexerは「最悪ではない」選択肢
MUD自体の観点から言えば、アプリケーションチェーン領域において大きな進歩と言える。なぜなら、MUDは同時に以下の3つの問題を解決しているからだ：
1＞ スマートコントラクト内でデータとロジックが結合しているために、ロジックのアップグレードが困難になる問題
2＞ チェーンとクライアント間でデータ同期の仕組みが欠如しており、データ状態の不一致が生じる問題
3＞ ブロックチェーンに統一されたアクセス制御メカニズムがなく、一定の重複作業や相互運用性の障壁が生じる問題
MUDがデータ読み取り問題を解決するアイデアは、クライアント側に特定のコントラクトのデータのみを扱う「フルノード」を配置することにある。MUD公式ではこれを「Namespaced Full-node」と呼んでおり、つまり私たちが言うところのIndexerである。
出典：https://youtu.be/tLGdup5wmck?si=ykgQ4qwut4VLgimF
このアプローチは、アプリケーションチェーン分野において「ゼロからの一歩」であり、明らかに大きな前進である。完璧とは言えないが、悪いスタートではない。後続の開発者は巨人の肩に乗って、より良い解決策を探求できるだろう。総じて言えば、MUD Indexerは「最悪ではない」設計だが、我々にはさらに良いものが求められている。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
