--- title: "ブロックチェーンインデクサーとは?" description: "インデクサーの役割と、オンチェーンデータのクエリにどう役立つかを解説します。" --- # ブロックチェーンインデクサーとは? ブロックチェーンには根本的な問題がある。データが検索可能ではないのだ。言い換えると、オンチェーンデータはデフォルトではクエリできない。 従来のデータベースでは、データはインデックスとリレーションを持つテーブルに整理されており、開発者は全レコードをスキャンすることなく即座にリクエストをクエリできる。対照的に、ブロックチェーンはデータをブロックの線形なチェーンとして保存しており、これは不変性とセキュリティのために最適化されたものであって、高速な検索のためのものではない。 この設計により、SQLも、組み込みのインデックスも、データを簡単にクエリできる便利な`"SELECT FROM transactions WHERE..."`関数も存在しない。ブロックチェーンが代わりに提供するのは、`eth\_getBlockByNumber`のような低レベルのRPCメソッドであり、これは生のブロックを返すだけなので、必要なものを見つけるにはブロックを一つずつ取得してスキャンするしかない。 例えば、特定のウォレットからの全トランザクションを見つけたい場合、ブロック0から始めて数百万のブロックをループし、各ブロック内のすべてのトランザクションをチェックし、途中でノードがレート制限をかけてこないことを祈る必要がある。[Ethereumメインネット](https://www.alchemy.com/rpc/ethereum)には[2,000万を超えるブロック](https://etherscan.io/)があり、これには何時間、あるいは何日もかかる可能性がある上、そのデータを使えるようにするためには自分自身で整理・保存する必要もある。 ここでインデクサーの出番となる。インデクサーは、ブロックチェーンの生の逐次データと、アプリケーションが必要とする高速なクエリとの間の橋渡し役を果たす。オンチェーンデータのための検索エンジンだと考えればいい。インデクサーはブロックチェーンを継続的に監視し、関連情報を抽出し、クエリ可能なデータベースに整理し、数時間ではなくミリ秒単位で応答するAPIを通じてそれを提供する。 インデクサーがなければ、レスポンシブなアプリを構築するのはほぼ不可能だろう。ポートフォリオの読み込みに30秒かかるDeFiダッシュボードや、トランザクションタイプでフィルタできないネオバンクを想像してほしい。インデクサーは、すべてのブロックを手動でスキャンする必要をなくすためにブロックチェーンデータを事前処理することで、この問題を解決する。 このガイドでは、ブロックチェーンインデクサーとは何か、どのように動作するのかを解説し、インデクサーの実際の使用例をいくつか紹介する。 コード例とリソースへのリンクを添えて実践的な内容にするので、初めてアプリを構築するジュニア開発者でも、単に知識を再確認したい人でも、このガイドでブロックチェーンインフラの中でも最も重要な要素の一つについて理解を深めることができるはずだ。 ## ブロックチェーンインデクサーとは何か ブロックチェーンインデクサーは、ブロックチェーンを継続的に監視し、トランザクションデータとスマートコントラクトのイベントを抽出し、それを構造化されたフォーマットに変換し、高速クエリ用に最適化されたデータベースに保存する専用サービスである。 3段階のプロセスとして考えるとわかりやすい。 1. **抽出（Extract）**: インデクサーはブロックチェーンノードをリアルタイムで監視し、チェーンに追加されるたびにすべての新しいブロック、トランザクション、イベントを取得する。 1. **変換（Transform）**: 生のブロックチェーンデータをデコードし、トランザクションの入力値を解析し、スマートコントラクトのイベントをデコードし、トークン転送を追跡し、状態変化を意味のあるレコードに整理する。 1. **ロード（Load）**: 最後に、この処理済みデータをクエリ可能なデータベース（PostgreSQL、MongoDB、または専用のグラフデータベースなど）に保存し、そのデータをアプリケーションが利用できるAPIを通じて公開できるようにする。 このプロセスがどのように詳細に動作するかについてしっかりと理解を深めたい場合は、[Ethereum Foundationによるインデクサーの入門記事](https://www.youtube.com/watch?v=WgBab6kamtg)を確認してほしい。 ## インデクサーの構成要素とは何か インデクサーは実装によって差異があるが、ほとんどはブロックチェーンデータを処理・提供するために連携するいくつかの共通の中核コンポーネントを中心とした構成を共有している。以下、それぞれがどのように組み合わさっているかを見ていく。 ### 1. データソース（ブロックチェーンとの接続） これはインデクサーとブロックチェーン自体との接続部分であり、通常はノード（Ethereumの[Geth](https://geth.ethereum.org/)や[Solana RPC](https://www.alchemy.com/dapps/list-of/rpc-node-providers-on-solana)ノードなど）か、インフラプロバイダーのAPI（Alchemyなど）を指す。 インデクサーはこのソースから生データを継続的に取得する。追加された新しいブロック、そのブロック内のトランザクション、スマートコントラクトが発行したイベントログ、時には状態変化も対象となる。一部のインデクサーはデータをリアルタイムで処理し（新しいブロックが来た瞬間に監視する）、他のインデクサーは履歴データの処理やダウンタイム後の追いつきのためにバッチ処理を行う。 ### 2. インデックスエンジン（処理レイヤー） これは処理全体の頭脳部分である。インデックスエンジンは生のブロックチェーンデータを、意味があり検索可能な形に変換する。 このエンジンの中核的な役割は、トランザクションとイベントをデコードすることだ。生のブロックチェーンデータはエンコードされているため、トランザクションの入力値は16進数の文字列であり、イベントログは暗号学的ハッシュとなっている。インデックスエンジンはコントラクトの[ABI](https://docs.soliditylang.org/en/latest/abi-spec.html)（Application Binary Interface）を使って、各トランザクションが実際に何を行ったのかを解釈する。トークンスワップだったのか、NFTのミントだったのか、それともガバナンスの投票だったのか。パラメータをデコードし、意味のある値を抽出し、すべてを人間が読める形式のレコードに変換する。 個々のトランザクションをデコードするだけでなく、エンジンは時間の経過に伴う状態変化も追跡しなければならない。ブロックチェーンは現在の状態を簡単にアクセスできる形で保存しておらず、その代わりに状態遷移の履歴を保存している。そのためインデクサーは、イベントの連鎖を追うことで現在の状態を再構築する。転送のたびにトークンの残高がどう変化するかを追跡し、トークンがウォレット間を移動するたびにNFTの所有権を監視し、各やり取りごとにスマートコントラクトのストレージ変数がどう変化するかを見守る。この状態追跡は「このウォレットは現在どのNFTを保有しているか」というようなクエリにとって不可欠だ。その答えはオンチェーン上のどこにも保存されておらず、転送履歴の全体から計算する必要がある。 エンジンはまた、専用のインデックスも構築する。これは高速な検索を可能にする効率的なデータ構造だ。書籍の索引を思い浮かべるとよい。「Ethereum」への言及を見つけるために全ページを読む代わりに、索引をチェックして関連ページに直接ジャンプする。インデックスエンジンは、アドレス用（ウォレット`0x123`の全アクティビティを見つける）、トークンID用（NFT #5000の所有者と履歴を見つける）、トランザクションタイプ用（すべての[Uniswap](https://www.alchemy.com/dapps/uniswap)スワップを見つける）、タイムスタンプ用（過去24時間の全アクティビティを見つける）などの検索テーブルを作成する。こうしたインデックスによって、数百万のブロックを逐次スキャンする処理がサブ秒単位のクエリへと変わる。 このエンジンにおけるもう一つの重要な責務は、チェーンの再編成（リオーグ）への対応だ。ブロックチェーンのコンセンサスの結果、最近の一部のブロックが別のブロックセットに置き換えられることがまれに発生する。これはしばしば「[ブロックチェーンのリオーグ](https://www.alchemy.com/overviews/what-is-a-reorg)」と呼ばれる。これが発生すると、インデクサーはそのリオーグを検知し、孤立したブロックからインデックスしたデータをロールバックし、新しい正規のブロックを再インデックスしなければならない。適切なリオーグ処理がなければ、インデックス済みのデータには正規チェーン上では実際には発生していないトランザクションが含まれてしまう。 最後に、このインデックスエンジンは同期とバックフィルを管理する。インデクサーが初めて起動する際には、ブロックチェーン全体の履歴、場合によっては何年も前にさかのぼる数百万のブロックを処理する必要がある。この「バックフィル」プロセスは効率的である必要があり、ブロック処理の並列化や、再起動に対応するための進捗のチェックポイント記録が行われることが多い。追いつくと、インデクサーは新しいブロックが追加されるたびに継続的に同期を維持し、通常はチェーンの先端からわずか数秒遅れた状態を保つ。インデクサーがオフラインになったり遅れたりした場合は、ブロックを一つも取りこぼすことなく追いつかなければならない。 計算負荷の高い処理はここで発生する。何百万ものトランザクションを解析し、コントラクトアドレスとトピックに基づいて関連イベントをフィルタリングし、複雑にネストされたデータ構造をデコードし、リオーグをまたいで一貫した状態を維持し、すべてを高速な保存・取得のために構造化する。 ### 3. データベース（ストレージレイヤー） エンジンによってデータが処理・構造化された後、それはクエリ可能などこかに保存される必要があり、通常は外部データベースがその役割を担う。データベースの選択は、インデクサーのユースケースやクエリパターンに依存する。 - **リレーショナルデータベース（PostgreSQL、MySQL）**: リレーショナルデータベースは、ほとんどのブロックチェーンインデクサーにとって最も一般的な選択肢だ。複雑な関係を持つ構造化データに適しており、例えば各トランザクションで変化するウォレット残高の追跡、ブロックやアドレスへの外部キーでリンクされたトランザクション履歴の維持、複数テーブルにまたがるJOIN操作を使ったトークン転送のクエリなどに向いている。SQLの強力なクエリ言語により、「このコントラクトから過去1週間で10 ETH以上を受け取った全アドレスを表示して」といった問いかけが容易になる。厳格なスキーマによってデータの一貫性が保証され、これは金融情報を扱う上で重要となる。 - **NoSQLデータベース（MongoDB、Cassandra）**: NoSQLデータベースは、スキーマが時間とともに変化しうる半構造化データに柔軟性をもたらす。イベント構造が多様な様々なスマートコントラクトをインデックスする場合や、テーブルにきれいに収まらない生のトランザクションメタデータを保存する場合に有用だ。これらのデータベースは水平スケーリングに優れ、データを複数サーバーに分散することで大量の書き込み量（1秒間に数千ブロックを処理する場合に重要）に対応できる。複雑なクエリ能力よりも生のインデックス速度が重要な場合によく使われる。 - **グラフデータベース（Neo4j）**: グラフデータベースは、関係性の多いクエリのために特化して設計されている。複数ウォレットを介したトークンの流れの追跡（資金を追う）、DeFiプロトコル間のやり取りの分析（どのプロトコルが流動性プールを介してつながっているか）、ソーシャルグラフの構築（どのウォレット同士がやり取りしているか）といったユースケースに最適だ。リレーショナルデータベースのJOINの代わりに、グラフデータベースはネイティブなグラフ探索を使用し、「このアドレスから3ホップ以内のすべてのウォレットを見つける」といった処理を、リレーショナルデータベースよりも桁違いに高速に行える。 - **データウェアハウス（BigQuery、Snowflake）**: データウェアハウスは、大規模データセットにわたる分析や集計のために設計されている。これはリアルタイムクエリ向けではなく、「今月の全DEXにおける総取引高は」「過去1年間のチェーンごとの日次アクティブアドレスを表示して」といった問いかけに答えるためのものだ。カラムナストレージと分散処理を使って数十億のレコードを効率的に処理できるが、運用データベースに比べてレイテンシは高い。 多くの本番インデクサーは複数のデータベースタイプを併用している。アプリケーションのUIを支える高速なリアルタイムクエリのためにトランザクションデータをPostgreSQLに保存する一方で、同じデータを分析ダッシュボードや過去のトレンド分析のためにBigQueryにも同時に流し込む、といった具合だ。このハイブリッドなアプローチにより、各データベースが最も得意とすることを行える。 ### 4. APIレイヤー（クエリインターフェース） APIレイヤーは、アプリケーションがインデックス済みデータにアクセスするための手段だ。APIはエンドポイントを公開し、アプリがデータベーススキーマ、インデックスロジック、データ変換の複雑さを気にすることなく、処理済みのブロックチェーンデータをクエリできるようにする。 一般的なアプローチには以下がある。 - **GraphQL API**: GraphQL APIは最も柔軟な選択肢であり、クライアントが単一のクエリで必要なデータをちょうど過不足なくリクエストできる。複数のREST呼び出しを行う代わりに、アプリケーションはネストされた関連データを1回のリクエストで要求できる。例えば「このアドレスの、値が> $1,000であるすべてのERC-20転送を取得し、各転送についてトークン名、シンボル、小数点桁数、現在価格を含めて」といったリクエストだ。GraphQLではクライアントがどのフィールドを返すか指定できるため、オーバーフェッチ（不要なデータの取得）やアンダーフェッチ（複数回の往復が必要になること）を避けられる。これは複数のエンティティにまたがる複雑なクエリで特に強力だ。例えば[The Graphプロトコル](https://thegraph.com/)は、完全にGraphQLの上に構築されている。 - **REST API**: REST APIはよりシンプルで予測しやすく、一般的なクエリ用に事前定義されたエンドポイントを持つ。各エンドポイントには特定の目的があり、例えばトランザクション履歴を取得する`/api/address/\{address\}/transactions`や、現在の全トークン保有者を取得する`/api/token/\{contract\}/holders`などが用意される。RESTはキャッシュしやすく（各URLが特定のリソースを表すため）、ドキュメント化もしやすく、ほとんどの開発者にとってなじみがある。トレードオフは柔軟性の低さで、エンドポイントが提供していないデータが必要な場合は、複数回のリクエストを行うか、新しいエンドポイントが構築されるのを待つ必要がある。RESTは、クエリパターンがよく知られており一貫している場合に最適だ。 - **WebSocketストリーム**: WebSocketストリームは、新しいブロックがインデックスされるたびのリアルタイム更新に最適だ。数秒ごとにAPIをポーリングして「何か新しいものはある?」と尋ねる代わりに、アプリはWebSocket接続を開いておき、特定のアドレスがトランザクションを受け取った瞬間など、関連データが到着した瞬間にプッシュ通知を受け取る。これは、ライブ取引ダッシュボードやリアルタイム通知システムなど、即時の更新を必要とするアプリケーションにとって重要だ。WebSocketは接続を開いたままにするため、たまに行われるREST呼び出しよりリソース消費は大きいが、時間に敏感なデータのレイテンシを排除できる。 APIレイヤーには、単にデータを提供するだけでなく重要なインフラ機能が含まれることが多い。キャッシング（頻繁にリクエストされるクエリ結果をメモリに保存し、データベースへの繰り返しのアクセスを避け、人気のクエリのレスポンス時間を大幅に改善する）、レート制限（単一のユーザーが過剰なリクエストでシステムを圧倒するのを防ぎ、全員に公平なアクセスを保証する）、認証（利用状況の追跡、アクセス制御の適用、プレミアム階層への課金の可能性のためのAPIキーやトークン）などだ。こうした機能により、APIは高速性、信頼性、経済的な持続可能性を維持でき、特に数千のアプリを同時に提供する場合には重要となる。 ## **インデクサーの各コンポーネントがどう連携するか** 実際の流れの例を示す。インデクサーのデータソースがEthereumノードからブロック#18,500,000を取得する。次にインデックスエンジンがそのブロック内の200件のトランザクションをデコードし、500件のイベント（Uniswapのスワップや NFT転送を含む）を抽出し、影響を受けたウォレットを特定する。 その後、データベースはこれらのレコードを、アドレス、トークンコントラクト、タイムスタンプにインデックスを付けて保存する。そこから、あなたのアプリがインデクサーのAPIに「今週、アドレス`0x123`によって行われた全NFT購入を表示して」とクエリを送る。APIはブロックチェーンではなくインデックス済みデータベースをクエリすることで、50ミリ秒で結果を返す。 このアーキテクチャこそが、何時間もかかるブロックチェーンのスキャンをミリ秒単位のクエリ時間に変えることを可能にしている。 ## 実際にインデックス処理はどのように行われるか 各コンポーネントを理解したところで、実際にインデックス処理がどのように動作するのか、そしてインデクサーがどのように生のブロックチェーンデータを即座にクエリ可能な情報に変換するのかを見ていこう。 ### 実例: DeFiレンディングプロトコルのインデックス処理 [Aave](https://aave.com/)や[Compound](https://compound.finance/)のようなプラットフォームの仕組みに似た、簡略化されたレンディングプロトコルのスマートコントラクトを使った具体例を見てみよう。このコントラクトでは、ユーザーが担保を預け入れ、資産を借りることができる。 Position) public positions; uint256 public nextPositionId; event PositionOpened( uint256 indexed positionId, address indexed user, address collateralToken, uint256 collateralAmount, address borrowedToken, uint256 borrowedAmount, uint256 interestRate ); event PositionClosed( uint256 indexed positionId, address indexed user, uint256 amountRepaid ); event PositionLiquidated( uint256 indexed positionId, address indexed liquidator, uint256 collateralSeized ); function openPosition( address collateralToken, uint256 collateralAmount, address borrowedToken, uint256 borrowedAmount, uint256 interestRate ) external { uint256 positionId = nextPositionId++; positions[positionId] = Position({ user: msg.sender, collateralToken: collateralToken, collateralAmount: collateralAmount, borrowedToken: borrowedToken, borrowedAmount: borrowedAmount, interestRate: interestRate, timestamp: block.timestamp }); emit PositionOpened( positionId, msg.sender, collateralToken, collateralAmount, borrowedToken, borrowedAmount, interestRate ); } function closePosition(uint256 positionId, uint256 amountRepaid) external { require(positions[positionId].user == msg.sender, "Not position owner"); emit PositionClosed(positionId, msg.sender, amountRepaid); delete positions[positionId]; } }`} /> インデクサーがなければ、このプロトコルに関する問いに答えるのは大変な作業になる。 - 「全ポジションにわたる総ロック価値は?」これにはすべてのブロックをスキャンし、すべての`PositionOpened`イベントを見つけ、それぞれをデコードし、担保の合計を計算する必要がある。 - 「ユーザー0x123の全ポジションを表示して」これも、ユーザーアドレスでフィルタリングするために全体スキャンが必要になる。 - 「ETH担保のローンの平均金利は?」これにも、担保トークンでフィルタリングし金利を集計するために全体スキャンが必要になる。 - 「今週清算されたポジションはいくつあったか?」これには、`PositionLiquidated`イベントを探すために1週間分のブロックをスキャンする必要がある。 これらのクエリはそれぞれ数分から数時間かかる可能性があり、数ギガバイトのブロックチェーンデータを処理する必要がある。 インデクサーがあれば、以下のようになる。 1. **イベント検知**: インデクサーはLendingProtocolコントラクトのアドレスを監視する。ブロック#18,500,000に`PositionOpened`イベントを発行するトランザクションが含まれると、インデクサーは即座にそれを取得する。 1. **データ抽出**: コントラクトのABIを使って、インデクサーはイベントのパラメータをデコードする。`positionId=42`、`user=0xabc...`、`collateralToken=0xWETH`、`collateralAmount=5000000000000000000`（5 ETH相当のwei）、`borrowedToken=0xUSDC`、`borrowedAmount=8000000000`（8,000 USDC）、`interestRate=500`（5%）。 1. **エンリッチメント**: インデクサーは、ETHやUSDCの現在のUSD価格を調べてポジションの価値をドル建てで計算したり、時間ベースのクエリのためにブロックのタイムスタンプを保存したりといった追加のコンテキストを取得することで、このデータを強化できる。 1. **保存**: これを複数のインデックスとともにデータベースに書き込む。 5.**APIによる提供**: これで、複雑なクエリがシンプルで高速なデータベースルックアップになる。 - 「総ロック価値は?」→ `SELECT SUM\(collateral\_amount \* token\_price\) FROM lending\_positions WHERE status='open'`（10ミリ秒で返る） - 「ユーザー0x123のポジションは?」→ `SELECT \* FROM lending\_positions WHERE user\_address='0x123'`（即座） - 「ETHローンの平均金利は?」→ `SELECT AVG\(interest\_rate\) FROM lending\_positions WHERE collateral\_token='0xWETH'`（ミリ秒単位） インデクサーはこのプロセスを新しいブロックごとに継続的に繰り返し、プロトコルの完全な状態と履歴のリアルタイムでクエリ可能なビューを維持する。`PositionClosed`イベントが発生すると、ステータスフィールドが更新される。価格が変動すると、清算監視のためにポジションの健全性比率を再計算できる。 この、逐次的なブロックチェーンスキャンからインデックス済みデータベースクエリへの変換こそが、現代の暗号フィンテックダッシュボード、分析プラットフォーム、リスク監視ツールを可能にしているものだ。インデクサーがなければ、ブロックチェーンアプリケーションに期待するようなユーザー体験は単純に存在しえない。 ## インデクサーはどのような問題を解決するのか レンディングプロトコルの例でインデックス処理がどのように動作するかを見たところで、開発者にとってインデクサーが解決する根本的な問題をまとめてみよう。 - **データアクセスとクエリ性能**: ブロックチェーンには組み込みの検索機能がなく、データをクエリするには数百万のブロックを逐次スキャンする必要がある。インデクサーはブロックチェーンデータを抽出し、戦略的なインデックスを付けたクエリ可能なデータベースに整理することで、何時間もかかるスキャンをミリ秒単位のクエリに変える。 - **データ分析**: 大規模なアクティビティ（取引高、ユーザーパターン、プロトコルの健全性）を理解するには、膨大なデータセットの集計が必要となる。インデクサーは過去の状態を維持し、一般的な指標を事前計算する。DEXの日次取引高はすでに合計されており、プロトコル変更後の非アクティブなウォレットはインデックス済みのタイムスタンプを介して即座にクエリできるため、カスタムのデータパイプラインを構築する必要がなくなる。 - **リアルタイムアプリ開発**: 現代のアプリは、ユーザーに正確でパフォーマンスの高い体験を提供するために、オンチェーンイベントに即座に反応しなければならない。ブロックチェーンノードを常にポーリングするのは遅く非効率だ。インデクサーはプッシュ型のアーキテクチャ（WebSocket）を使い、イベントが発生した瞬間にアプリケーションに通知することで、ブロックチェーンアプリをweb2並みにレスポンシブに感じさせる。 ## 一般的なインデックス処理のユースケース なぜインデクサーが存在するのかを理解することで、それを使って実際に何を構築できるのかが明確になる。以下は、インデックス済みブロックチェーンデータを活用した実世界のアプリケーションだ。 - **DeFiダッシュボードとポートフォリオ管理**: [Zapper](https://zapper.xyz/)、[Debank](https://debank.com/)、[Zerion](https://zerion.io/)のようなアプリは、数十のプロトコルにまたがるユーザーのポジション、[Aave](https://aave.com/)でのレンディングポジション、[Uniswap](https://uniswap.org/)での流動性プール、[Lido](https://lido.fi/)でのステーキング資産などを、ライブのUSD評価額とともに単一のポートフォリオビューに集約する。インデクサーがなければ、各ページの読み込みごとに何百ものスマートコントラクトを個別にクエリする必要があるだろう。 - **高度な検索機能を持つマーケットプレイス**: [OpenSea](https://opensea.io)のようなプラットフォームでは、ユーザーは特定の属性でコレクションをフィルタリングし、レアリティランキングでソートし、完全な所有履歴を閲覧し、フロア価格の推移を時系列で追跡できる。インデクサーがあることで、数百万のERC-721にまたがるこうした複雑なクエリが、検索のたびにブロックチェーン全体をスキャンすることなく可能になっている。 - **オンチェーン分析プラットフォーム**: [Dune](https://dune.com/home)、[Nansen](https://www.nansen.ai/)、[Flipside Crypto](https://flipsidecrypto.xyz/home/)のようなツールは、プロトコル指標を示すカスタムダッシュボードを提供し、DEXの取引高、レンディングプロトコルの利用率、チェーン間のブリッジフロー、クジラウォレットの動きを追跡する。アナリストは生のブロックチェーンログを処理する代わりに、インデックス済みデータに対してSQLクエリを書く。 - **トレーディングボットとMEV戦略**: 自動取引システムは、裁定機会を探すためにmempool内のトランザクションを監視し、最適なルーティングのために複数のDEXにわたる流動性プールの準備金を追跡し、トリガーとなるイベントから数ブロック以内に戦略を実行する。これには、インデクサーだけが大規模に提供できるサブ秒単位のデータアクセスが必要となる。 - **ウォレット**: [MetaMask](https://metamask.io/)、[Rainbow](https://rainbow.me)、[Phantom](https://phantom.com/)のような現代のウォレットは、完全なトランザクション履歴、トークン残高（自分が持っていることに気づいていなかったトークンも含む）、保留中のトランザクション、推定ガス代を表示する。これらの機能はいずれもインデックス済みデータに依存しており、ブロックチェーンノードに直接クエリするとウォレットのインターフェースは使い物にならないほど遅くなってしまう。 - **ブロックチェーンエクスプローラー**: [Etherscan](https://etherscan.io/)、[Solscan](https://solscan.io/)、および類似のエクスプローラーでは、ユーザーは任意のアドレス、トランザクションハッシュ、ブロック番号、トークンコントラクトを検索して、完全な詳細、関連トランザクション、過去のアクティビティを即座に確認できる。これらは本質的に、包括的なブロックチェーンインデクサーの上に構築されたUIレイヤーだ。 - **DAOガバナンスプラットフォーム**: [Snapshot](https://snapshot.org/)や[Tally](https://www.tally.xyz/)のようなツールは、提案のライフサイクル、特定のブロック時点でのトークン保有量に基づく投票権の計算、委任関係、投票履歴を追跡する。こうしたプラットフォームは、過去の提案に対して誰が投票資格を持っていたかを計算するために、インデックス済みの過去の状態を必要とする。 - **リスク管理とモニタリング**: プロトコルはインデクサーを使って、清算リスクのある大口ポジションを監視し、セキュリティアラート用に異常なウォレットのアクティビティパターンを追跡し、トランザクションパターンを分析することでスマートコントラクトの潜在的な悪用を特定し、特定のオンチェーン条件が満たされたときにアラートを生成する。 - **クロスチェーンブリッジ**: チェーン間の資産移動を仲介したり、複数のネットワークにまたがる最適なスワップ経路を見つけたりするアプリケーションは、手数料の計算、レートの比較、転送ステータスの追跡のために、各ブロックチェーンからのリアルタイムのインデックス済みデータを必要とする。 ## 2025年の主要インデクサー インデックス処理の分野には、分散型プロトコルからフルマネージドサービスまで、幅広い選択肢がある。以下、主要な選択肢を紹介する。 ### The Graph [The Graph](https://thegraph.com/)は、最も広く採用されている分散型インデックスプロトコルだ。開発者は「サブグラフ」を定義する。これは、どのスマートコントラクトを監視し、そのデータをどのようにクエリ可能な形式に変換するかを指定するカスタムのインデックス設定だ。独立したノードオペレーターがインデックスインフラを運用し、クエリに応じることでGRTトークンを獲得する。The Graphは、検閲耐性を重視し、中央集権型のサービスプロバイダーではなく分散型インフラに依存したいプロジェクトに最も適している。 ### Goldsky [Goldsky](https://goldsky.com/)は、90を超えるブロックチェーンをサポートするインフラプラットフォームで、カスタムのデータパイプラインに重点を置いている。複雑なデータ変換、外部データベースへのブロックチェーンデータのストリーミング、分析ワークロード用のデータウェアハウスへのデータ供給を得意とする。GoldskyはGraph互換のサブグラフホスティングと、リアルタイムのデータストリーミング用の独自のMirrorパイプラインシステムの両方を提供する。標準的なGraphQLクエリを超えたカスタムのビジネスロジックを伴うマルチチェーンのインデックス処理を必要とするチームに適している。 ### Chainstack [Chainstack](https://chainstack.com/)は、Subgraphsをマネージドサービスとして提供するエンタープライズグレードのブロックチェーンインフラプロバイダーだ。稼働率保証付きのSLA、低レイテンシクエリのためのグローバルCDN配信、専用のサポートチャネルを備えた信頼性の高いインデックス処理を提供する。このプラットフォームはEthereumおよびEVM互換チェーンをサポートし、Chainstackのより広範なノードインフラサービスとも統合する。Chainstackは、エンタープライズサポート、コンプライアンス機能、予測可能なスケーリングを必要とする組織に特に強い。 ## プロジェクトに合ったインデクサーの選び方 適切なインデクサーの選択は、あなたの具体的な要件次第だ。考慮すべき主な要因を以下に挙げる。 **1. チェーンの互換性** インデクサーによってサポートするブロックチェーンエコシステムは異なるため、選んだインデクサーが構築したいチェーンをサポートしているか確認しよう。Solanaのような特定のネットワークに特化したものもあれば、EVM互換チェーンに重点を置いたもの、あるいは幅広いマルチチェーン対応を提供するものもある。 **2. クエリ要件** インデクサーは、ニーズに応じて異なるクエリインターフェースを提供する。柔軟なネストされたクエリ用のGraphQL、シンプルな事前定義エンドポイント用のREST、分析ワークロード用のSQL、リアルタイムストリーミング用のWebSocketだ。アプリケーションがどのようにデータにアクセスするかを検討し、そのパターンをサポートするインデクサーを選ぶこと。 **3. パフォーマンス要件** レイテンシとスループットの要件を慎重に検討すること。一部のインデクサーはリアルタイムアプリケーション向けに速度を優先し、他のものは包括的な履歴データアクセスや大量の分析クエリに重点を置いている。 **4. インフラの方針** 運用負荷は軽減されるがベンダー依存が生じるフルマネージドサービスにするか、検閲耐性を提供するがより多くのセットアップと保守を必要とする分散型プロトコルにするかを決めること。 **5. コスト構造** ほとんどのインデクサーは段階的な価格設定を提供している。開発用の無料プラン、成長中のプロジェクト向けの従量課金制、本番ワークロード向けのエンタープライズプランだ。長期的なコストを見積もる際には、予想されるクエリ量やデータのエグレス料金も考慮に入れること。 **6. 開発者体験** ドキュメントの質、希望するプログラミング言語向けのSDKサポート、コミュニティリソースの充実度を評価すること。強力な開発者サポートと明確な例は、統合にかかる時間を大幅に削減しうる。 **7. データの専門性** NFTマーケットプレイスやSolanaアプリケーションのような特定のユースケースでは、専用のインデクサーが汎用ソリューションよりもすぐに使える豊富なデータを提供することが多い。あなたの分野向けに事前にエンリッチされたデータが、開発の労力を大幅に節約できるかどうかを検討すること。 ## まとめ 大規模にオンチェーンデータを扱うことは難しい問題だ。ブロックチェーンは、現代のアプリケーションが必要とする種類のクエリ、つまり数百万のトランザクションにまたがる検索・フィルタリング・集計向けには構築されていない。適切なインフラなしでは、こうした処理はアプリの動作を止めてしまうだろう。 インデクサーは、この問題を面倒な作業を引き受けることで解決する。ブロックチェーンデータを継続的に処理し、それをクエリ可能な形式に整理し、高速なAPIを通じて提供する。これにより、データパイプラインやブロックチェーンノードと格闘する代わりに、優れたアプリケーションの構築に専念できるようになる。 始める準備はできただろうか。Alchemyは、ブロックチェーン開発をシンプルにするために設計された、包括的なツール群とエンリッチされたAPI群を提供している。構築を始めるには、[Alchemyのドキュメント](https://www.alchemy.com/docs/)を確認してほしい。 ## よくある質問 ### ブロックチェーンインデクサーとは何か ブロックチェーンインデクサーは、ブロックチェーンを継続的に監視し、トランザクションデータとスマートコントラクトのイベントを抽出し、それを構造化されたフォーマットに変換し、高速クエリ用に最適化されたデータベースに保存する専用サービスだ。 ### ブロックチェーンインデクサーはどのように動作するか インデクサーは3段階のプロセスに従う。抽出（ブロックチェーンノードをリアルタイムで監視する）、変換（生のブロックチェーンデータをデコードし、状態変化を整理する）、ロード（処理済みデータをクエリ可能なデータベースに保存し、アプリケーションが利用できるAPIを提供する）だ。 ### ブロックチェーンインデクサーの主要な構成要素は何か 中核的な構成要素には、データソース（ブロックチェーンとの接続）、インデックスエンジン（トランザクションとイベントをデコードする処理レイヤー）、データベース（PostgreSQLやMongoDBのようなストレージレイヤー）、APIレイヤー（GraphQL、REST、WebSocketを使ったクエリインターフェース）が含まれる。 ### なぜブロックチェーンデータを直接クエリできないのか ブロックチェーンは、高速な検索ではなくセキュリティのために最適化された、ブロックの線形なチェーンとしてデータを保存している。組み込みのSQLもインデックスもないため、特定のデータを見つけるには数百万のブロックを一つずつスキャンする必要があり、これには何時間、あるいは何日もかかることがある。 ### ブロックチェーンインデクサーは開発者のどのような問題を解決するか インデクサーは、何時間もかかるブロックチェーンスキャンをミリ秒単位のクエリに変え、膨大なデータセットにわたるリアルタイムの分析や集計を可能にし、ブロックチェーンアプリを従来のwebアプリケーションと同じくらいレスポンシブに感じさせるプッシュ型アーキテクチャを提供する。 ### ブロックチェーンインデクサーの一般的なユースケースは何か 代表的なアプリケーションには、DeFiダッシュボードやポートフォリオトラッカー、オンチェーン分析プラットフォーム、トレーディングボット、現代のウォレット、ブロックチェーンエクスプローラー、クロスチェーンブリッジなどがある。 ### 自分のプロジェクトに適したインデクサーをどう選べばよいか チェーンの互換性、クエリ要件（GraphQLかRESTかSQLか）、パフォーマンス要件、インフラの方針（マネージドか分散型か）、コスト構造、開発者体験の質、そしてユースケースに特化したデータが必要かどうかを考慮すること。 ### インデクサーとフルノードの運用の違いは何か フルノードはブロックチェーン全体を保存し、直接クエリするには大きなリソースを必要とするが、インデクサーはAPI経由でのサブ秒単位の取得のためにデータを事前処理・最適化し、遅い手動のブロックチェーンスキャンを不要にする。