COLUMN

ネットワークインデクサのブログシリーズの2回目です。今回は、ネットワークインデクサの仕組みについて、より詳しく掘り下げていきます。前回の記事はこちらからご覧いただけます：ネットワークインデクサの紹介

今年初め、Protocol Labsは、FilecoinやIPFSネットワーク上のストレージプロバイダーからコンテンツアドレス可能なデータのリトリーブを可能にする、最初の量産型ネットワークインデクサを発表しました。現在、140社以上のストレージプロバイダーがインデクサにデータを公開し、4つの本番インデクサノードがパートナーと共に稼働しており、6B以上のコンテンツID（CID）のインデックスを作成しています。インデクサノードがFilecoinとIPFSの間でより多くのコンテンツを処理するにつれて、クライアントはインデクサに問い合わせ、識別されるコンテンツをどこで取得できるかを知ることができます。

概要

Filecoinは膨大な量のデータをストレージしていますが、適切なインデックスがなければ、クライアントは効率的なリトリーブを行うことができません。Filecoinのコンテンツを容易に発見するため、CIDマルチハッシュとコンテンツプロバイダレコードのマッピングするインデクサノードが開発されました。クライアントは、CIDまたはマルチハッシュを使用してプロバイダーのレコードを検索し、そのプロバイダーのレコードを使用してストレージプロバイダーからデータを取得します。要するに、インデクサは次の2つのユーザーグループにとって、特殊なデータ管理システムとなります。

• ストレージプロバイダーは、インデクサにデータを格納することで、利用可能なコンテンツを宣伝します。これは、インデクサの取り込みロジックによって処理されます。
• リトリーブクライアントはインデクサに問い合わせ、どのストレージプロバイダーがそのコンテンツを持っているか、そしてどのようにそれを取得するか（すなわちグラフシンク（ピア間でグラフを同期）、ビットスワップなど）を調べます。これは、インデクサのリトリーブロジックで処理されます。

この記事では、インデクサの構成要素がどのように相互作用し、どのようにインデックスが取り込まれ、ストレージされ、ネットワーク上で共有されるかについて見ていきます。

インデクサーの相互作用

では、これら2つのユーザータイプは、どのようにインデクサと相互作用するのでしょうか？

まず、ストレージ契約が結ばれ、データはストレージプロバイダーによってストレージされます。ストレージプロバイダーは、新しいコンテンツが利用可能になったことを、gossip pubsub上で広告レコードのCIDを公開することで知らせます。通常、メインネットノードが中継を行います。あるいは、HTTPで直接インデクサに送信することもできます。インデクサノードは互いに中継し合うことも可能です。

それから、インデクサはストレージプロバイダから新しいコンテンツを同期させます。このとき、すでに見た広告やチェーンの終端までを取得します。また、新しい広告ごとに、contextID、メタデータ、コンテンツのマルチハッシュチャンクチェーンを取得します。

コンテンツがインデックス化されると、リトリーブクライアントは、見つけたいデータのCIDまたはマルチハッシュを使用してプロバイダデータを見つけることができます。インデックス作成者は、各CIDのプロバイダレコードのリストと、最新のプロバイダアドレスを返信します。

次に、クライアントはプロバイダレコードに示されたプロトコル（例：グラフシンクやビットスワイプ）を用いてストレージプロバイダーからコンテンツを取得します。次に、クライアントはプロバイダーレコードを送信し、プロバイダーはcontextIDとメタデータを使用してコンテンツを検索します。

この図は、インデクサーのエコシステムにおけるさまざまなアクターと、それらがどのように相互作用するかをまとめたものです。

インデクサのエコシステムのアクター

インデックスの取り込み

インデックスの取り込みは、2つの部分から構成されます。

1. 発行：インデックス広告が利用可能であることを、インデクサに知らせます。
2. 同期：インデックスデータをそのデータの発行元から取得します。公開されたインデックスデータとインデクサを同期させます。

アナウンスメッセージは、広告が利用可能であることをインデクサに通知します。これはパブリッシャーからインデクサへ、gossip pubsub（ほとんどの場合）又はHTTPを介して送信されます。アナウンスメッセージには、広告のCIDとパブリッシャーのアドレス（広告を取得する場所）が含まれています。インデックス作成者は、すでにその広告をインデックスしている場合、アナウンスを無視します。

広告は順番に処理され、ブロックチェーンのような構造を作るために署名されます（リンクを含む）。プロバイダーまたは許可された発行者によって署名されます。

広告では、ContextIDが提供者の特定のメタデータを識別します。ContextIDは、メタデータの更新、プロバイダーレコードへのマルチハッシュマッピングの追加、プロバイダーレコードとそれへのマルチハッシュマッピングの削除に使用されます。メタデータはプロトコル識別子に加え、データ取得時にストレージ提供者に転送される追加データを含みます。ストレージプロバイダーはメタデータを使用して取得するデータを探します。メタデータには、ディールID、内部レコードキーなどが含まれることがあります。

次の図は、広告とマルチハッシュデータの構造を示しています。

データストレージ

インデクサデータストアの設計では、多くのマルチハッシュが比較的少数のプロバイダーレコードに対応します。マルチハッシュは、そのマルチハッシュで識別されるコンテンツが利用可能な場所を記述したプロバイダーレコードを検索するために使用されます。プロバイダIDおよびコンテキストIDは、特定のプロバイダレコードを検索するために使用されます。

プロバイダデータは、それに対応するマルチハッシュとは独立して更新・削除することができます。プロバイダーデータはプロバイダーIDおよびコンテキストIDによって識別されます。コンテキストIDはプロバイダーデータの値の一部としてインデクサコアに渡されます。プロバイダーデータオブジェクトが更新されると、それ以降のすべてのマルチハッシュクエリーはそのデータの新しい値を返します。

一意のプロバイダーレコードは、プロバイダIDとレコードのコンテキストIDのハッシュであるプロバイダキーによって検索されます。同じコンテンツが異なるプロバイダーにストレージされていたり、同じプロバイダで別々のディールが含まれていたりすることがあるため、マルチハッシュは複数のプロバイダーレコードにマッピングされることがあります。インデクサコアは、各マルチハッシュをプロバイダーキーのリストにマッピングし、各プロバイダーキーをプロバイダーレコードにマッピングします。

この図は、インデクサデータストアの2レベルマッピング設計を表しています。

レベル2のインデクサのデータストアマッピング

データの共有

さらに、インデクサは、このように設定されていれば、さまざまな種類のデータを互いに共有することができます。

• インデクサは、他のインデクサからプロバイダーやパブリッシャを発見することができます。
• インデクサはHTTPアナウンスを他のインデクサに再パブリッシュできます。
• インデクサはゴシップpubsubアナウンスを中継することができます。

リソース

もしあなたがインデクサネットワークに参加することに興味があったり、インデクサについてもっと知りたいのであれば、以下のリソースが役に立つかもしれません。

• cid.contact（コンテンツルーティングのホームページ)
• docs.cid.contact（インデクサgitbook）。
• storetheindex（ファイルコインのスラックチャンネル)
• インデクサの実装
• バリューストアの実装
• インデクサ同期用ライブラリ

本ブログは、www.filecoin.io/blogからの翻訳となります。

ソース：https://filecoin.io/blog/posts/how-does-the-network-indexer-work/