IPFS Kubo 0.39.0: Optimistic Provide によるコンテンツ公開の高速化
IPFS Kubo 0.39.0: Optimistic Provide によるコンテンツ公開の高速化
IPFS Kubo v0.39.0 では、コンテンツの公開レイテンシを平均 15 秒から 1 秒未満に短縮する手法である Optimistic Provide が導入されました。厳格な DHT walk の終了条件を統計的なヒューリスティックに置き換えることで、このアップデートにより、ネットワークのオーバーヘッドを 40% 削減しながら、ほぼリアルタイムのコンテンツ発見可能性を実現します。
従来の IPFS 公開におけるパフォーマンスのボトルネック
IPFS Amino DHT におけるコンテンツの公開は、従来、2 つのフェーズを必要としていました。まず、データの XOR 距離メトリックを使用して、ネットワーク全体でそのデータに最も近い 20 個のピアを特定するための DHT Walk を行い、その後に、プロバイダー・レコードをそれら 20 個のピアにプッシュする Follow-Up フェーズが続きます。
歴史的に、DHT Walk フェーズが主なボトルネックとなってきました。従来のアルゴリズムでは、終了前に、発見された最も近い 3 つのピアからのレスポンスを待機する必要があります。チャーン（ノードの頻繁な入れ替わり）が高いパーミッションレス・ネットワークにおいては、これらの特定のピアに到達できないことが多く、システムがバックトラックして、より遠いノードにクエリを投げることを余儀なくされます。この硬直性が、中央値で約 20 秒のレイテンシ、場合によっては 2 分以上かかる操作を引き起こしていました。
Optimistic Provide の仕組み
Optimistic Provide は、決定論的な待機を、以下の 3 つの主要なメカニズムに置き換えることで、「provide」操作を高速化します。
1. ネットワーク・サイズの推定
確率的な決定を行うために、ノードはまずネットワークの総サイズを推定する必要があります。Kubo v0.39.0 は、既存のルーティング・テーブルの更新メカニズムに相乗りする軽量な推定アルゴリズムを実装しており、追加のネットワーク・オーバーヘッドは発生しません。
ピア ID が一様に分布していると仮定することで、システムは Order Statistics（順序統計量）に Beta 分布を使用し、ルックアップ結果の各ピアを独立したネットワーク・サイズの推定値として扱います。局所的な密度の偏り（密な領域のピアがネットワーク・サイズを過大評価してしまう現象）を防ぐため、アルゴリズムはルーティング・テーブル内の非フル・バケットからのデータポイントに指数関数的な重み付けの減少（downweight）を適用します。
2. 予測的終了 (Predictive Termination)
信頼できるネットワーク・サイズの推定値が得られると、ノードは DHT walk 中に確率的な決定を下すことができます。
- Per-Peer Storage: 開始ノードが、統計的にネットワーク全体で最も近い 20 個の中に含まれる可能性が高い（信頼度 90%）ピアに遭遇した場合、walk の終了を待たずに、即座にレコードを保存します。
- Walk Termination: 開始ノードが、現在の 20 個の最も近いピアのセットがグローバルな最も近いセットを構成していると 90% の確信を持てた時点で、walk を即座に終了し、最も近い 3 つのピアの確認を待つ必要を回避します。
3. 早期リターン (Early Return)
予測的終了により、従来のバックトラック・アルゴリズムのフィルタリング効果がスキップされるため、follow-up フェーズにおいて、到達不能なピアが多く含まれる可能性があります。単一の応答不能なピアによってユーザー体験が停滞することを防ぐため、Kubo は、20 個のピアのうち 15 個が保存を完了した時点で、ユーザーに制御を戻すようになりました。
残りの 5 つのリクエストは、バックグラウンドで非同期に継続されます。研究によれば、複製ファクターを 20 から 15 に減らすことは、レコードの可用性への影響は無視できる程度であることが示されています。
パフォーマンスと可用性への影響
Kubo v0.39.0 の導入により、アップロード・レイテンシが平均約 15 秒から約 0.7 秒へと劇的に低下しました。
レコードの可用性
レコードの可用性に対する重大な妥協はありません。Optimistic approach による選択されたピアは、ターゲット・キーに対して統計的に十分に近いため、検索可能性を維持できます。さらに、Reprovide Sweep メカニズムがバックグラウンドで正確な PUT 操作を実行して、初期配置の不正確さを修正するため、初期のユーザー体験に影響を与えることなく、長期的なレコードの安定性を確保します。
現在の制限事項
- Undialable Peers: Amino DHT におけるピア・アイデンティティの約 50% がプライベート IP アドレスを広告しています。これらのピアはネットワーク・サイズの推定値を膨らませ、より保守的な終了閾値とパフォーマンス向上効果の減少をリードします。
- Cold Start: ノードは起動後に、ネットワーク・サイズを推定するために、ルーティング・テーブルの部分的な更新が必要であり、数秒から数分間の遅延が発生します。
将来の改善策
アルゴリズムをさらに最適化するために、ProbeLab チームは 3 つの強化策を提案しています。
- Peer Filtering: パブリック・ネットワーク上で動作している場合、推定プロセスからプライベート IP アドレスのみを持つピアを除外すること。
- Reprovide Sweep Integration: Reprovide Sweep のネットワーク・エニュメレーションを使用して、正確なピア・カウントを直接 Optimistic Provide アルゴリズムに供給すること。
- Disk Persistence: 最新のネットワーク・サイズ推定値をディスクに保存し、再起動時の Cold Start による遅延を解消すること。