IPFS とは: 完全な InterPlanetary ファイル システム ガイド (2026)

あなたが毎日使っているインターネットは、ブラウザにアドレスを入力すると、世界のどこかにある特定のサーバーがファイルを送り返すという単純な約束で動いています。このモデルは 30 年間ウェブを支えてきましたが、重大な弱点があります。ファイルは 1 か所に存在します。そのサーバーがダウンしたり、検閲されたり、単にドメインの更新を忘れたりすると、コンテンツは永久に消えてしまいます。の 惑星間ファイルシステム IPFS として知られる は、インターネット上でのファイルのアドレス指定と共有の方法を再考することで、まさにこの問題を解決するために構築されました。

IPFS は単一の会社ではありません。 ブロックチェーン、または伝統的な意味でのクラウド ストレージ サービス。これは、場所ベースのアドレス指定ではなくコンテンツベースのアドレス指定を使用して、誰でもファイルを保存および提供できるピアツーピア プロトコルです。 IPFS では、「このサーバーにあるファイルをください」と尋ねる代わりに、「このフィンガープリントが付いているファイルをください」と尋ねることができ、ファイルを持つネットワーク上のどのノードでも応答できます。この微妙な変化により、パーマネント リンク、検閲耐性、プロトコル レベルでの重複排除、オフライン操作、および Web3 集中型ホスティングに依存しないアプリケーション。

この完全なガイドでは、IPFS が実際に何であり、そうでないのか、コンテンツ アドレッシングが内部でどのように機能するのかを学びます。 CID 識別子、その理由 NFT メタデータ、ピンニング サービスの状況、IPFS ゲートウェイがネットワークを静かに再集中化する方法、新しい Helia js-ipfs を置き換える実装、および IPFS と並行して適合する実装 ファイルコイン。最終的には、最初のファイルをアップロードし、ピン留めプロバイダーを評価し、ほとんどの記事では触れられていない落とし穴を特定できるほど IPFS を深く理解できるようになります。

IPFS とは実際何ですか?

IPFS は InterPlanetary File System の略で、Web の高速化、復元力の向上、オープン化を目的に設計されたオープンソースのピアツーピア プロトコルです。これは、後に Filecoin を立ち上げたのと同じ組織である Protocol Labs を通じて、2014 年に Juan Benet によって作成されました。 IPFS の核心は、HTTP のロケーションベースのアドレス指定をコンテンツベースのアドレス指定に置き換え、中央機関に依存せずにコンテンツを保存および取得できるノードの分散ネットワークを構築します。

ここに重要な精神的変化があります。 HTTP 経由で Web サイトにアクセスすると、ブラウザは特定のサーバーに特定のパスを要求します。 URL https://example.com/photo.jpg は、何を取得するかではなく、どこに行くかをブラウザーに指示します。 IPFS では、ファイルの名前によってファイルを要求します。 CID、ファイルの内容の暗号化ハッシュ。ネットワークは、ファイルを持つピアを見つけて、それを提供します。アドレスはコンテンツそのものです。

重要な点が 1 つあります。プロトコルは実際にはそれ自体には何も保存しません。 IPFS is an addressing and routing system.ファイルは、それらをホストすることを選択したノード上に存在します。特定の CID をホストするノードがない場合、アドレスが永久に有効であっても、そのコンテンツは単にネットワーク上に存在しません。これが、ピン留めサービスが存在する理由であり、ピン留めせずに NFT イメージを IPFS にアップロードすることが最もよくある間違いの 1 つである理由です。 NFT プロジェクト。

コンテンツ アドレッシング: 中心となるアイデア

コンテンツ アドレッシングは、IPFS における最も重要な概念です。ファイルがどこにあるかによって識別するのではなく、ファイルが何であるかによって識別します。 IPFS に追加されるすべてのファイルは暗号化によって実行されます。 hashing algorithm、通常は SHA-256 で、そのファイルに固有の固定長のダイジェストを生成します。ファイルの 1 ビットを変更すると、ハッシュが完全に変わります。このハッシュは、ファイルの CID、つまりネットワーク上の永続的なアドレスの基礎となります。

この影響は非常に大きいです。世界中のどこにある 2 つの同一のファイルも同じ CID を持つことになります。これは、IPFS がコンテンツを自動的に重複排除することを意味します。 100 万人が同じ猫の写真をアップロードしたとしても、ネットワークに必要なコピーは 1 枚だけです。 CID は、HTTPS URL とは異なり、改ざん防止機能も備えています。取ってくるとき /ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi、受信したコンテンツはその正確な CID にハッシュする必要があります。そうしないと、IPFS クライアントがそれを拒否します。悪意のあるノードが同じアドレスで変更されたコンテンツを提供する方法はありません。

大きなファイルは単一の BLOB としてハッシュされません。 IPFS は、それらを小さなチャンク (通常はそれぞれ 256 KB) に分割し、各チャンクをハッシュしてから、各ノードがハッシュによって子を参照するマークル有向非巡回グラフ (DAG) を構築します。返される CID はルート ノードのハッシュであり、ファイル内のすべてのチャンクに推移的にコミットされます。この構造はと呼ばれます IPFS の世界では dag-pb であり、これが従来のデフォルトです。新しいコンテンツの使用 ipld (InterPlanetary Linked Data)、JSON、CBOR、およびその他のエンコーディングをサポートする、より柔軟なデータ モデル。

CID v0 と CID v1: 違いは何ですか?

IPFS に何かをアップロードしたことがある方は、おそらく 2 つのまったく異なる CID を見たことがあるでしょう。 The old style starts with Qm のように見えます QmYwAPJzv5CZsnA625s3Xf2nemtYgPpHdWEz79ojWnPbdG。新しいスタイルは以下から始まります b のように見えます bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi。これらはそれぞれ CID v0 と CID v1 を表し、その違いは実稼働環境で重要となります。

CID v0 がオリジナルの形式です。これは常に、Qm で始まる、base58 エンコードされた dag-pb エンコードされたコンテンツの SHA-256 ハッシュです。短くて分かりやすいですが、硬質でもあります。異なるハッシュ関数、異なるエンコーディング、または異なるベースを使用する余地はありません。 CID v1 は、最新の柔軟な形式です。これは、バージョン、コーデック、 使用される multihash 関数と基本エンコーディング。つまり、CID v1 は SHA-256 dag-pb を表すことができますが、BLAKE3 IPLD、生のバイト、またはプロトコルがサポートするその他のものを表すこともできます。

現在 CID v1 を好む最大の実際的な理由は、サブドメイン ゲートウェイのサポートです。最新の IPFS ゲートウェイは、次のような URL からコンテンツを提供します。 https://bafybei...ipfs.dweb.link、各 CID に独自のブラウザー起点を与えます。オリジンの分離はセキュリティ (Cookie、ローカル ストレージ、サービス ワーカー) にとって不可欠であり、大文字と小文字を区別しない Base32 エンコード (CID v1) でのみ機能します。 2026 年に何かを公開する場合は、特別な理由がない限り、デフォルトで CID v1 を使用してください。

libp2p: その下のネットワーク層

IPFS は、と呼ばれるモジュラー ネットワーキング スタックの上に構築されています。 libp2p。これは、Protocol Labs が開発したインフラストラクチャの最も重要な部分の 1 つであり、IPFS 以外にも、Ethereum 2.0、Polkadot、およびさまざまな Web3 プロトコルを含む他の多くのプロジェクトで使用されています。 libp2p は、ピア検出、接続管理、NAT トラバーサル、トランスポート暗号化、多重化、ストリーム プロトコルなど、従来ネットワーク スタックを必要とするすべてのものを処理します。ピアツーピア ネットワーキングの厄介な現実が抽象化されるため、IPFS などの上位レベルのプロトコルは独自のロジックに集中できます。

libp2p のピアは一意の PeerID、これ自体がピアの公開鍵のハッシュです。これは、ピア ID が暗号化され自己主権的であることを意味し、アドレスの仕組みと非常によく似ています。 暗号通貨ウォレット。ピアは、Kademlia に基づく分散ハッシュ テーブル (DHT) を通じてお互いを見つけます。これにより、ネットワークは中央ディレクトリなしでコンテンツ要求を効率的にルーティングできます。 CID を要求すると、ノードは DHT にクエリを実行して、CID を持っていることをアドバタイズしているピアを見つけ、それらのピアに直接接続してコンテンツをダウンロードします。

libp2p は、TCP、QUIC、WebSocket、WebRTC を含む複数のトランスポートをサポートします。ブラウザは生の TCP 接続を開くことができないため、WebRTC はブラウザで IPFS を機能させるものです。この柔軟性により、IPFS は組み込みデバイスからブラウザ タブ、運用サーバーに至るまで、すべて同じプロトコルを使用するすべてのもので実行できます。

コンテンツ取得の仕組み: ビットスワップ

IPFS ピア間でバイトを移動する実際のメカニズムは次のように呼ばれます。 bitswap。これは、強力なアイデアを備えた比較的単純なプロトコルです。各ピアは、探している CID の「欲しいリスト」と、提供できる CID の「所有リスト」を維持します。 2 つのピアが接続すると、これらのリストを交換し、あるピアが別のピアが必要とするブロックを受信するたびに、それを送信します。

CID をリクエストすると、IPFS ノードはまずローカル キャッシュをチェックします。コンテンツがそこにある場合は、すぐに取得できます。そうでない場合、ノードは DHT にクエリを実行して CID をアドバタイズしたピアを見つけ、libp2p 経由でピアに接続し、ビットスワップを使用してブロックをダウンロードします。多くのブロックに分割された大きなファイルの場合、ノードは異なるピアから異なるブロックを並行してプルする可能性があり、これによりパフォーマンスが向上し、個々のピアの障害に対するネットワークの回復力が高まります。

デフォルトでは、ビットスワップに金銭的なインセンティブは組み込まれていません。ピアはコンテンツを提供したいため、または IPFS 上で実行されているサービスから料金を受け取ったためにコンテンツを提供します。これは IPFS と Filecoin の重要な違いの 1 つであり、後で詳しく説明します。 Bitswap には支払いの概念がありません。これは純粋なベストエフォート型のピアツーピア交換です。

ピン留め: なぜそれが重要なのか、そして誰がそれを行うのか

IPFS に関して最も誤解されている点は次のとおりです。ファイルを IPFS にアップロードしても誰もそれを固定しない場合、そのファイルは最終的に消滅します。 IPFS ノードのキャッシュ スペースは限られており、誰も積極的に保持していない古いコンテンツを定期的にガベージ コレクションします。 CID は有効なままで、誰かがコンテンツを提供した場合にプロトコルはそのコンテンツを見つける方法をまだ知っていますが、実際のバイトは失われています。ピン留めは、IPFS ノードに「何があってもこのコンテンツを削除しないでください」と伝える行為です。

コンテンツを自分のノードにピン留めできます。これは個人的なプロジェクトには問題ありませんが、運用環境ではほとんどの場合ピン留めサービスに依存します。これらは、堅牢な IPFS インフラストラクチャを実行し、料金を支払っている限り CID を利用し続けることを保証する企業です。 2026 年のピンニング サービスの状況は成熟しており、競争力があり、さまざまなユースケースに対応する堅実なオプションがいくつかあります。

ピン留めサービスの選択は、優先順位によって異なります。確実な稼働時間と優れた開発者の人間工学が必要な場合は、Pinata が安全なデフォルトです。 Filecoin 取引を含めて長期的な耐久性が必要な場合は、Storacha がその目的のために構築されています。 dApp フロントエンドをデプロイしている場合、Fleek の Git 統合により、CI セットアップにかかる時間を節約できます。小規模なプロジェクトを実行していて、定期的な支出をゼロにしたい場合は、適切なモニタリングを備えたセルフホスト型の Kubo ノードが完全に実行可能です。

IPFS ゲートウェイと集中化の問題

IPFS がピアツーピア プロトコルの場合、ブラウザはどのようにロードされますか /ipfs/CID URL?少なくともネイティブではそうではありません。主流のブラウザは IPFS プロトコルを認識しません。 IPFS コンテンツに通常の Web 経由でアクセスできるようにするために、コミュニティはゲートウェイ、つまり IPFS ネットワークと通常のブラウザの間のブリッジとして機能する HTTP サーバーを構築しました。あなたがリクエストする https://ipfs.io/ipfs/bafybei...、ゲートウェイは IPFS ネットワークからコンテンツを取得し、HTTPS 経由でコンテンツを返します。

ゲートウェイは非常に便利ですが、IPFS のマーケティング資料ではよく取り上げられている静かな集中化の問題が発生します。 2 つの主要なゲートウェイである ipfs.io (Protocol Labs が運営) と Cloudflare-ipfs.com (Cloudflare が運営) は、すべての IPFS トラフィックの大部分を処理します。ほとんどの NFT マーケットプレイス、dApp、教育サイトがこれらのゲートウェイを使用して IPFS コンテンツを提供すると、プロトコルの分散化のストーリーは弱くなります。 CloudflareがCIDをブロックするか、ipfs.ioが停止すると、実際のIPFSクライアントをインストールしたことがないユーザーは、「分散型」コンテンツの大部分が一時的にアクセスできなくなります。

この緩和策はよく知られていますが、十分に活用されていません。まず、複数のゲートウェイを介してコンテンツにリンクするか、フォールバック ゲートウェイ リストを使用して、単一のオペレーターがダウンしてもサイトが破壊されないようにします。次に、次のようなサブドメイン ゲートウェイを優先します。 https://CID.ipfs.dweb.link はパス ゲートウェイを介して送信されます。これは、各コンテンツが独自のブラウザー オリジンに分離されるためです。 3 番目に、実際の検閲耐性が必要なユーザーには、独自のノードを実行するか、IPFS が組み込まれている Brave を使用することを奨励します。 4 番目に、長期的な回復力を重視するプロジェクトは、パブリック ゲートウェイの使用に加えて独自のゲートウェイを実行する必要があります。

ヘリア vs クボ: 最新の IPFS スタック

IPFS の歴史のほとんどにおいて、主に 2 つの実装がありました。 Kubo (当初は go-ipfs と呼ばれていました)、Go で書かれたリファレンス実装、および JavaScript 実装の js-ipfs。 Kubo はデーモンとして実行され、ピン留めサービスやゲートウェイなど、ほとんどの実稼働 IPFS インフラストラクチャを強化します。成熟しており、パフォーマンスが高く、実戦でテスト済みです。

js-ipfs を使用すると、IPFS をブラウザーや Node.js アプリで実行できますが、多くのレガシー コードが含まれており、保守が困難でした。 2023 年に、プロトコル ラボは次への移行を開始しました。 Helia、より無駄がなく、よりモジュール化されたアーキテクチャを備えた新しい実装です。 2025 年までに js-ipfs は非推奨となり、Helia が JavaScript プロジェクトで推奨される選択肢になりました。 2026 年、新しいことは Helia から始めましょう。

Helia はドロップイン代替品ではありません。 API は異なり、依存関係グラフはより小さく、哲学は「独自の部分を持ち込む」です。独自のブロックストア、データストア、ルーティングを選択し、それらを Helia に接続すれば、動作するノードが得られます。これにより、Helia を最新のスタックに簡単に組み込むことができます。 js-ipfs プロジェクト用の移行ガイドが存在します。

IPFS と HTTP: 並べて比較

IPFS を理解する最も有益な方法は、IPFS をその上に構築され、部分的に置き換えられるプロトコルである HTTP と直接比較することです。これらは敵ではなく、ほとんどの実稼働 IPFS ユースケースにはスタックのどこかに HTTP が含まれていますが、設計哲学は大きく異なります。

2026 年の現実的な判断は、IPFS と HTTP は競合するのではなく、共存するということです。 HTTP は、動的コンテンツ、セッション、および高スループットのアプリケーションに優れています。 IPFS は、ミリ秒の遅延よりも完全性と回復力が重要な、静的でアドレス指定可能な長期間存続するコンテンツに最適です。ほとんどの実稼働スタックは、動的レイヤー (API、ユーザー認証) に HTTP を使用し、不変レイヤー (画像、NFT メタデータ、dApp フロントエンド) に IPFS を使用します。

IPFS とファイルコイン: 関係の明確化

IPFS と Filecoin の間には常に混乱があります。その理由の 1 つは、両方とも Protocol Labs によって作成されたためであり、また、彼らのマーケティング資料が時々境界線を曖昧にしているためでもあります。これはクリーン バージョンです。 IPFS は、コンテンツのアドレス指定と移動のためのプロトコルです。 Filecoin は、保証期間中にコンテンツをホストするためにノードに料金を支払うブロックチェーンベースのストレージ市場です。これらは補完的なものであり、交換可能なものではありません。

IPFS には経済層がありません。ノードは善意からコンテンツを提供するか、プロトコル上で実行されているサービスから料金を受け取ったためにコンテンツを提供します。 CID が引き続き利用可能であるという保証は組み込まれていません。 Filecoin は、ストレージプロバイダーが特定のコンテンツを特定の期間利用できるようにするために暗号経済的賭け金をコミットするマーケットプレイスを作成することで、この問題を解決します。 Filecoin プロバイダーが通常の暗号証明を通じてあなたのデータをまだ保持していることを証明できなかった場合、担保の一部を失います。これにより、純粋な IPFS にはない経済的インセンティブが生まれます。

クリーンな考え方: 取得とアドレス指定には IPFS を使用し、耐久性のある有料ストレージのコミットメントには Filecoin を使用します。 Storacha や NFT.Storage などの最新のピン留めサービスは両方を実行します。彼らはコンテンツを IPFS に固定して高速に取得できるようにし、ファイルコインのストレージ取引も行うため、コンテンツには長期的な暗号経済的保証が与えられます。 IPFS の速度と Filecoin の耐久性を 1 つのスタックで実現します。

NFT メタデータ: IPFS が標準になった理由

NFTをミントするとき、実際の画像やメディアファイルがブロックチェーン自体に保存されることはほとんどありません。数メガバイトの JPEG をイーサリアムに保存するには、多額の費用がかかります ガス料金。代わりに、NFT コントラクトには、画像 URL、特性、その他の属性を含む JSON ファイルを指すメタデータ URI が保存されます。 NFT の整合性は、そのメタデータ URI が正しいコンテンツに解決され続けるかどうかに完全に依存します。

ここで IPFS が事実上の標準になりました。 NFT メタデータに通常の HTTPS URL を使用すると、NFT が壊れるまで 1 回のサーバー停止で済みます。さらに悪いことに、造幣後にイメージを交換しても、サーバーのログを確認しないと誰も気づかない可能性があります。 IPFS の場合、URI は次のようになります。 ipfs://CID、特定の暗号化ハッシュを指します。内容は変更できません。ハッシュが一致しないため、その CID に対して異なるファイルを提供するノードはすぐに検出できます。

問題点は、これが最も一般的な NFT の間違いですが、IPFS にアップロードしてもファイルが存続しないことです。ローカルノードにアップロードし、他の場所にピン留めせずにシャットダウンすると、NFT は無効になります。評判の良いプロジェクトは少なくとも 1 つの専門サービスにピン留めされ、本格的なプロジェクトは複数にピン留めされて Filecoin 取引を行います。 NFT プロジェクトが造幣局から数年後に中断される場合、それはほとんどの場合、チームがピン留め請求書の支払いを停止したことが原因です。

IPFS での dApp フロントエンド ホスティング

NFT を超えた 2 番目の主要な運用ユースケースは、分散型アプリケーション フロントエンドのホスティングです。最新の dApp には、イーサリアム上のスマート コントラクト バックエンドと JavaScript フロントエンドがあります。フロントエンドが通常のクラウドプロバイダー上にある場合、dApp の分散化の主張はほとんどがフィクションになります。スマート コントラクトはオンチェーンですが、チームのドメインまたはホスティングがダウンすると、ユーザーはアクセスできなくなります。

フロントエンドバンドルを IPFS にデプロイすると、dApp に次の場所からアクセスできるようになります。 /ipfs/CID は永続的に存在し、どの IPFS ゲートウェイでもサービスを提供できます。と組み合わせる 分散型アイデンティティ と ENS を介した人間が読める名前、または dnslink、完全にアドレス指定可能で検閲に耐性のあるフロントエンドが得られます。 Uniswap、Aave、その他の主要な DeFi プロトコルは、この理由から IPFS ビルドを公開しています。

IPNS および DNSLink: 不変コンテンツ上の可変名

コンテンツ アドレッシングは素晴らしいですが、明らかな制限があります。コンテンツが変更されるたびに CID も変更されます。 dApp が新しいバージョンをデプロイすると、既存のリンクがすべて壊れます。これを解決するために、IPFS は 2 つの間接層を提供します。 /ipns/ (惑星間ネームシステム) および dnslink。

IPNS を使用すると、時間の経過とともに更新できる、安定したピアキーベースの CID へのポインターを公開できます。ポインタ自体は公開キーのハッシュであり、対応する秘密キーを使用して更新に署名します。他のノードはそれらの更新を検証し、IPNS 名に対する要求を現在の CID にルーティングできます。住所は次のようになります /ipns/k51qzi5...は永遠に安定していますが、指すものは変わる可能性があります。

DNSLink はこれをさらに一歩進め、TXT DNS レコードを通じて通常のドメイン名を IPFS CID にマッピングできるようにします。次のようなTXTレコードを作成します _dnslink.example.com と値 dnslink=/ipfs/CIDおよび IPFS 対応ツールは、ドメインを現在の CID に解決します。これは、dApp フロントエンドが IPFS からコンテンツを提供しながら、人間が判読できる URL を取得する方法です。導入するたびに DNS レコードが更新されますが、ユーザーは引き続きフレンドリ ドメインにアクセスします。

ハンズオン: Storacha と Pinata へのアップロード

理論は問題ありませんが、IPFS を内部化する最も速い方法は、実際に何かを固定することです。 Storacha と Pinata はどちらも、豊富な無料枠と優れた開発者エクスペリエンスを提供します。それぞれの具体的な流れをご紹介します。

付き ストラチャ、電子メールで storacha.network にサインアップしてください。サービスから確認の電子メールが送信され、クリックスルーすると、アップロード用の名前空間である「スペース」が作成されます。をインストールします。 w3 CLI を使用 npm install -g @web3-storage/w3cliでログインします w3 login [email protected]、スペースを選択し、アップロードします w3 up ./my-file.jpg。 CID はすぐに返されます。ファイルは Storacha の IPFS ノードに固定され、Filecoin ストレージ取引のキューに入れられます。

付き ピニャータ、pinata.cloud にサインアップし、ピン留めおよびリストのスコープを含む API キーを作成し、Web アップロード インターフェイスまたは API を使用します。ダッシュボードから文字通りファイルをドラッグ アンド ドロップして名前を付けると、数秒以内に次のような CID と Pinata ゲートウェイ URL が得られます。 https://gateway.pinata.cloud/ipfs/CID。プログラムによるアップロードのために、Pinata は複数の言語の SDK とクリーンな REST API を提供します。独自のドメインの下にカスタム専用ゲートウェイを構成することもできます。これは、ほとんどの実稼働 NFT プロジェクトが行うことです。

いずれかのサービスから CID を取得したら、それが複数のゲートウェイから機能することを確認します。試してみる https://ipfs.io/ipfs/CID、 https://CID.ipfs.dweb.link、および https://cloudflare-ipfs.com/ipfs/CID。 3 つすべてが同じコンテンツを提供する必要があります。異なるゲートウェイから同じ CID で異なるコンテンツが表示された場合は、何かが非常に間違っているため、報告する必要があります。コンテンツ アドレス指定の要点は、CID がコンテンツであるということです。

実際の運用ユースケース

IPFS はもはや研究プロジェクトではありません。 IPFS は大規模な運用トラフィックを強化します。以下の例は、IPFS が実際に優れている点と過剰に宣伝されている点を示しているため、知っておく価値があります。

トルコのウィキペディアミラー: 2017 年にトルコが Wikipedia をブロックしたとき、ウィキメディア財団は IPFS コミュニティと協力して、トルコ語 Wikipedia の完全なミラーを IPFS 上に公開しました。ユーザーは、政府がブロックしていない IPFS ゲートウェイを通じてアクセスできました。これは、IPFS 検閲への抵抗を示す最もよく引用される証拠です。

勇敢なブラウザ: Brave は、ネイティブ IPFS サポートを搭載した最初の主要ブラウザであり、ユーザーが解決できるようにしました ipfs:// パブリック ゲートウェイを介して URL を送信するか、ブラウザからローカルの Kubo ノードを直接実行します。これにより、何千万ものユーザーが設定なしで IPFS を利用できるようになりました。

オーディウス: 分散型音楽ストリーミング プラットフォームは、すべての音楽を独自のコンテンツ ノードを介して IPFS に保存します。アーティストがアップロードし、プラットフォームがピンを留め、リスナーがストリーミングします。何百万ものユーザーとトークン化されたクリエイターエコノミーを抱える実際の消費者向けアプリケーション。

OpenSea および NFT マーケットプレイス: Ethereum、Polygon、Solana 上の NFT メタデータとメディアの大部分は、ピニング サービスを通じて IPFS に保存されます。保存されている固有のコンテンツの量としては、これは IPFS の単一の使用例としては最大です。

dApp フロントエンド: Uniswap、Aave、1inch、その他多くの主要な DeFi プロトコルは、フロントエンド ビルドを IPFS に公開し、複数のサービスに固定します。検閲への耐性を重視するユーザーは、チームのドメインが占有されたり、DNS に汚染されたりした場合でも、IPFS 経由でこれらのフロントエンドに直接アクセスできます。

リスクと正直な制限

IPFS は強力なプロトコルですが、魔法ではないため、マーケティングでは IPFS が実際に提供するものを過剰に販売することがあります。 IPFS でプロジェクトに賭ける前に理解する必要があるリスクと制限を以下に示します。

最初にして最大のリスクは ピンの信頼性。あなたのコンテンツは、誰かがピン留めしている限り存続します。多くの場合、無料利用枠にはストレージとレートの制限があります。これらを超えてアップグレードしない場合は、ピンが削除される可能性があります。プロジェクトが重要な場合は、有料ピンニングまたはセルフホスティングを計画し、アーカイブ用に Filecoin 取引を検討してください。

2 番目のリスクは ゲートウェイ集中化。現在、ほとんどの「IPFS ユーザー」は、少数のゲートウェイにアクセスする HTTP ユーザーです。ゲートウェイがさらに統合されたり、規制の圧力に直面したりすると、現実的な分散化の話は弱まってしまいます。複数のゲートウェイを使用し、パワー ユーザーに実際のノードを実行するよう奨励することで軽減します。

第三弾は プライバシー。 IPFS は匿名ではありません。 CID を要求すると、ピア ID と IP がピアに表示され、DHT ノードを実行している人は誰でも、どの CID が要求されているかを確認できます。機密コンテンツの場合、IPFS だけでは十分ではありません。暗号化またはオニオンルート転送が必要です。

第4回目は レイテンシ。コールド ストレージからの取得は、特に複製が不十分な CID の場合、遅くなる可能性があります。 DHT はラウンド トリップを追加し、ビットスワップは洗練された CDN ほど最適化されていません。高トラフィックの動的コンテンツの場合、IPFS は適切なツールではありません。

第5回目は、 データの永続性に関する誤解。 CID は、同じコンテンツが常に同じアドレスを持つという意味で永続的です。ただし、コンテンツをホストするノードがない場合、アドレスは何も解決されません。永続性は、IPFS 自体の機能ではなく、ピン留めと Filecoin 取引の機能です。

IPFS、ステーブルコイン、Web3 プラミング

IPFS が Web3 で果たすあまり目立たないが重要な役割の 1 つは、監査可能かつ不変である必要があるガバナンス文書、サービス利用規約、およびリスク パラメーター セットのストレージ層としてです。メジャー ステーブルコイン 発行者と DeFi プロトコルは、スマート コントラクトから参照される IPFS CID として、認証文書、準備レポート、ガバナンス提案を公開します。これにより、トークン所有者は、発行者の Web サーバーに依存しない改ざん防止された履歴記録を得ることができます。

同じパターンが DAO ガバナンスにも現れています。提案テキストと裏付け文書は IPFS に固定されているため、オンチェーン投票では常に人々が投票していた正確な内容が参照されます。スナップショットやタリーなどのツールは、IPFS 固定プロポーザルをネイティブにサポートします。過去のプロポーザルを確認すると、 ブロックチェーンエクスプローラー をクリックして説明をクリックすると、通常は IPFS から CID をロードします。

よくある質問

結論

IPFS は、過去 10 年間の広範な分散コンピューティング運動から生まれた最も重要なインフラストラクチャの 1 つです。位置ベースのアドレス指定をコンテンツベースのアドレス指定に置き換えることで、Web が初期の頃から抱えていた問題、つまりリンクが切れ、コンテンツが消失し、集中サーバーが単一障害点を作成する問題が解決されました。 IPFS は Web に関するすべてを修正するわけではありませんが、不変性と復元力から最も恩恵を受けるインターネットの部分に対して、強力で実用的な代替手段を提供します。

正直な要約は、IPFS は、NFT メタデータ、dApp フロントエンド、アーカイブ文書、ガバナンス記録、分散パブリッシングなど、整合性が重要となる静的でアドレス指定可能な長期コンテンツに対して非常にうまく機能するということです。高スループットの動的コンテンツ、追加の暗号化のないプライベート データ、およびミリ秒の遅延が必要なユースケースでは、あまり効果がありません。プロトコルは成熟しており、ツールはHeliaとKuboを使用して堅牢であり、ピン留めサービスの環境は十分に競争力があるため、誰でも数分以内にコンテンツのアップロードを開始できます。

正直な注意点も同様に重要です。ゲートウェイの集中化により、少数の通信事業者に大量のトラフィックが静かに集中します。 PIN の信頼性は、誰が請求書を支払うかによって完全に決まります。 Filecoin や堅牢なピン留めがなければ、「永続ストレージ」に関するマーケティングは誤解を招きます。これらの制限を理解していれば、IPFS は素晴らしいツールです。そうしないと、静かに朽ちていくNFTコレクション、フロントエンドを失ったdApp、誰も見ていないときに消えるアーカイブを出荷する可能性があります。 IPFS を慎重に使用し、耐久性が重要な場合は Filecoin またはプロによるピン留めと組み合わせれば、最新の Web3 スタックの最も強力なストレージ プリミティブの 1 つを手に入れることができます。