暗号コモンズの悲劇シリーズ：ポリマーケットのデータインデックスの悲劇

著者: ショー

まとめ

GCC リサーチコラムの「暗号コモンズの悲劇」シリーズへようこそ。

このシリーズでは、暗号資産の世界において、規範の遵守がますます困難になっている重要な公共財に焦点を当てます。これらはエコシステム全体の基盤となるインフラですが、不十分なインセンティブ、不均衡なガバナンス、さらには中央集権化の進行といった課題にしばしば直面しています。暗号技術の理想と、冗長性と安定性の現実は、これらの分野で厳しい試練に直面しています。

本号では、イーサリアムエコシステムで最も影響力のあるアプリケーションの一つであるPolymarketとそのデータインデックスツールに焦点を当てています。今年、Polymarketは、トランプ大統領の選挙勝利、ウクライナのレアアース取引におけるオラクル操作、ゼレンスキー大統領のスーツの色を巡る政治的賭けといった出来事をめぐり、繰り返し世論の注目を集めてきました。その資本規模と市場への影響力の大きさゆえに、これらの論争は特に困難なものとなっています。

しかし、この製品の重要な構成要素であるデータインデックスは、「分散型予測市場」を体現する製品であり、真に分散化されていると言えるのでしょうか？The Graphのような公共インフラはなぜ本来の役割を果たせていないのでしょうか？真に使いやすく持続可能なデータインデックスという公共財は、どのような形をとるべきなのでしょうか？

1. 集中型データプラットフォームのダウンタイムによって引き起こされる連鎖反応

2024年7月、Goldskyは6時間にわたる障害に見舞われました（GoldskyはWeb3開発者向けのリアルタイムブロックチェーンデータ基盤プラットフォームで、インデックス作成、サブグラフ作成、ストリーミングデータサービスを提供し、データ駆動型の分散型アプリケーションの迅速な構築を支援します）。これにより、Ethereumエコシステムの大部分が麻痺しました。例えば、DeFiフロントエンドではユーザーのポジションや残高データを表示できず、予測市場Polymarketでは正しいデータを表示できませんでした。数え切れないほどのプロジェクトがフロントエンドユーザーにとって完全に利用不可能になったように見えました。

分散型アプリケーションの世界では、このようなことがあってはなりません。そもそも、ブロックチェーン技術は単一障害点を排除するために設計されたのではないですか？ゴールドスキー事件は、憂慮すべき真実を露呈しました。ブロックチェーン自体は可能な限り分散化されているものの、その上に構築されたアプリケーションのインフラストラクチャには、しばしば多数の中央集権型サービスが含まれているのです。

その理由は、ブロックチェーンデータのインデックス作成と検索が非排他的かつ非競合的なデジタル公共財であるためです。ユーザーはしばしばこれらが無料または極めて低コストであることを期待しますが、これらのサービスは、ハードウェア、ストレージ、帯域幅、そして運用人員への継続的かつ集中的な投資を必要とします。持続可能な収益モデルが欠如すると、勝者総取りの中央集権的な構造が形成されます。サービスプロバイダーが速度と資金の面で先行者利益を獲得すると、開発者はすべてのクエリトラフィックをそのサービスに誘導する傾向があり、結果として単一の依存関係が再び生まれます。Gitcoinのような公共福祉プロジェクトは、「オープンソースインフラは数十億ドルの価値を生み出す可能性があるが、著者は住宅ローンの支払いにそれを頼りにできないことが多い」と繰り返し強調してきました。

これは、分散型世界が公共財への資金提供、再分配、あるいはコミュニティ主導の取り組みを通じて、Web3インフラの多様化を早急に進める必要があることを如実に物語っています。さもなければ、中央集権化は避けられなくなります。DApp開発者には、ローカルファーストの製品を構築するよう強く求めます。また、技術コミュニティには、DAppsの設計においてデータ取得サービスの障害を考慮し、データ取得インフラがなくてもユーザーがプロジェクトにアクセスできるようにする必要があります。

2. Dapp に表示されるデータはどこから来ているのでしょうか?

Goldskyのような事件がなぜ発生するのかを理解するには、DAppsの舞台裏の仕組みをより深く掘り下げる必要があります。一般的なユーザーにとって、DAppsは通常、オンチェーン・コントラクトとフロントエンドの2つの部分で構成されています。ほとんどのユーザーは、Etherscanなどのツールを使用してオンチェーンのトランザクション状況を追跡し、フロントエンドで必要な情報を取得し、トランザクションを開始してコントラクトを操作することに慣れています。しかし、ユーザーのフロントエンドに表示されるこれらのデータは、実際にはどこから来ているのでしょうか？

欠かせないデータ検索サービス

ユーザーの保有資産と、各ポジションの証拠金と負債の状況を表示するレンディングプロトコルを構築しているとします。素朴なアイデアとしては、フロントエンドがチェーンから直接このデータを読み取ることが挙げられます。しかし実際には、レンディングプロトコルのコントラクトでは、ユーザーアドレスがポジションデータを照会することを許可していません。コントラクトは、ポジションIDを使用してポジションの特定のデータを照会する機能を提供します。そのため、フロントエンドでユーザーのポジション状況を表示したい場合は、現在のシステム内のすべてのポジションを取得し、どのポジションが現在のユーザーに属しているかを見つける必要があります。これは、特定の情報を得るために何百万ページもの台帳を手動で検索するように誰かに依頼するようなものです。技術的には可能ですが、非常に遅く非効率的です。実際、フロントエンドがこの取得プロセスを完了することは困難です。大規模なDeFiプロジェクトの取得タスクをローカルノードによってサーバー上で直接実行した場合でも、多くの場合、数時間かかります。

したがって、データ取得を加速するためのインフラストラクチャを導入する必要があります。Goldskyのような企業は、こうしたデータインデックスサービスを提供しています。次の図は、データインデックスサービスがアプリケーションに提供できるサービスの種類を示しています。

ここまで読んで、イーサリアムエコシステム内にTheGraphと呼ばれる分散型データ取得プラットフォームが存在することに興味を持たれた読者もいるかもしれません。このプラットフォームとGoldskyの関係は何でしょうか？そして、なぜ多くのDeFiプロジェクトが、より分散化されたTheGraphではなく、Goldskyをデータプロバイダーとして利用しているのでしょうか？

TheGraph/GoldskyとSubGraphの関係

上記の質問に答えるには、まずいくつかの技術的な概念を理解する必要があります。

SubGraph は、開発者がオンチェーンデータを読み取って要約するコードを記述し、特定の方法を使用してこのデータを読み取ってフロントエンドに表示するために使用できる開発フレームワークです。
TheGraphは、AssemblyScriptで記述されたSubGraphフレームワークを開発した、初期の分散型データ取得プラットフォームです。開発者は、このサブグラフフレームワークを使用して、コントラクトイベントをキャプチャし、データベースに書き込むプログラムを作成できます。ユーザーは、Graphqlメソッドを使用してこのデータを読み込んだり、SQLコードを直接使用してデータベースを読み込んだりできます。
SubGraphを実行するサービスプロバイダーを一般的にSubGraphオペレーターと呼びます。TheGraphとGoldskyはどちらもSubGraphホストです。SubGraphは開発フレームワークであるため、SubGraphで開発されたアプリケーションはサーバー上で実行する必要があります。Goldskyのドキュメントには、以下の記載があります。

読者の中には、なぜ SubGraph に複数の演算子があるのか気になる方もいるかもしれません。

これは、SubGraph フレームワークが実際には、ブロック内のデータベースからデータを読み取ったり、データベースにデータを書き込んだりする方法のみを規定しているためです。

SubGraphプログラムへのデータの流れ方や、最終的な出力結果がどのようなデータベースに書き込まれるかについては実装されていません。これらの内容は、SubGraphオペレータ自身が実装する必要があります。

一般的に、サブグラフオペレーターはノードを変更することで速度向上を図ります。TheGraph、Goldskyなど、オペレーターによって戦略や技術的ソリューションは異なります。

TheGraphは現在、Firehouseテクノロジーソリューションを使用しています。このテクノロジーソリューションの導入により、TheGraphは以前よりも高速なデータ取得を実現しています。しかし、GoldskyはSubGraphを実行するコアプログラムを未だ公開していません。

前述の通り、TheGraphは分散型データ取得プラットフォームです。Uniswap v3のサブグラフを例に挙げると、Uniswap v3のデータ取得サービスを提供するオペレーターが多数存在することがわかります。そのため、TheGraphはサブグラフオペレーターの統合プラットフォームとも言えます。ユーザーは独自のサブグラフコードをTheGraphに送信でき、TheGraph内にはユーザーのデータ取得を支援するオペレーターがいくつか存在します。

ゴールドスキーの価格モデル

Goldskyのような集中型プラットフォーム向けに、Goldskyはリソース使用量に基づいたシンプルな課金システムを採用しています。これはインターネット上で最も一般的なSaaS課金方法であり、多くの技術者が慣れ親しんでいます。下の図は、Goldskyの料金計算ツールです。

TheGraphの価格モデル

TheGraphは従来の課金システムとは全く異なる料金体系を採用しています。この料金体系はGRTのトークンエコノミクスと関連しています。以下の図は、GRTのトークンエコノミクス全体を示しています。

DApp またはウォレットがサブグラフにリクエストを行うたびに、支払われるクエリ手数料は自動的に分割されます。1% はバーンされ、約 10% がサブグラフのキュレーションプール (キュレーター/開発者) に流れ込み、残りの約 89% が指数リベートメカニズムに従ってコンピューティング能力を提供するインデクサーとそのデリゲーターに支払われます。
インデクサーはオンラインになる前に10万GRT以上のステークを行う必要があります。誤ったデータを返却するとスラッシングが発生します。委任者はインデクサーにGRTを委任し、前述の89%の比例配分を受け取ります。
キュレーター（通常は開発者）は、Signalを使用して、自身のサブグラフの結合曲線にGRTをステークします。Signalの数値が高いほど、より多くのインデクサーがリソースを割り当てようとします。コミュニティの経験から、複数のインデクサーからの注文を確保するには、5,000～10,000GRTを調達することが推奨されます。キュレーターはロイヤリティの10%を受け取ります。

TheGraph のクエリごとの料金:

TheGraphバックエンドにAPI KEYを登録し、そのAPI KEYを使用して、TheGraphのオペレーターが取得したデータをリクエストします。これらのリクエストはリクエスト数に基づいて課金されます。開発者は、APIリクエストのコストとして、事前にGRTトークンの一部をプラットフォームにデポジットする必要があります。

TheGraphのSignalステーキング手数料：

SubGraphの導入者は、データを取得するためにTheGraphプラットフォーム内のオペレーターの協力を必要とします。前述の利益分配方法によると、彼らは他の参加者に「私のクエリサービスの方が優れていて、より多くの収益が得られる」と伝える必要があります。GRTをステークする必要があります。これは広告のようなもので、利益が得られることを保証することで、人々が集まるようにするのです。

テスト期間中、開発者は SubGraph を TheGraph プラットフォームに無料でデプロイできます。TheGraph は、テスト目的で無料の割り当てを提供し、ユーザーの検索を支援します。この割り当ては本番環境での使用には適していません。開発者が SubGraph が TheGraph の公式テスト環境で良好に動作すると判断した場合、パブリックネットワークに公開し、他のオペレーターが検索に参加するのを待つことができます。開発者は、保証された検索アクセスのために単一のオペレーターに直接料金を支払うことはできません。代わりに、複数のオペレーターが競争してサービスを提供することで、単一の依存関係を回避します。このプロセスでは、GRT トークンを使用して SubGraph でキュレーション (シグナリングとも呼ばれます) を実行する必要があります。これには、開発者がデプロイした SubGraph に一定量の GRT をステークすることが含まれます。オペレーターは、ステークされた GRT が特定のレベル (以前に参照されたデータは 10,000 GRT) に達した場合にのみ、SubGraph 検索プロセスに参加します。

請求業務の経験不足が開発者と従来の会計士を悩ませている

ほとんどのプロジェクト開発者にとって、TheGraphの使用は比較的面倒なプロセスです。Web3プロジェクトではGRTトークンの購入は比較的簡単ですが、デプロイ済みのサブグラフをキュレートし、オペレーターを待つというプロセスは非常に非効率的です。このプロセスには、少なくとも2つの問題があります。

ステーキングするGRT量の不確実性と、オペレーターの関心を引くのに必要な時間。以前SubGraphをデプロイした際、ステーキングするGRT量を決定するためにTheGraphコミュニティアンバサダーと直接相談しました。しかし、ほとんどの開発者にとって、このデータを入手するのは容易ではありません。さらに、十分なGRTをステーキングした後、オペレーターが介入して調査を行うにはある程度の時間がかかります。
コスト計算と会計の複雑さ。TheGraphはトークンエコノミクスに基づいて料金体系を設計しているため、多くの開発者にとってコスト計算は複雑になります。より現実的に言えば、企業がこの費用を会計処理する場合、会計担当者がコスト構造を理解できない可能性があります。

「優れている方が良いのか、それとも中央集権化されている方が良いのか？」

当然のことながら、ほとんどの開発者にとって、Goldskyを直接選択する方が簡単です。課金方法は誰にとっても分かりやすく、支払いさえ済ませればほぼ即座に利用できるため、不確実性が大幅に軽減されます。このことが、ブロックチェーンデータのインデックス作成・検索サービスにおいて、単一の製品に依存する状況を生み出しています。

TheGraphの複雑なGRTトークンエコノミクスは、明らかに広範な普及を妨げています。トークンエコノミクスは複雑になりがちですが、その複雑さをユーザーに公開すべきではありません。例えば、GRTのキュレーションやステーキングの仕組みは、ユーザーに公開すべきではありません。より良いアプローチは、ユーザーに簡素化された支払いページを提供することです。

上記のTheGraphに対する批判は、私の個人的な意見ではありません。著名なスマートコントラクトエンジニアであり、Sablierプロジェクトの創設者であるPaul Razvan Berg氏もツイートで同様の見解を示しました。ツイートでは、SubGraphとGRT課金の導入におけるユーザーエクスペリエンスが極めて劣悪だったと述べられています。

3. 既存の解決策

データ取得における単一障害点の解決方法については、既に上記で既に触れました。開発者はTheGraphサービスの利用を検討できますが、そのプロセスはより複雑になります。開発者は、ステーキングキュレーションとAPI料金の支払いのためにGRTトークンを購入する必要があります。

現在、EVMエコシステムには多くのデータ検索ソフトウェアが存在します。詳細については、Duneによる「The State of EVM Indexing」、またはrindexerによるEVMデータ検索ソフトウェアの概要をご覧ください。また、最近の議論については、こちらのツイートをご覧ください。

この記事では、Glodsky 社の問題の具体的な原因については触れません。Glodsky 社は現在原因を把握していますが、企業ユーザーのみに公開しています。つまり、Glodsky 社の障害の正確な原因を特定できる第三者は現時点では存在しません。報告に基づくと、取得したデータをデータベースに書き込む際に問題が発生した可能性があると推測できます。この簡潔な報告の中で、Glodsky 社はデータベースにアクセスできず、AWS との連携によってアクセスが復旧したと述べています。

このセクションでは、主に他のソリューションを紹介します。

Poderは、優れた開発経験と容易な導入を備えたシンプルなデータ検索サービスソフトウェアです。開発者はサーバーをレンタルし、自身で導入することができます。
ローカルファーストは、ネットワークが利用できない状況でも優れたユーザーエクスペリエンスを提供することを開発者に促す、興味深い開発コンセプトです。ブロックチェーンがあれば、ローカルファーストの制約をある程度緩和することができ、ユーザーがブロックチェーンに接続できる状況では、優れたエクスペリエンスを確実に得られるようになります。

熟考する

なぜ他のソフトウェアではなくponderの使用を推奨するのでしょうか？具体的な理由は次のとおりです。

Ponderはベンダーに依存しません。当初、Ponderは個々の開発者によって構築されたプロジェクトであったため、他社が提供するデータ取得ソフトウェアと比較して、PonderではユーザーがEthereum RPC URLとpostgresデータベースリンクを入力するだけで済みます。
Ponderは優れた開発エクスペリエンスを提供します。私は過去に何度も開発にPonderを使用しました。PonderはTypeScriptで記述されており、コアライブラリは主にViemに依存しているため、開発エクスペリエンスは非常に良好です。
Ponderの方がパフォーマンスが高い

もちろん、いくつか問題点はあります。Ponderはまだ急速な開発段階にあり、開発者はアップデートによって以前のプロジェクトが動作しなくなるといった状況に遭遇する可能性があります。この記事は技術的な紹介ではないため、Ponderの開発の詳細については触れません。技術的な知識をお持ちの読者は、ドキュメントを参照することをお勧めします。

Ponder に関してさらに興味深いのは、同社も部分的に商業化を開始している点ですが、Ponder の商業化の道筋は、前回の記事で論じた「分離理論」と非常に一致しています。

ここでは、「分離理論」について簡単に紹介します。公共財の公共性は、無制限の数の利用者にサービスを提供できるという点を主張します。したがって、公共財に料金を課すと、一部の利用者が利用をやめてしまい、社会的な便益が最大化されません（経済学では「パレート最適ではなくなる」と表現されます）。理論的には、公共財は利用者ごとに異なる価格設定が可能ですが、価格差を設けることによるコストが便益を上回る可能性があります。したがって、公共財が無料である理由は、それが本質的に無料であるからではなく、固定料金が社会的な便益を損なうためであり、現状では利用者ごとに異なる価格設定を安価に実現する方法が存在しないからです。分離理論は、均質な集団を隔離し、料金を課すという、公共財内の価格設定手法を提案しています。分離理論は、誰もが公共財を無料で享受することを妨げるものではありませんが、一部の人々に料金を課す方法を示唆しています。

Ponder は分離理論に似た方法を使用します。

まず、ponder のデプロイには一定の知識が必要です。開発者は、デプロイプロセス中に RPC やデータベースなどの外部依存関係を提供する必要があります。
デプロイ後、開発者はPonderアプリケーションの継続的な運用と保守を行う必要があります。例えば、データリクエストがバックグラウンドスレッドでのPonderのオンチェーンデータ取得に影響を与えないように、プロキシシステムを用いた負荷分散を行うなどです。これは一般的な開発者にとっては少々複雑です。
現在、Ponderは完全自動デプロイメントサービス「Marble」の内部テストを行っています。ユーザーはプラットフォームにコードを送信するだけで、自動デプロイメントを実現できます。

これは明らかに「分離理論」の原則の適用例です。Ponderサービスの運用・保守を自ら行おうとしない開発者は分離され、これらの開発者は有料で簡略化されたPonderデプロイメントサービスを利用できます。もちろん、Marbleプラットフォームの登場によって、他の開発者がPonderフレームワークを無料で利用し、セルフホスティングでデプロイメントを行うことが妨げられることはありません。

ポンダーとゴールドスキーの観客は？

完全にベンダーフリーの公共財である Ponder は、他のベンダー依存のデータ取得サービスよりも小規模プロジェクトの開発に人気があります。
大規模プロジェクトを運営する開発者の中には、必ずしも Ponder フレームワークを選択しない人もいます。これは、大規模プロジェクトでは検索サービスに十分なパフォーマンスが求められることが多く、Goldsky などのサービスプロバイダーが十分な可用性の保証を提供していることが多いためです。

どちらにもリスクがあります。最近のGoldsky氏のインシデントが示唆するように、開発者はサードパーティのサービス停止の可能性を軽減するために、独自のponderサービスを維持することが推奨されます。さらに、ponderを使用する際には、RPCリターンデータの妥当性を考慮する必要があります。Safe社は最近、不正なRPCリターンデータが原因で検索エンジンがクラッシュしたと報告しました。Goldsky氏のインシデントと不正なRPCリターンデータを結びつける直接的な証拠はありませんが、Goldsky氏も同様の問題に遭遇した可能性があると考えています。

地域第一主義の開発理念

ローカルファーストはここ数年、注目を集めています。簡単に言うと、ローカルファーストを実現するには、ソフトウェアに以下の機能が必要です。

オフライン作業
クライアント間のコラボレーション

現在、ローカルファースト技術に関する議論の多くは、CRDT（Conflict-free Replicated Data Type）に焦点をあてています。CRDTは、複数のデバイスで操作する際に、ユーザーが競合を自動的に解決し、データの整合性を維持できる、競合のないデータ形式です。CRDTを簡単に理解するには、シンプルなコンセンサスプロトコルを備えたデータ型と考えると良いでしょう。分散環境において、CRDTはデータの整合性と一貫性を保証します。

しかし、ブロックチェーン開発においては、前述のローカルファーストのソフトウェア要件を緩和することができます。プロジェクト開発者が提供するバックエンドのインデックスデータがなくても、フロントエンドで最低限のユーザビリティが維持されることのみを要求します。さらに、クライアント間の連携におけるローカルファーストの要件は、ブロックチェーンによって既に解決されています。

DApps のコンテキストでは、ローカルファーストのコンセプトは次のように実装できます。

重要なデータをキャッシュする: フロントエンドでは、残高や保有資産などの重要なユーザーデータをキャッシュする必要があります。これにより、インデックスサービスが利用できない場合でも、ユーザーは最新の既知のステータスを確認できます。
機能低下対策設計：バックエンドのインデックスサービスが利用できない場合でも、DAppは基本的な機能を提供できます。例えば、データ取得サービスが利用できない場合、RPCを使用してチェーン上の一部のデータを直接読み取ることができるため、ユーザーは既存のデータの最新の状態を確認できます。

このローカルファーストDAppの設計哲学は、アプリケーションの回復力を大幅に向上させ、データ取得サービスのクラッシュ発生時にも利用不能状態を防ぎます。ユーザビリティに関わらず、優れたローカルファーストアプリケーションは、ユーザーがローカルノードを実行し、trueblocksなどのツールを使用してローカルでデータを取得することを前提としています。分散型取得とローカル取得に関する詳細な議論については、「文字通り誰も分散型フロントエンドとインデクサーを気にしていない」という投稿をご覧ください。

4. 最後に

Goldskyの6時間に及ぶ障害は、エコシステムへの警鐘となりました。ブロックチェーンは本質的に分散化と単一障害点への耐性を備えていますが、その上に構築されたアプリケーション・エコシステムは依然として中央集権的なインフラサービスに大きく依存しています。この依存は、エコシステム全体にシステミックリスクをもたらします。

この記事では、長年利用されてきた分散型検索サービスであるTheGraphが、今日ではなぜ広く利用されていないのか、特にGRTトークンエコノミクスによってもたらされる複雑さについて簡潔に説明します。最後に、より堅牢なデータ検索インフラストラクチャを構築する方法について考察します。開発者の皆様には、緊急対応オプションとしてセルフホスト型データ検索フレームワークPonderの活用を推奨するとともに、Ponderの商用化に向けた有望な道筋についても概説します。最後に、ローカルファースト開発哲学について考察し、データ検索サービスがなくても機能するアプリケーションの構築を開発者に推奨します。

現在、多くのWeb3開発者は、データ取得サービスの単一障害点問題を認識しています。GCCは、より多くの開発者がこのインフラストラクチャに注目し、分散型データ取得サービスの構築や、データ取得サービスなしでもDAppフロントエンドを動作させることができるフレームワークの設計に取り組むことを期待しています。