Named Data Networking プロジェクト（以下、NDN）は、ネットワーク分野における情報中心のフラッグシッププロジェクトです。このプロジェクトは、ネットワーク層、メッセージ中心の (つまり、コンテンツにアドレス指定可能な) プロトコル スタックを構築しています。約10年前にNSFの資金提供を受けて米国の10の大学と協力してスタートした。
IPFS と NDN は、コンテンツ アドレス可能ネットワークという同じビジョンを共有していますが、動作方法は大きく異なります。 NDN はネイティブ ネットワーク層モデルであるのに対し、IPFS はアプリケーション層モデルです。
プロジェクトの共通のビジョンを考えると、私たちはショーケース セッション、特にディスカッションとフィードバックに非常に興奮しています。講演には合計20名以上が参加した。
以下はプレゼンテーション中に寄せられた質問の要約です。
Q: ブロックサイズはどれくらいですか?ユーザーは異なるサイズのブロックを使用できますか?
A: 使用されるデフォルトのブロック サイズは 256 KB です。はい、ユーザー/アプリケーションは、ipfs add コマンドの -s (--chunker) オプションを使用して、チャンク サイズとチャンク アルゴリズムを定義できます。
Q: マークルツリーはどのように作成されるのですか?
A: ユーザーがローカル IPFS ノードにファイルを追加すると、Merkle-DAG 構造 (惑星間リンク データ (IPLD) と呼ばれる) がローカルに作成されます。ファイルが IPFS ネットワークに公開されると、そのファイルは他のノードに複製されません。これは、クライアントの同意なしにコンテンツがクライアントのローカル ストレージに追加されることを避けるための意図的なものです。代わりに、ファイルは最初にユーザー エージェントによって配布され、ユーザー エージェントは要求に応じてファイルをネットワークに公開します。同時に、元のファイルから取得するノードはマテリアルのプロバイダーとしても機能するため、コンテンツのキャッシュ ネットワークが作成されます。ファイルがネットワークに公開されると、取得用のローカル ノードを指す「プロバイダー レコード」が DHT に配置されます。ネットワーク内の他のクライアントがファイルの永続的なプロバイダーになりたい場合は、ファイルを「ロック」することもできます。ファイルをロックしない場合、ファイルは最終的に「ガベージ コレクション」されます。
Q: アーキテクチャの観点から、ファイルはどのようにシステムに追加されますか?特に、何をどこに追加したかをどのようにして世界に知らせますか?同様に、他のユーザーがシステムに追加されたことをどうやって知ることができるでしょうか?
回答: IPFS アーキテクチャには、ネットワークに公開されたファイルを追跡するメカニズムがありません。新しく追加されたコンテンツ/CID を世界中に知らせるには、これを「オフバンド」で行う必要があります。このトピックは、IPFS コミュニティで進行中の「分散型検索エンジン」に関する議論と大きく関係していますが、これまでのところ、実質的な議論は何も起こっていません。とはいえ、このトピックは Protocol Labs やコミュニティ全体から多くの注目を集めています。 IPNS とそのサポートされている PubSub プロトコルは、新しく公開されたコンテンツに関する情報を配布するもう 1 つの方法です。アプリケーションはこのオプションを使用して、アプリケーション自体のドメイン内の新しいコンテンツに関する情報を伝播 (つまり、プッシュ) できます。 IPNS が DHT 上で実行される場合、プルベースの作業も実行できます。
Q: マークル ツリーの一部を取得するには、その構造全体が必要ですか?ファイルの一部だけを取得したい場合、CID ルートはほとんど意味がないと思われます。
A: ユーザーは、Merkle-DAG の一部を取得するために、その構造全体を持っている必要はありません。 Merkle-DAG の一部 (1 つ以上の CID ブロックで構成される) のみを取得するには、ユーザーはそれらの特定の CID を保持する必要があります。また、ルート CID とパス表記を使用して、Merkle-DAG 内のファイルにアクセスすることもできます (例: Qmcri6S86LuivUY4FDcM1phu5REXcFYootxn1GsRoqnFN5/path/to/some/file.png)。
Q: ブロックに CID が割り当てられると、そのブロックは不変になりますか?
回答: はい、ブロックの CID は一度計算されると、永久に同じままになります。ご存知のとおり、SVN や git などのバージョン管理システムでは、これが「永続的な Web」の基本概念です。これは保管および配送システムの重要な特性であると私たちは考えています。もちろん、ブロック自体は静的なものではなく、変更することができます。ただし、新しいファイルの CID は古いファイルと一致しないため、新しいバージョンを個別に追加する必要があります (コンテンツが IPNS 経由で公開キーで公開されている場合を除く)。
Q: IPFS ネットワークから CID を取り消すにはどうすればよいですか?
A: このような CID は永続的であり、特定のもののハッシュであるため「取り消す」ことはできません (「永続的な Web」に関する上記のコメントを参照)。特定のコンテンツへのアクセスを提供したくないユーザーは、単にそのコンテンツの「提供」を停止することができます。言い換えれば、対応するプロバイダーのレコードの公開を停止することもできます。ただし、これはコンテンツがネットワークから消えることを意味するものではなく、コンテンツを取得した他のクライアントがそのコンテンツをまだキャッシュに保持して提供している可能性があるためです。また、Protocol Labs が提供する IPFS ゲートウェイには CID 拒否リストがあります。 、このリストの CID はコンテンツを保護するために二重ハッシュされており、IPFS ゲートウェイはコンテンツを提供する前にコンテンツが拒否/ブロックされているかどうかを確認します。
Q: 特定の CID の削除ステータス (つまり、拒否リストに追加されているか) を確認することはできますか?
A: CID が特定のゲートウェイの拒否リストに含まれているかどうかを確認するには、ゲートウェイ上でその CID を解決し、拒否されたかどうかを通知する HTTP 応答コードを取得します。各拒否リストは運営組織によって個別に管理されます。IPFS ネットワーク全体に対するグローバルな拒否リストはありません。
Q: 拒否者リストは分散型インフラストラクチャに属していないようです。
A: どの個人または組織もパブリック IPFS ゲートウェイを実行し、独自の拒否リストを運用できます。この意味で、拒否リスト (内容) は中央集権的なエンティティによって決定されるものではありません。
Q: IPNS 記録はどこに保存されますか?
A: IPNS は、コンテンツ ルーティングと同じインフラストラクチャ、つまり DHT を使用します。クライアント公開キーの複数のハッシュが DHT に登録され、変更可能なコンテンツを指します。一方、IPNS レコードを配布する他の方法もあります。IPNS レコードを迅速に配布する方法として、gossipsub と呼ばれる pubsub プロトコル (これも仕様) がこの目的に使用されます。前述したように、IPNS over PubSub と DHT の違いは、プッシュ (PubSub) モードとプル (DHT) モードの違いです。
Q: 他のノードは、名前に対する正しいキーを持っていることをどのようにして知るのでしょうか?
A: ノードが DHT 上で IPNS 名を検索すると、DHT によって指定されたすべてのクライアントからレコードが取得され、データが保存されます。レコードにはシリアル番号があるため、クライアントは IPNS キーに対応する最新の値を簡単に判断できます。また、DHT ルックアップ ショートカットもあり、ルックアップが完了するのを待つ代わりに、ユーザーは受信レコードのクォーラム Q (現在は Q=16 に設定されている) を待ってから、この最新のものを判断するのに十分な情報があることを確認することができます。記録。
Q: IPNS レコードを保存しているノードがオフラインになると、IPNS レコードは失われ、誰かが 24 時間以内に更新しなかった場合、IPNS レコードは提供されなくなりますか?
A: これは正しいです。IPFS レコード (つまり、不変 CID) の発行者も同様です。次の 2 つのうちの 1 つが発生する可能性があります。コンテンツが要求され、すでに他のノードによって取得およびキャッシュされている場合、そのコンテンツはキャッシング ノードによって提供されます。
コンテンツを取得 (およびキャッシュ) したクライアントの 1 つ (または一部) が、コンテンツの保存/提供を継続することを決定した場合、コンテンツを「ロック」できます。これは、コンテンツの永続的なプロバイダーになったことを意味します。
Q: コンテンツをキャッシュするとき、システムは何がキャッシュされているか、またそれをどのように使用/解析するかをどのように認識しますか?
回答: コンテンツをキャッシュするクライアントは、プロバイダーのレコードを DHT に公開して、キャッシュ内のすべてのコンテンツ アイテムのプロバイダーでもあることを宣言します。
Q: キャッシュされたコンテンツは、コンテンツの元のコピーと同じですか?
A: 次の「ガベージ コレクション」の日付まで、この期間中はキャッシュされたコンテンツを解析して提供することができ、キャッシュされたコンテンツが「ロック」されない限り有効期限が切れます (ロックされていない場合、ユーザーが変更を加えるまで永続的にコピーされます)。この記事の執筆時点では、ガベージ コレクションはデフォルトでオフになっていることに注意してください。
Q: 何を探すべきかを正確に知る必要があります。 DHTは良いものですが、その中に何が入っているのかを知るのは難しいです。 CID と実際の ID 情報の間のバインディングはどこで行われますか?
A: IPFS は、エンドユーザー向けのコンテンツ検出 (例: Google 検索サービスのサイトのアドレス指定/ホストに現在 HTTP が使用されている方法など) で使用される分散ファイル システムです。 IPFS は、特定の CID のコンテンツの提供、保存、取得を管理します。残りの処理 (そのアプリに関連付けられた CID にユーザーを接続するか、最初にアプリを見つけること) は、IPFS 自体の上のレイヤーで実行する必要があります。
Q: 会話の冒頭で、目的はネットワーク (つまり、外部エンティティ) から信頼を取り除くことであると述べました。詳しく教えてもらえますか？特定のコンテンツが特定のキーで公開されるとどうやって信頼できるのでしょうか?
A: 独自のハッシュによってコンテンツに名前を付け、分散 P2P ネットワークで公開すると、コンテンツ ホスティング エンティティやコンテンツ解決エンティティなどの外部エンティティを信頼することに関連する問題の一部が本質的に克服されます。コンテンツは自己検証されるため、ローカルで検証できます。コンテンツが発行者の秘密鍵によって署名されている限り、コンテンツ消費者は外部エンティティに依存せずにコンテンツの信頼性を検証できます。
この講演に参加してくださった皆様、そしてこのイベントを企画し、私たちを招待してくださった NDN に感謝します。
