この記事は、IPNIに関する一連の記事の4番目のブログ記事です。第1回目はIPNIのコンセプトについて、第2回目は数十億のアドレス可能なコンテンツのコンテンツプロバイダーを見つけるための内部的な仕組みについて、第3回目はインデックスプロバイダーになるための方法について説明しました。
このブログでは、前回の記事に加えて、最近IPNIに追加された新機能である拡張プロバイダについて説明します。
IPNIにデータはどのように入るのか？
IPNIは、Advertisementを処理することでインデックスを構築します。Advertisementの構成により、ストレージプロバイダはIPNIにCIDを提供することができ、Advertisementが処理されると、これらのCIDを高速ルックアップに利用できるようになります。CIDの他に、AdvertisementにはプロバイダのピアID、マルチアドレス、データをフェッチするためのプロトコルが含まれています。IPNIでCIDを検索すると、接続を確立してデータをダウンロードするために必要なすべてのフィールドを即座に確認することができます。
AdvertisementはIPLDオブジェクトであり、チェーンにリンクされている。IPNIはAdvertisementを見ると、チェーンを最後の既知のエントリまで遡り、そこから始まるすべての新しいデータのインデックスを作成することができます。
このワークフローは下図のように描かれています。
課題
web3.storageやnft.storageのような大規模なStorage Providerのフルインデックスを構築するのは大変です。多くの時間と計算資源を消費します。例えば、数少ないIPNIのデプロイメントの一つであるcid.contactは、執筆時点で約1兆3千億のCIDがインデックスされていました。このようなインデックスをゼロから作り直すには、数週間かかり、24時間365日稼動する頑丈なサーバーが必要です。
さて、ストレージプロバイダが水平方向にスケールアウトしたい場合はどうすればよいでしょうか。典型的な方法は、新しいlibp2pアイデンティティを持つ新しいノードを追加し、多分異なる転送プロトコルで、そこから同じデータの提供を開始することでしょう。しかし、IPNIは、プロバイダ「A」のすべてのデータがプロバイダ「B」でも利用可能であることをどのように知るのでしょうか？新しいIDのためにすべてのCIDを再広告することは、それを達成するための極めて非効率的な方法でしょう。拡張プロバイダがその答えです。
拡張プロバイダ
Extended Providers機能により、ストレージプロバイダは、過去と未来のすべてのAdvertisement、または特定のContextIDを持つ単一のAdvertisementにAdvertisement情報を追加することができます。さらに重要なことは、Advertisementチェーン全体を再パブリッシュすることなく、たった1つの広告を送信することでそれが可能になることです。
ユースケース
- 同じデータセットを扱う独自の libp2p ID を持つ新しいノードを追加することで、データ検索をスケールアウトさせることができます。このユースケースは、ファイルコインへの大規模なデータオンボードプラットフォームであるEstuaryが、拡張プロバイダを使用してデータ検索機能を向上させるために行ったものです。
- 新しいデータ転送プロトコルを、同じデータセットを扱う新しいマルチアドレスのセットで提供します。この使用例は、Boost（lotusのgo-fil-marketsパッケージの置き換え）によって推進されました。
どのような仕組みになっているのか？
Extended Providers（EPs）は、Advertisementプロトコルの後方互換性のある拡張です。これは、Advertisementにオプションで追加できる新しいExtendedProviderフィールドとして定義されています。
type Advertisement struct {
…
ExtendedProvider optional ExtendedProvider
…
}
type ExtendedProvider struct {
Providers [Provider]
Override bool
}
type Provider struct {
ID String
Addresses [String]
Metadata optional Bytes
Signature Bytes
}
拡張プロバイダには、チェーンレベルまたはコンテキストレベルのものがあります。チェーンレベルの拡張プロバイダは、プロバイダの過去と未来のすべてのAdvertisementに適用されます。コンテキスト拡張プロバイダは、特定のコンテキストIDを持つ1つのAdvertisementにのみ適用されます。
遭遇した場合、IPNIはExtendedProviderフィールドを以下のように解釈します。
AdvertisementにContextIDがない場合、これらのプロバイダはチェーンレベルとみなされます。そうでない場合、それらは文脈的とみなされ、そのContextIDに対してのみ返されます。いくつかの追加ルールがあります。
ContextIDを持つAdvertisementのExtendedProviderエントリでOverrideが設定されている場合、そのContextIDに対して、指定されたチェーンレベルのプロバイダセットを返してはならないことを示します。プロバイダは代わりに返されます。
ContextIDを持つAdvertisementのエントリでOverrideが設定されていない場合、任意のチェーンレベルのExtendedProviders（Addresses、Metadata）との結合として結合されることになります。
ルールの完全なセットについては、仕様書を参照してください。
例えば、プロバイダMaxが新しいピアID 12D3KooWB1b3qZxWJanuhtseF3DmPggHCtG36KZ9ixkqHtdKasdfhからBitswapプロトコルでのデータ提供を開始したい場合、以下のAdvertisementを発行できます。
{
Provider: “12D3KooWHHzSeKaY8xuZVzkLbKFfvNgPPeKhFBGrMbNzbfwwkpqu”, // Max’s original peer id
Addresses: [“/ip4/224.96.85.246/tcp/1481”, “/ip4/23.49.80.75/tcp/3339”], // Max’s original multiaddresses
ContextID: “”, // Empty ContextID so that Extended Providers are chain-level
ExtendedProvider: {
Providers: [
{
ID: “12D3KooWB1b3qZxWJanuhtseF3DmPggHCtG36KZ9ixkqHtdKasdfh”, // Max’s new peer id that he wants to use for Bitswap transfers
Addresses: [“/ip4/224.96.85.246/tcp/1481”], // Max’s new addresses that he wants to serve Bitswap over
Metadata: “gBI=” // Metadata that tells that this is a Bitswap protocol
}
]
}
}
その広告が処理されると、Max の新しいプロバイダ情報は、彼の CID のすべてのルックアップに追加で返されます。API の観点からは、Extended Provider の結果は、通常のプロバイダ記録と区別がつきません。
拡張プロバイダを利用した広告も、仕様で定められた特別な方法で署名する必要があります。
Go SDKの例
index-providerライブラリの最新バージョンに、Extended Providersのサポートが追加されました。xproviders.AdBuilderを使用して広告を構築し、使い慣れたEngineインターフェイスを使用して公開することができます。
adv, err := xproviders.NewAdBuilder(providerID, priv, addrs).
WithContextID(contextID).
WithMetadata(metadata).
WithOverride(override).
WithExtendedProviders(extendedProviders).
WithLastAdID(lastAdId).
BuildAndSign()
if err != nil {
//…
}
engine.Publish(ctx, *adv)
リソース
IPNIへの参加に興味がある、またはIPNIについてもっと知りたいという方は、以下のリソースが役に立つかもしれません。
- cid.contact (one of the managed IPNI deployments)
- storetheindex (Filecoin slack channel)
- IPNI implementation
- IPNI Specification
コメント