IPFS ファイルはどのようになっているのでしょうか?どうやって構築すればいいのでしょうか?

IPFS は本質的に、ファイル、Web サイト、アプリケーション、およびデータを保存およびアクセスするための分散システムです。トランスポート層に依存しないため、伝送制御プロトコル (TCP)、uTP、UDT、QUIC、TOR、さらには Bluetooth を含むさまざまなトランスポート層を介して通信できます。

HTTP と比較して、IPFS の転送速度が速い理由は、IPFS がハッシュ識別によってファイルを検索するためです。ハッシュを取得したら、「このコンテンツ (ハッシュ) の所有者は誰か」を尋ねてネットワークに接続します。次に、対応するノードに接続してダウンロードします。つまり、ポイントツーポイントのカバレッジが形成され、非常に高速で広範囲にわたる、すぐに使用できるルーティングが可能になります。

I PFSノード

IPFS は本質的に、IPFS オブジェクトを取得および共有するための P2P システムです。 IPFS ノードは 2 つのフィールドを持つデータ構造です。

データ: 256 KB 未満の非構造化バイナリデータの容量
リンク: 他のIPFSノードにリンクできる

リンク構造には 3 つのデータフィールドがあります。

名前: リンクの名前
ハッシュ: リンクされているIPFSオブジェクトのハッシュ
サイズ: リンクされたIPFSノードの累積サイズ（リンクがたどられている場所を含む）

IPFS ノードは通常、Base58 でエンコードされたハッシュによって参照されます。たとえば、IPFS コマンドラインツールを使用して、ハッシュ QmarHSr9aSNaPSR6G9KFPbuLV9aEqJfTk1y9B8pdwqK4Rq を持つ IPFS オブジェクトを表示してみましょう。

すべてのハッシュが「Qm」で始まることに気付くかもしれません。ハッシュは実際にはマルチハッシュであるため、ハッシュ自体がマルチハッシュの最初の 2 バイトでハッシュ関数とハッシュの長さを指定します。上記の例では、16 進数の最初の 2 バイトは 1220 です。12 はこれが SHA256 ハッシュ関数であることを示し、20 はハッシュのバイト単位の長さ (32 バイト) を示します。

データと名前付きリンクにより、IPFS に Merkle DAG と呼ばれる構造のオブジェクトコレクションが提供されます。DAG は有向非巡回グラフを意味し、Merkle はこれを、暗号化ハッシュを使用してコンテンツをアドレス指定する暗号化認証データ構造として表します。

グラフ構造を視覚化するために、ノードにデータがあり、グラフエッジ上の他の IPFS オブジェクトを指すリンクがあるグラフを通じて IPFS オブジェクトを視覚化します。リンクの名前はグラフエッジのラベルになります。

ここでは、IPFS オブジェクトで表現できるさまざまなデータ構造の例を示します。

ファイルシステム

IPFS は、ファイルとディレクトリで構成されるファイルシステムを簡単に表現できます。次の例を通じてファイル表現を分解することができます。

小さなアーカイブ

小さなファイル (< 256 kB) は、データがファイルの内容 (および小さなヘッダーとフッター) であり、リンクがない (つまり、リンク配列が空である) IPFS オブジェクトによって表されます。ファイル名は IPFS オブジェクトの一部ではないことに注意してください。そのため、名前が異なり内容が同じ 2 つのファイルは、同じ IPFS オブジェクト表現を持ち、したがってハッシュも同じになります。 ipfs add コマンドを使用して、小さなファイルを IPFS に追加できます。

上記の IPFS オブジェクトのファイルの内容を表示するには、ipfs cat を使用します。

ipfs オブジェクトを使用してインフラストラクチャを表示すると、次の結果が得られます。

ファイルを次のように視覚化します。

大きなファイル

大きなファイル (> 256 kB) は、< 256 kB のファイルチャンクを指すリンクのリストで表され、このオブジェクトが大きなファイルを表していることを指定する最小限のデータのみで、ファイルチャンクへのリンクの名前は空の文字列になります。

ディレクトリ構造

ディレクトリは、ファイルまたは他のディレクトリを表す IPFS オブジェクトを指すリンクのリストによって表されます。リンクの名前は、ファイルまたはディレクトリの名前です。たとえば、ディレクトリ test_dir の次のディレクトリ構造を考えます。

ファイル hello.txt と my_file.txt の両方に、Hello World! という文字列が含まれています。 \n.ファイルtesting.txtには、文字列Testing 123\nが含まれています。

このディレクトリ構造を IPFS オブジェクトとして表現すると、次のようになります。

Hello World! に注意してください。 \nファイルは自動的に重複排除され、\nそのファイル内のデータは IPFS 内の 1 つの論理的な場所 (ハッシュアドレスで指定) にのみ保存されます。

IPFS コマンドラインツールは、ディレクトリリンク名をシームレスにたどってファイルシステムを移動できます。

バージョン管理されたファイルシステム

IPFS は、Git がバージョン管理されたファイルシステムに使用するデータ構造を表すことができます。 Git コミットオブジェクトについては、Git ブックで説明されています。 Commit オブジェクトの主なプロパティは、以前のコミットを指す parent0、parent1 などの名前を持つ 1 つ以上のリンクと、コミットが参照するファイルシステム構造を指す名前オブジェクト (Git のツリー) へのリンクがあることです。

以前のファイルシステムディレクトリ構造に 2 つのコミットが一緒に含まれていた同じ例を使用しましょう。最初のコミットは元の構造で、2 番目のコミットでは、ファイル my_file.txt を元の Hello World ではなく別の世界に更新しています。

また、ここでは自動重複排除が有効になっているため、2 番目のコミットの新しいオブジェクトはメインディレクトリ、新しいディレクトリ my_dir、および更新されたファイル my_file.txt だけであることに注意してください。

ブロックチェーン

過去のブロックは常に後続のブロックのハッシュによってリンクされているため、ブロックチェーンは自然な DAG 構造を持っています。 Ethereum ブロックチェーンなどのより高度なブロックチェーンには、IPFS オブジェクトを使用してエミュレートできる Merkle-Patricia ツリー構造を持つ関連する状態データベースもあります。

各ブロックに次のデータが含まれる単純なブロックチェーンモデルを想定します。

取引対象リスト
前のブロックへのリンク
状態トライ/データベースのハッシュ

このブロックチェーンは、IPFS で次のようにモデル化できます。

状態データベースを IPFS に配置すると重複排除の効果が得られることがわかりました。 2 つのブロック間では、状態全体 (データ負荷が大幅に増加する) ではなく、変更された状態エントリのみを明示的に保存する必要があります。

ここで興味深い点は、ブロックチェーン上にデータを保存することと、ブロックチェーン上にデータのハッシュを保存することの違いです。 Ethereum プラットフォームでは、状態データベースの肥大化を最小限に抑えるために、関連する状態データベースにデータを保存するために高額の手数料を支払う必要があります。したがって、大きなデータではデータ自体を保存するのではなく、データの IPFS ハッシュを状態データベースに保存するのが一般的な設計パターンです。

通常、ブロックチェーンは、すべてのマイナーが複製するグローバル台帳内のデータ（つまり、チェーン自体に保存されているデータ）と、チェーン内で参照される可能性があるがすべてのノード間で複製されていないデータを区別します。

関連する状態データベースを持つブロックチェーンがすでに IPFS で表現されている場合、すべてが IPFS に保存され、ブロックのハッシュのみが状態データベースのハッシュを必要とするため、ブロックチェーンにハッシュを保存することとブロックチェーンにデータを保存することの区別があいまいになります。この場合、誰かがブロックチェーンに IPFS リンクを保存すると、データがブロックチェーン自体に保存されているかのように、そのリンクをシームレスにたどってデータにアクセスできます。

ただし、マイナーが新しいブロックを作成するときに処理する必要があるものを確認することで、オンチェーンとオフチェーンのデータストレージを区別することは可能です。現在の Ethereum ネットワークでは、マイナーは状態データベースを更新するトランザクションを処理する必要があります。これを行うには、変更が行われた場所を更新できるように、完全な状態データベースにアクセスする必要があります。

したがって、IPFS で表されるブロックチェーン状態データベースでは、データを「オンチェーン」または「オフチェーン」としてマークする必要があります。マイナーにとって、「オンチェーン」データはローカルマイニングに不可欠であり、このデータはトランザクションによって直接影響を受けます。「オフチェーン」データは、マイナーの手に触れることなく、ユーザーが更新する必要があります。

<<: [Filecoinに関する100の質問と回答（写真付き）] 質問35：ラッキーバイアスとは何ですか？

>>: IPFS 公式 @ You |第106回週報