インデックスプロバイダーになるには

このブログは、ネットワークインデクサーに関する一連の記事の3つ目のブログ記事です。最初のブログではネットワークインデクサーのコンセプトを紹介し、2つ目のブログでは、何十億ものアドレス可能なコンテンツに対してコンテンツプロバイダーを見つけることを可能にするために、それが内部でどのように機能しているのかを深く掘り下げました。

このブログ記事では、これまでの投稿を基に、ネットワークインデクサーのインデックスプロバイダーになる方法と、インデックスプロバイダーになる方法について、詳しく説明したいと思います。

インデックスプロバイダーとは何ですか？

インデックスプロバイダーとは、基本的にコンテンツプロバイダーであり、さらに2つのことを行います。

1. マルチハッシュを宣伝することによって、ネットワークにどのようなコンテンツがあるのかを知らせる。
2. コンテンツを取得するための追加情報を提供する。

プロセスの概要

以下は、典型的なインデックスプロバイダーが取る手順の概要である。

コンテンツです。新しいアドレス指定可能なコンテンツがプロバイダに保存されることがある。プロバイダはコンテンツのCID（エントリー）からマルチハッシュを抽出する。

1. 広告を生成する。プロバイダは、エントリーを、コンテンツを取得する方法に関するメタデータとともに、Advertisementと呼ばれるデータ構造で組み立てる。
2. 検索可能な広告。プロバイダーは、他のコンテンツと同様に広告を保存し、検索に利用できるようにする。アドバタイズメント自体はアドレス指定可能なコンテンツである。
3. アナウンス（オプション）。プロバイダは、アドバタイズされる新しいコンテンツがあることをネットワークにアナウンスする。アナウンスは2つの方法で公開されることがある。
4. Gossipsubアナウンス
   1. Gossipsubアナウンスメント: 有名なgossipsubトピックに公開されます。デフォルトでは/indexer/ingest/mainnet over libp2pです。
   2. HTTPアナウンス。HTTPトランスポートプロトコルを介して、既知のネットワークインデクサインスタンスに明示的なPUTリクエストが行われます。

インデックス作成ノードはアナウンスメッセージを聞き、それに反応し、最終的にネットワークインデクサによるコンテンツのインデックス作成につながるアドバタイズメント取り込み機構を起動します。

各ステップをより深く掘り下げてみましょう。

広告の生成

広告とは、プロバイダがホストするコンテンツに関する情報をネットワーク・インデクサに伝えるコード・データ構造です。以下のスニペットは、このデータ構造の概要を IPLD スキーマ形式で示しています。

type Advertisement struct {

PreviousID optional Link

Provider String

Addresses [String]

Signature Bytes

Entries Link

ContextID Bytes

Metadata Bytes

IsRm Bool

ExtendedProviders

}

ここでは、それらの各フィールドが何を表しているかを簡単に説明します。

• 前回のID：前の広告への IPLD リンク。リンクがない場合は、その広告がチェーンの中で最も古いものであることを表します。
• プロバイダ：コンテンツプロバイダのlibp2pピアID
• アドレス：コンテンツを取得することができるアドレスのリスト
• 広告の署名：コンテンツプロバイダの ID で署名されている。
• エントリーコンテンツプロバイダがホストしているコンテンツのハッシュを取得するエントリへの IPLD リンク。
• ContextID：コンテンツプロバイダが公開する広告のメタデータを一意に識別するキー。
• メタデータ：データが検索可能なプロトコルの符号化された記述。
• IsRm：アドバタイズが、以前にアドバタイズされたコンテンツを削除するかどうか。
• ExtendedProviders：データの代替プロバイダのリスト。

広告チェーン

広告が連鎖しており、各広告は事実上プロバイダがホストするコンテンツの差分となる。すべての広告を一緒に収集すると、ホスト上のすべてのマルチハッシュの完全なリストを表します。次の図は、広告がどのように連鎖されるかを示しています。

エントリー

エントリーは、コンテンツプロバイダーによってホストされているミューリハッシュのリストをキャプチャします。次のような構造にすることができる。

• EntryChunk 、または
• HAMT

Entry Chunk チェーン

EntryChunk チェーンは以下の IPLD スキーマを使用します。

type EntryChunk struct {

Entries [Bytes]

Next optional link

}

アドバタイズメントと同様に、EntryChunkもIPLDリンクを使用してマルチハッシュのリストのページ分割を容易にする方法として、一緒にチェーンされています。主なEntriesリストは、アドバタイズメントのマルチハッシュの配列である。広告がデータ転送の目的で単一ブロックに収まるより多くのCIDを有する場合、それらは次のチャンクへの参照としてNextを使用することによって、概念的にリンクリストである複数のチャンクに分割されるかもしれない。

具体的な制約としては、各EntryChunkは4MB以下であるべきで、EntryChunkのリンクリストは400チャンク以下の長さであるべきです。これらの制約を超えると、エントリーのリストは複数の広告に分割される必要があります。実用的には、個々の広告が最大約4000万個のマルチハッシュを保持できることを意味する。

HAMT

HAMTは、HAMT ADLのIPLD仕様に従わなければならない。HAMTデータ構造は、アドバタイズされるマルチハッシュのリストをキャプチャするためのセットとして使用されます。これは、HAMTのキーがアドバタイズされるマルチハッシュを表し、値は単純に真に設定されるところです。

https://github.com/ipld/go-ipld-adl-hamt

https://ipld.io/specs/advanced-data-layouts/hamt/spec/

エントリー・チャンクチェーン対HAMT

広告のエントリーを表現するために、どちらのデータ構造も使用することができます。しかし、どちらを選ぶべきかはユースケースによって異なります。

Entry Chunk Chainはよりシンプルで、それぞれがマルチハッシュの配列を持つIPLDノードの連鎖です。マルチハッシュはソートされていません。つまり、たとえば特定のプレフィックスを持つすべてのマルチハッシュのリストを取得するには、チェーン全体をインジェストする必要があります。次のチャンクへのリンクは1つだけなので、チャンクは厳密な順序に従いますが、並列にトラバースすることはできません：次のリンクをトラバースすることによってのみ、次のリンクを知ることができます。

一方、HAMTはマルチハッシュを整理するために特殊なマップデータ構造を使用します。そのため、特定の接頭辞を持つマルチハッシュを効率的に探索することができます。これは、例えば、複数のノードに責任を分散させるような場合に非常に便利です。一方、より複雑なデータ構造であり、マルチハッシュの総数を把握し、ビット幅とバケットサイズに適切なHAMT値を選択するための研究が必要です。

メタデータ

メタデータは、データを取得するためのプロトコルに関する情報を取得する。これはプロトコル ID であり、残りのバイトをどのようにデコードするかのヒントになります。メタデータは拡張可能であるように設計されており、データの取得者がプロトコルIDを理解できる限り、どのようなプロトコルでもサポートすることができる。インデクサノードはこれを単純にバイトの配列として扱い、最大1KiBというサイズ制限を持つ。

このフィールドは複数のプロトコルIDのエンコーディングをサポートしており、プロトコルセクションはプロトコルIDの値の昇順で表示されることが要求される。現在、2つのウェルが存在する。

よく知られているプロトコルIDは次の2つである。

• Bitswap: これは単純に値 0x0900 の固定バリントで、それ以上のバイトはない。
• GraphsyncFileCoinV1：プロトコル ID 0x0910 を使用し、CBOR としてエンコードされた以下の情報をカプセル化することによって、Filecoin ストレージプロバイダーからコンテンツをダウンロードする方法を指定します。

type GraphsyncFilecoinV1 struct {

PieceCID Link

VerifiedDeal Bool

FastRetrieval Bool

}

通常、プロトコルIDはmulticodec CSVテーブルに追加されます。しかし、これは厳密には必須ではありません。検索クライアントはメタデータを理解するので、独自のプロトコルを独自のオーダーメイドの衝突しないプロトコルIDで自由にエンコードすることができます。

広告のアナウンス

広告が形成されると、その存在を伝え、結果としてネットワークインデクサによる広告の実際のコンテンツのポーリングをトリガするために、インデックスプロバイダによってアナウンスが行われる。アナウンスは2つの方法で送ることができる。

• GossipSub、または
• HTTPの直接アナウンス

インデクサがすでに告知プロバイダについて知っている場合、新しい広告ごとに告知することは厳密には必要ない。

GossipSub アナウンスメント

GossipSub アナウンスは libp2p gossipsub プロトコルを使って、 /indexer/ingest/mainnet というよく知られたトピック上で行われます。インデックス作成ノードは、そのトピックで公開されたメッセージを聞き、 検出します。

1. 最新のアドバタイズメントCIDが何であるか、そして
2. どこから取得できるのか。

その後、ピアに連絡してアドバタイズメントチェーンのフェッチを開始する。

HTTPアナウンス

直接的なHTTPアナウンスは、コンテンツプロバイダ側でよく知られたインデクサーのエンドポイントが設定されることを必要とします。いったんアドバタイズが形成されると、コンテンツプロバイダはよく知られたエンドポイントである /ingest/announce に、gossipsub メッセージと同じ情報を含むリクエストのボディを持つ PUT リクエストを送信します。

204 Acceptedで応答し、広告チェーンを取得するために受動的にピアを呼び出します。

広告のフェッチ

これは、インデクサノードがスケールして、多数のプロバイダーからコンテン ツをフェッチできるようにするための、重要な設計上の決定である。広告フェッチを受動的にすることで、インデクサノードは、多くのプロ バイダーアナウンスがある場合に、フェッチ要求をバッチ処理する機会を得 ることができます。

また、インデクサがフェッチする内容を制御することもできます。インデクサノードは、最後に処理された広告のCIDを内部で追跡することにより、以前に見たことのない広告チェーンの部分のみをフェッチすることができます。

フェッチを容易にするために、プロバイダーは、インデクサノードがアクセスできるエンドポイントを公開する必要がある。現在、2つのトランスポートプロトコルがサポートされています。

• HTTP、および
• GraphSyncによるデータ転送

アナウンスメッセージは、コンテンツプロバイダがどのトランスポートプロトコルを提供しているかという情報を運ぶだろう。

広告コンテンツの変更

プロバイダは、再広告の必要性を緩和した特別な広告によって、広告しているコンテンツの状態を変更することができます。これは、毎回エントリーを再広告することなく、効率的に変更できるようにするためである。

ここでは、さらなる広告によって広告されたコンテンツを変更する方法について、最も一般的なユースケースを簡単に説明します。

• コンテンツの削除：IsRmをtrueに設定し、コンテンツを追加した広告と同じProviderとContextIDを持つ、特別なCID no-contentをEntriesリンクとして使用する新しい広告を発行する。
• 検索プロトコルの変更：IsRmをfalseに設定し、ProviderとContextIDをコンテンツを追加した広告と同じにして、Entriesリンクを指定しない新しい広告を発行し、新しいMetadataのみを変更する。
• 検索アドレスの変更：新しいアドレスで新しい広告を発行するだけで、プロバイダIDにマッピングされたアドレスは、以前に広告されたすべてのコンテンツについて更新されます。

アドバタイズされた内容を変更する方法の詳細については、インジェストスキーマのドキュメントを参照してください。

なお、remove all content は現在サポートされていません。

IPNIは、拡張プロバイダー・ファミリもサポートしています。この機能により、プロバイダはデータを取得できる他のプロバイダのリストと取得プロトコルを拡張することができます。今後、拡張プロバイダー・ファミリーに特化したブログポストを予定しています。

広告の検証

index-provider ライブラリは、広告されたコンテンツがコンテンツプロバイダ側とインデクサ側の両方から正しいかどうかを検証するために使用できる CLI ツールを提供します。これは、ネットワークインデクサからアクセスできるように、コンテンツプロバイダがチェーンを正しく公開していることを確認できます。インデックス作成者側では、広告されたコンテンツが実際にインデックス作成者によって取り込まれ、正しいプロバイダーに関連付けられたクエリーAPIを介して発見可能であることを確認することができます。

詳細については、こちらのインストールガイドを参照し、provider verify-ingest –helpを実行してください。

リソース

インデクサネットワークへの参加や、インデクサについてもっと知りたいという方は、以下のリソースが役に立つかもしれません。

• cid.contact (コンテンツルーティングのホームページ)
• docs.cid.contact (インデクサーのgitbook)
• ipni (ファイルコインのスラックチャンネル)
• インデクサーの実装
• インデックスの取り込み
• インデックスプロバイダの作成
• インデックスプロバイダデッキ