分散ハッシュテーブル (DHT)

IPFS ノードが互いを見つけ、探しているコンテンツを誰が持っているかを発見する方法。

DHT とは？

分散ハッシュテーブルは、分散型のルックアップシステムです。誰一人として全体を持っていない電話帳のようなものと考えてください — 各参加者が数ページを持ち、持っていないページについては誰に聞けばよいか知っています。

IPFS では、DHT は CID を対応するコンテンツを持つノードのネットワークアドレスにマッピングします。CID でファイルをリクエストすると、DHT がどのノードがそれを提供できるかを見つける手助けをします。

IPFS での仕組み

IPFS は Kademlia DHT の変種を使用しています。各ノードは近隣ノード（ノード ID 間の XOR 距離）のルーティングテーブルを維持しています。ノードがコンテンツを見つけたいとき：

1. CID と既知のノード ID の間の XOR 距離を計算
2. 最も近い既知のノードに問い合わせ：「この CID を誰が持っていますか？」
3. それらのノードはコンテンツを持っているか、より近いノードを指し示す
4. 検索は収束 — 各ホップでファイルを持つノードに近づく
5. コンテンツを提供するノードから直接取得

TIP

このルックアップは通常数ホップしか必要ありません — 数百万ノードのネットワークでも、ファイルは 20〜30 ステップで見つけることができます。

プロバイダレコード

ノードがコンテンツをピン留めすると、DHT にプロバイダレコードを公開し、「CID X を持っています。アドレスは Y です」と告知します。これらのレコードは約 24 時間で期限切れになり、定期的にリフレッシュする必要があります。アクティブなピン留めが重要な理由がここにあります — それがなければ、プロバイダレコードが期限切れになり、コンテンツが発見できなくなります。

DHT について考える必要がない理由

IPFS.NINJA がすべての DHT インタラクションを処理します。ファイルをアップロードすると：

• クラスターがファイルをピン留めし、プロバイダレコードを自動的に公開
• プロバイダレコードは継続的にリフレッシュ — コンテンツは発見可能な状態を維持
• ゲートウェイはリクエストを処理する際に DHT 経由で CID を解決
• CID とゲートウェイ URL を使うだけ — DHT は透過的です