IPFS ホワイトペーパー: Web3.0 を構築するための惑星間ファイルシステム!

IPFS ホワイトペーパーでは、単一障害点のないファイルシステムに対するピアツーピアのバージョン管理アプローチについて説明します。データはコンテンツアドレス指定されるため、ネットワーク内のノードは互いに信頼する必要がありません。この記事によると、IPFS は HTTP を置き換えて Web を分散化できる可能性があるとのことです。

IPFS -高速でインデックス可能、バージョン管理されたピアツーピアのファイルシステム

まとめ

IPFS (Inter Planetary File System)は、すべてのコンピュータデバイスを同じファイルシステムに接続するように設計されたピアツーピアの分散ファイルシステムです。ある意味では、IPFS は Web に似ていますが、Web は集中型であるのに対し、IPFS は Git リポジトリを使用した分散ストレージを備えた単一の Bittorrent クラスターです。つまり、IPFS は、コンテンツアドレス指定ハイパーリンクを備えた高スループットのコンテンツアドレス指定ブロックストレージモデルを提供します。これにより、バージョン管理されたファイルシステム、ブロックチェーン、さらには永続的な Web サイトの構築に使用できる一般化された Merkle DAG データ構造が形成されます。 IPFS は、分散ハッシュテーブル、インセンティブブロック交換、自己認証名前空間を組み合わせたものです。 IPFS には単一障害点がなく、ノードは互いに信頼する必要がありません。

1. はじめに

グローバル分散ファイルシステムの分野では、多くの人が試みてきました。いくつかのシステムは大きな成功を収めましたが、完全に失敗したシステムも多くあります。学術的な試みの中では、AFS[6]が成功例であり、現在では広く利用されています。しかし、他の[7,? ] 同じ結果は得られませんでした。学術分野以外では、オーディオおよびビデオメディアのピアツーピアファイル共有システムで最も広く使用されています。最も注目すべきは、Napster、KaZaA、BitTorrent[2]によって導入されたファイル配信システムが1億人の同時ユーザーをサポートしていることです。現在でも、BitTorrent は 1 日あたり数千万のアクティブノードを維持しています。これらの学術的なファイルシステム理論に基づいて実装されたアプリケーションは数多くあります。ただし、これらのシステム理論は基本層ではなくアプリケーション層にあります。その結果、世界中に低遅延の配信を提供するためのユニバーサルなファイルシステムインフラストラクチャフレームワークが存在しません。

おそらく、HTTP のような「十分に優れた」システムがすでに存在しているからでしょう。これまで、HTTP は「分散ファイルシステム」プロトコルとして使用され、大規模に導入されてきました。ブラウザと組み合わせると、技術的にも社会的にも大きな影響力を持ちます。現在では、インターネット経由でファイルを転送する際の事実上の標準となっています。しかし、彼は過去 15 年間に発明された数十の高度なファイル配布技術を採用しませんでした。一方では、下位互換性の制約と新しいモデルへの現在の投資により、http Web のインフラストラクチャを継続的に進化させることはほぼ不可能です。しかし、ある観点から見ると、http の出現以来、多くの新しいプロトコルが登場し、広く使用されるようになりました。 HTTP プロトコルをアップグレードすると、新しい機能が導入され、現在の HTTP プロトコルが強化されますが、ユーザーエクスペリエンスは低下します。

トラフィック量が多い小規模な組織でも、小さなファイルを移動する方が比較的安価であるため、一部の業界では長い間 HTTP を使用し続けてきました。しかし、私たちは新たな課題とともに、データ配信の新しい時代を迎えています。

ペタバイト規模のデータセットのホスティングと配布。
組織全体にわたるビッグデータコンピューティング。
大容量の高解像度オンデマンドまたはリアルタイムメディアストリーミング。
大規模データセットのバージョン管理とリンク。
重要なファイルなどの偶発的な損失を防ぎます。

これらの多くは、「あらゆる場所に大量のデータが存在する」と要約できます。重要な機能と帯域幅の問題により、さまざまなデータに対する HTTP 配信プロトコルの使用を中止しました。次のステップは、それらを Web 自体の一部にすることです。

効率的なデータ配布とは直交して、バージョン管理システムは重要なデータコラボレーションワークフローの開発を目指してきました。 Git は、分散データ操作をモデル化および実装するための多くの便利なメソッドを開発した分散ソースコードバージョン管理システムです。 Git ツールチェーンは、多くのファイル配布システムに著しく欠けている柔軟なバージョン管理機能を提供します。 Camlistore[? など、Git にヒントを得た新しいソリューションが登場しています。 ]、個人ファイルストレージシステム、Dat[? ]データコラボレーションツールチェーンとデータセットパッケージマネージャー。 Gitは、強力なファイル分散戦略を可能にするMerkle DAGデータモデルをコンテンツに含んでいるため、分散ファイルシステムの設計に影響を与えてきました[9]。このデータ構造が高スループットのファイルシステムの設計にどのように影響するか、また Web 自体をどのように拡張するかについては、まだ調査されていません。

この論文では、これらの問題を解決することを目的とした新しいピアツーピアのバージョン管理ファイルシステムである IPFS を紹介します。 IPFS は、これまでに成功した多くのシステムの利点を組み合わせています。 IPFS は、これらの参照システムの合計よりも優れた結果を生み出します。 IPFS の基本原則は、すべてのデータを同じ Merkle DAG の一部としてモデル化することです。

2. 背景

このセクションでは、IPFS で採用されている成功したピアツーピアシステムテクノロジの重要な特性について説明します。

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

分散ハッシュテーブル (DHT) は、ピアツーピアシステムに関するメタデータを調整および維持するために広く使用されています。たとえば、メインライン DHT は、すべてのピアノードを追跡する分散ハッシュテーブルです。

2.1.1 カデムリアDHT

Kademlia[10]は、以下を提供する人気のDHTです。

大規模ネットワークでの効率的なクエリ: 平均 O(log2N) ノードで連絡先をクエリします。（例えば、100,000ノードの20ホップネットワーク）
低い調整オーバーヘッド: 他のノードに送信される制御メッセージの数を最適化します。
あらゆる種類の攻撃に耐性があり、長寿命のノードを優先します。
GnutellaやBitTorrentなどのピアツーピアアプリケーションで広く使用されており、2000万以上のノードのネットワークを形成しています[16]。

2.1.2 コーラルDSHT

一部のピアツーピアファイルシステムではデータブロックをDHTに直接保存しますが、この「不要なノードにデータを保存すると、ストレージと帯域幅が浪費されます」[5]。 Coral DSHT は、特に重要な 3 つの点で Kademlia を拡張します。

Kademlia は、ID が「最も近い」(XOR 距離を使用) キーノードに値を保存します。これはアプリケーションデータの局所性を考慮せず、すでにデータを持っている可能性のある「遠くの」ノードを無視し、必要かどうかにかかわらず「最も近い」ノードにデータを保存するように強制します。これにより、大量のストレージと帯域幅が浪費されます。代わりに、Coral は、対応するデータブロックを提供できるピアのアドレスを保存します。
Coral は DHT API を get_value(key) から get_any_values(key) (DSHT では「sloppy」) に変更しました。これは、Coral ユーザーに必要なのは完全なリストではなく、1 つの (動作中の) ピアだけであるためです。その代わりに、Coral はサブセットを「最も近い」ノードにのみ配布し、ホットスポット (キーが人気になったときに最も近いノードすべてが過負荷になる) を回避できます。
さらに、Coral は、地域とサイズに基づいて、クラスターと呼ばれる別の DSHT 階層を構成します。これにより、ノードはまずそのエリア内のピアにクエリを実行し、「リモートノードにクエリを実行せずに近くのデータを見つける」[5]ことができ、検索の待ち時間が大幅に短縮されます。

2.1.3 S/カデムリアDHT

S/Kademlia[1]は悪意のある攻撃を防ぐためにKademliaを拡張します。方法は2つあります。

S/Kad は、NodeId の生成によって Sybill 攻撃が防止されたことを確認するソリューションを提供します。ノードは PKI 公開鍵と秘密鍵のペアを生成する必要があります。そこからアイデンティティを導き出し、お互いに署名します。 1 つのスキームでは、プルーフ・オブ・ワークを使用して、シビルの生成を高価にします。
S/Kad ノードは、分離したパス上の直接リンクを検索し、ネットワーク内に不正なノードが多数存在する場合でも、正直なノードが相互にリンクできるようにします。ネットワーク内に不正なノードが半分存在したとしても、S/Kad は 85% の成功率を達成できます。

2.2 ブロック交換 - BitTorrent

BitTorrent[3]は、信頼できないピアノード（スウォーム）の共同ネットワーク内で個々のファイルデータ部分を配布できる、広く使用されている成功したピアツーピア共有ファイルシステムです。 IPFS は、BitTorrent とそのエコシステムの主要な機能から次のようにインスピレーションを得ています。

BitTorrent のデータ交換プロトコルは、他の側面に貢献するノードに報酬を与え、相手側のリソースのみを利用するノードを罰する、ビット・フォー・タットのインセンティブ戦略を採用しています。
BitTorrent ピアはファイルの可用性を追跡し、希少なファイルを優先して送信します。これにより、シードノードの負担が軽減され、非シードノードが相互にトランザクションできるようになります。
BitTorrent の標準的な報復戦略は、一部の搾取的な帯域幅共有戦略に対して非常に脆弱です。しかし、PropShare[8]は、エクスプロイト戦略に抵抗し、クラスターのパフォーマンスを向上させることができる、異なるピアツーピアの帯域幅割り当て戦略です。

2.3 バージョン管理システム - Git

バージョン管理システムは、時間の経過とともに変化するファイルをモデル化し、異なるバージョンを効率的に配布するための機能を提供します。人気のバージョン管理システム Git は、配布に適した方法でファイルシステムツリーへの変更をキャプチャするための強力な Merkle DAG オブジェクトモデルを提供します。

不変オブジェクトは、ファイル (BLOB)、ディレクトリ (ツリー)、および変更 (コミット) を表します。
ハッシュオブジェクトの内容を暗号化することで、オブジェクトはアドレス指定可能になります。
他のオブジェクトへのリンクが埋め込まれ、Merkle DAG が形成されます。これにより、いくつかの有用な整合性とワークフローのプロパティが提供されます。
多くのバージョンメタデータ (ブランチ、タグなど) は単なるポインター参照であるため、作成と更新のコストは低くなります。
バージョンの変更では、参照が更新されるか、オブジェクトが追加されるだけです。
分散バージョンの変更は、他のユーザーからは単にオブジェクトの移動とリモート参照の更新として表示されます。

2.4 自己認証ファイルシステム - SFS

SFS[12, 11]は、(a)分散信頼チェーンと(b)均等に共有されるグローバル名前空間という2つの魅力的な実装を提案した。 SFS は自己構築テクノロジ - 登録ファイルを導入します。リモートファイルシステムのアドレス指定には次の形式を使用します。

/sfs/ :
場所: サービスネットワークの場所を表します
HostID = ハッシュ(公開キー || 場所)

したがって、SFS ファイルシステムの名前によってサービスが認証され、ユーザーはサービスによって提供される公開キーを通じてそれを検証し、共有秘密キーをネゴシエートしてすべての通信を確実に行うことができます。すべての SFS インスタンスはグローバル名前空間を共有します。名前の割り当ては暗号化され、中央のエンティティによって制御されません。

3. IPFSの設計

IPFS はピアツーピアであり、どのノードにも特権はありません。 IPFS ノードは IPFS オブジェクトをローカルストレージに保存し、ノードは相互に接続してファイルやその他のデータ構造を表すオブジェクトを転送します。 IPFS プロトコルは、さまざまな機能を担当する一連のサブプロトコルに分かれています。

リンクを持つコンテンツアドレス指定の不変オブジェクトの Merkle DAG。ファイル階層や通信システムなどの任意のデータ構造を表すために使用されます。詳細についてはセクション3.5を参照してください。

アイデンティティ - ノードアイデンティティの生成と検証を管理します。セクション3.1で説明されています。
ネットワーク - さまざまな基盤となるネットワークプロトコルを使用して、他のピアとの接続を管理します。設定可能。詳細についてはセクション3.2を参照してください。
ルーティング - 特定のピアとオブジェクトを見つけるための情報を維持します。ローカルおよびリモートのクエリに応答します。デフォルトは DHT ですが、変更可能です。セクション3.3で説明されています。
Swap - 効率的なブロック配布をサポートする新しいブロック交換プロトコル (BitSwap)。市場をシミュレートし、データの複製を弱めます。取引戦略は互換性があります。セクション3.4で説明されています。
Object IPFS は、DHT、BitTorrent、Git、SFS などの以前のピアツーピアシステムの成功したアイデアを統合した分散ファイルシステムです。 IPFS の貢献は、成熟したテクノロジーを簡素化、進化させ、個々の部分の合計よりも優れた単一の統合システムに統合することです。 IPFS は、アプリケーションの作成と展開のための新しいプラットフォームと、バージョン管理されたビッグデータ用の新しい配布システムを提供します。 IPFS は Web 自体を進化させる可能性もあります。
ファイル - Git に触発されたバージョン管理されたファイルシステム階層。詳細についてはセクション3.6を参照してください。
命名 - 自己認証の変更可能な名前システム。詳細についてはセクション3.7を参照してください。

これらのサブシステムは独立しておらず、統合されて互いの特性を活用します。ただし、プロトコルスタックを下から上に構築しながら、それらを個別に記述すると便利です。表記: Go 言語では次のデータ構造と関数が指定されています。

3.1 アイデンティティ

ノードはNodeIdによって識別されます。NodeIdはS/Kademlia [1]の静的暗号パズルを使用して作成された公開鍵の暗号ハッシュです。ノードは公開鍵と秘密鍵（パスワードで暗号化）を保存します。ユーザーは起動ごとに「新しい」ノード ID を自由に設定できますが、これにより蓄積されたネットワークの利点が失われます。インセンティブノードは変更されません。

タイプ NodeId マルチハッシュ
type Multihash []byte // 自己記述型暗号ハッシュサマリー
型 PublicKey []byte
type PrivateKey []byte // 自己記述型秘密鍵
型 Node 構造体 {
ノードID ノードID
公開鍵公開鍵
PriKey プライベートキー
}

S/Kademlia に基づく IPFS アイデンティティ生成:

難易度 =
n = ノード{}
する {
n.公開キー、n.秘密キー = PKI.genKeyPair()
n.NodeId = ハッシュ(n.PubKey)
p = count_preceding_zero_bits(ハッシュ(n.NodeId))
} （p < 難易度）

最初に接続するときに、ピアは公開鍵を交換し、hash(other.PublicKey) が other.NodeId と等しいかどうかを確認します。そうでない場合、接続は終了します。

暗号化機能に関する注意事項:

IPFS は、システムを特定の機能選択セットに固定するのではなく、自己記述的な値をサポートします。ハッシュダイジェスト値は、使用されるハッシュ関数とダイジェストの長さ（バイト単位）を指定するヘッダーを含むマルチハッシュ形式で保存されます。例えば：
1

これにより、システムは (a) 最適な機能の使用例 (例: より強力なセキュリティとより高速なパフォーマンス) を選択し、(b) 機能の選択が変化するにつれて進化することができます。自己記述的な値により、さまざまなパラメータ選択を互換性を持って使用できます。

3.2 ネットワーク

IPFS ノードは、ネットワーク内の何百もの他のノードと定期的に通信しており、その通信は広域ネットワーク全体にわたる可能性があります。 IPFS ネットワークスタックの機能:

トランスポート層: IPFS は任意のトランスポートプロトコルを使用でき、WebRTC データチャネルに最適です [? ]（ブラウザ接続用）またはuTP（LEDBAT [14]）である。
信頼性：基盤となるネットワークが信頼性を提供しない場合、IPFSはuTP（LEDBAT [14]）またはSCTP [15]を使用して信頼性を提供することができます。
接続性：IPFSはICE NATウォール貫通技術[13]も使用できます。
整合性: ハッシュチェックサムを使用して、メッセージの整合性をチェックできます。
検証可能性: メッセージの信頼性は、送信者の公開鍵を使用した HMAC を使用して確認できます。

3.2.1 ピアノードのアドレス指定に関する注意事項:

IPFS は任意のネットワークを使用できます。ただし、IP の取得は行わず、IP レイヤーに直接依存しません。これにより、オーバーレイネットワークで IPFS を使用できるようになります。

IPFS は、基盤となるネットワークでの使用を容易にするために、バイト文字列で構成された多層アドレスとしてアドレスを保存します。マルチレイヤーアドレスは、アドレスとそのプロトコルを解析しやすい形式で表現する方法を提供します。例えば：
# SCTP/IPv4 接続
/ip4/10.20.30.40/sctp/1234/
# TCP/IPv4 経由でプロキシされた SCTP/IPv4 接続

/ip4/5.6.7.8/tcp/5678/ip4/1.2.3.4/sctp/1234/

3.3 ルーティング

IPFS ノードには、(a) 他のピアのネットワークアドレス、および (b) 特定のオブジェクトの提供専用のピアノードを見つけるために使用できるルーティングシステムが必要です。

IPFS は S/Kademlia と Coral に基づく DSHT を使用します。これについてはセクション 2.1 で詳しく説明します。オブジェクトのサイズと使用パターンの点では、IPFSはCoral[5]やMainline[16]に似ているため、IPFS DHTはサイズに基づいて保存された値を区別します。小さな値（1KB以下）はDHTに直接保存されます。より大きな値の場合、DHT は値インデックスのみを保存します。これは、そのタイプの値に対して特定のサービスを提供できるピアノードの NodeId です。

DSHT のインターフェースは次のとおりです。
タイプIPFSルーティングインターフェース{
FindPeer(node NodeId) // 特定のNodeIdのネットワークアドレスを取得します。
SetValue(key []bytes, value []bytes) // 小さなメタデータを DHT に保存します。
GetValue(key []bytes) // DHTからメタデータを取得します。
ProvideValue(key Multihash) //このノードが大きなデータを提供できることを宣言します。
FindValuePeers(key Multihash, min int) // ビッグデータを提供するノードを取得します。
}

注: ユースケースが異なれば、根本的に異なるルーティングシステムが必要になります (例: WAN では DHT、LAN では静的 HT)。したがって、 IPFS ルーティングシステムはユーザーのニーズに応じて置き換えることができます。 上記のインターフェースを使用するだけで、システムは正常に動作し続けます。

3.4 ブロック交換 - BitSwap プロトコル

IPFS の BitSwap プロトコルは BitTorrent にヒントを得たもので、ピアノード間でデータブロックを交換することでデータを配布します。 BT と同様に、各ピアノードはダウンロード中にダウンロードしたデータを他のピアノードに継続的にアップロードします。 BT プロトコルとは異なり、BitSwap はトレントファイル内のデータブロックに限定されません。 BitSwap プロトコルには永続的な市場があります。このマーケットには、各ノードが取得したいすべてのブロックデータが含まれます。チャンクが何の一部であるかに関係なく、たとえば .torrent ファイルなどです。これらのデータチャンクは、ファイルシステム内のまったく無関係なファイルから取得される可能性があります。市場はすべてのノードで構成されています。

物々交換システムの概念は仮想通貨の作成が可能であることを意味しますが、そのためには通貨の所有権と移転を追跡するためのグローバルな台帳が必要になります。これは BitSwap 戦略として実装することができ、今後の論文で検討される予定です。

基本的なケースでは、BitSwap ノードはブロックの形式で互いに直接的な値を提供する必要があります。これは、ノード間でのブロックの分散が補完的であり、各当事者が必要なものを取得できる場合にのみうまく機能します。これは通常は当てはまらず、場合によってはノードが独自のブロックに対して動作する必要があります。ノードにピアが必要とするブロックがない場合（またはまったくブロックがない場合）、ピアが必要とするブロックの検索の優先順位が低くなります。これにより、ノードは、たとえ興味がなくても、希少なフラグメントをキャッシュして伝播するようになります。

3.4.1 BITSWAPクレジット

このプロトコルには、ノード自身がブロックを必要としない場合でも、他のノードが必要とするブロックをシードするようにノードを動機付けるインセンティブメカニズムが必要です。したがって、BitSwap ノードは、支払いを受けることを期待して、ピアノードにブロックを送信することに非常に積極的です。しかし、リーチ攻撃（空のロードノードはブロックを共有しない）を防ぐ必要があり、単純なクレジットのようなシステムがこれらの問題を解決します。

ピアは（バイト単位の認証を介して）残高を追跡します。
負債が増加すると、確率は減少し、ピアは債務者にブロックを確率的に送信します。

ノードがピアに送信しないことを決定した場合、ノードはピアの ignore_cooldown タイムアウトを無視することに注意してください。これにより、送信者が複数回送信しようとすること (フラッディング攻撃) を防止します (BitSwap のデフォルトは 10 秒です)。

3.4.2 BITSWAPの戦略

BitSwap ピアは、全体的なブロックスワップパフォーマンスにさまざまな劇的な影響を及ぼすさまざまな戦略を使用します。 BitTorrentでは、標準ポリシーが明確に定義されており（報復的対応）、BitTyrant [8]（可能な限り共有する）、BitThief [8]（脆弱性を悪用し、決して共有しない）、PropShare [8]（比例して共有する）に至るまで、さまざまなポリシーが実装されています。 BitSwap ピアも同様に、さまざまな戦略 (善意と悪意) を実装できます。機能を選択するときは、次の点を目標にしてください。

トランザクション全体とノードのトランザクション容量を最大化します。
空のロードノードがトランザクションを悪用して侵害するのを防ぐため。
未知の戦略に効果的に抵抗します。
信頼できる仲間に対してはより寛容になります。

これらの戦略のギャップを探ることは将来の課題です。実際に使用される代替関数の 1 つは、負債比率によってスケーリングされるシグモイド関数です。

負債比率をノードとそのピア間で次のようにします。

r によれば、負債ノードに送信する確率は次のようになります。

図 1 からわかるように、ノードの負債比率がノードの確立クレジットの 2 倍を超えると、負債のあるノードに送信する確率は急激に低下します。

図1 rが増加する場合の送信確率

負債比率は信頼の尺度です。負債は、以前に大量のデータを正常に交換したノードに対しては寛容ですが、信頼されておらず理解されていないノードに対してははるかに厳しくなります。これにより、(a) 多数のノードを作成する攻撃者 (シビル攻撃) にとって障害となります。 (b) ノードが一時的にデータを提供できない場合でも、以前に成功したトランザクションノード間の関係を保護します。 (c) 関係が再び証明されるまで、関係が悪化したノード間の通信を最終的にブロックします。

3.4.3 BITSWAP元帳

BitSwap ノードは、それ自身と他のすべてのノード間のトランザクションを記録する台帳を保持します。これにより、ノードは履歴を追跡し、改ざんを防ぐことができます。リンクがアクティブになると、BitSwap ノードは元帳情報を交換します。元帳情報がまったく同じでない場合、元帳は再初期化され、発生したクレジットと負債は失われます。悪意のあるノードは、自らの負債を清算する目的で、意図的に「これらの」元帳を失うことになります。ノードが信頼を獲得せずに認証を承認するのに十分な負債を蓄積する可能性は低いです。パートナーノードはこれを不正行為とみなし、トランザクションを拒否することができます。

元帳構造体型{
所有者ノードID
パートナー NodeId
送信バイト数
バイト受信整数
タイムスタンプタイムスタンプ
}

ノードは分散元帳の履歴を自由に保持できますが、現在の元帳エントリのみが有用であるため、正しい操作には必要ありません。ノードは必要に応じて、あまり役に立たないもの（古いもの（他のピアが存在しない可能性がある）や小さいもの）から始めて、自由に元帳を収集することもできます。

3.4.4 BITSWAPの詳細な説明

BitSwap ノードには次の単純なプロトコルがあります。

// 追加の状態が保持される
BitSwap構造体型{
ledgers map[NodeId]Ledger // このノードに知られている元帳（非アクティブを含む）
アクティブマップ[NodeId]ピア // 現在他のノードへの接続が開いている
need_list []Multihash // このノードに必要なブロックのチェックサム
have_list []Multihash // このノードが持つブロックのチェックサム
}
ピア構造体型{
ノードID
ledger 元帳 // ノードとこのピア間の元帳
last_seen Timestamp // 最後に受信したメッセージのタイムスタンプ
want_list []Multihash // ピアが要求するすべてのブロックのチェックサム
// ピアのピアが要求するブロックを含む
}
// プロトコルインターフェース:
インターフェースピア {
オープン (nodeid: NodeId、ledger: Ledger);
send_want_list (want_list : WantList);
send_block(ブロック: Block) -> (complete:Bool);
閉じる(最終: Bool);
}

ピア接続のライフサイクルの概略:

オープン: ピアは合意するまで互いに元帳を送信します。
送信: want_lists とブロックがピアノード間で交換されます。
閉じる: ピアノードが切断されます。
無視: (特別) ノードが送信防止戦略を採用している場合、ピアは無視されます (待機タイムアウト)。

Peer.open(NodeId、Ledger)。

リンクが発生すると、ノードはリンクされた元帳を初期化し、リンクされた元帳を保存するか、新しいゼロ化された元帳を作成します。次に、台帳を含んだオープンメッセージをピアノードに送信します。

オープンメッセージを受信した後、ピアノードは接続を受け入れるかを選択できます。受信者の元帳によると、送信者が信頼できないエージェントである場合（転送がゼロ未満であるか、未払いの負債が大きい場合）、受信者はリクエストを無視することを選択できます。リクエストの無視は、エラーを修正し、攻撃者を阻止するための時間を確保するために、 ignore_cooldown タイムアウトを使用して確率的に実装されます。

接続が成功した場合、受信者はローカル台帳を使用して Peer オブジェクトを初期化し、last_seen タイムスタンプを設定します。次に、受信した元帳を自身の元帳と比較します。 2 つの元帳がまったく同じであれば、リンクが開かれます。元帳がまったく同じでない場合、このノードは新しいゼロ化された元帳を作成して送信します。

ピア.send_want_list(WantList)

接続が開いている場合、ノードは接続されているすべてのピアに want_list を送信します。これは、(a) 接続を開いた後、(b) ランダム間隔のタイムアウト後、(c) want_list が変更された後、および (d) 新しいブロックが受信された後に実行されます。

want_list を受信すると、ノードはそれを保存します。次に、必要なブロックを所有しているかどうかを確認します。そうであれば、want_list で必要なブロックは、上記の BitSwap 戦略に従って送信されます。

Peer.send_block(ブロック)

ブロックの送信は簡単です。ノードは単にデータブロックを送信します。すべてのデータが受信されると、受信側は複数のハッシュチェックサムを計算して、必要なデータであるかどうかを確認し、確認メッセージを送信します。

正しいブロック転送が完了すると、受信者はブロックを need_list から have_list に移動し、最後に受信者と送信者の両方が転送された追加データバイト数を反映するように元帳を更新します。

送金が検証に失敗した場合、送信者に責任があるか、受信者を攻撃しているかのいずれかとなり、受信者は後続の取引を拒否することを選択できます。 BitSwap は信頼性の高い伝送チャネル上で動作することが想定されているため、データが BitSwap に送信される前に伝送エラー (正当な送信者のエラーに対してペナルティが発生する可能性がある) が検出されることが想定されることに注意してください。

ピアを閉じる(ブール)

close に渡される最後のパラメータは、接続を閉じることが送信者の意図であるかどうかを示します。パラメータ値が false の場合、受信側は接続をすぐに再開することができ、チェーンが接続を途中で閉じることを回避できます。

ピアノードは、次の 2 つの場合に接続を閉じます。

silent_wait タイムアウトが経過し、ピアノードから情報が受信されなかった場合 (BitSwap はデフォルトで 30 秒を使用します)、ノードは Peer.close(false) を送信します。
ノードが終了し、BitSwap が閉じられると、ノードは Peer.close(true) を送信します。

クローズメッセージを受信すると、受信側と送信側は切断され、保存されているすべての状態がクリアされます。元帳は、後で便利に使用できるように保存できますが、それは元帳が将来役立つと考えられる場合に限られます。

注記：

非アクティブな接続上の非オープンメッセージは無視する必要があります。 send_block メッセージを送信する場合、受信者はブロックが必要なものかどうか、また正しいかどうかを確認する必要があります。もしそうなら、このブロックを使用してください。つまり、すべての不規則なメッセージにより、受信側は close(false) メッセージをトリガーし、接続を強制的に再初期化することになります。

3.5 マークルDAGオブジェクト

DHT と BitSwap により、IPFS は高速で安定した配信とストレージを実現する巨大なピアツーピアシステムを構築できます。最も重要なのは、 IPFS がループのない有向グラフである Merkle DAG を構築し、オブジェクト間のリンクがハッシュ暗号化されてソースとターゲットに埋め込まれることです。これは Git のデータ構造の一般化です。 Merkle DAGS は、IPFS に次のような多くの便利なプロパティを提供します。

コンテンツアドレス可能: すべてのコンテンツは、リンクを含む複数のハッシュチェックサムによって一意に識別されます。
改ざん防止: すべてのコンテンツはチェックサムを使用して検証されます。データが改ざんされたり破損したりした場合、IPFS はそれを検出します。
重複排除: すべてのオブジェクトは同一のコンテンツを持ち、一度だけ保存されます。これは、git ツリーやコミット、データの共通部分などのオブジェクトのインデックス作成に役立ちます。

IPFS オブジェクトの形式は次のとおりです。

IPFSLink構造体型{
名前文字列 // このリンクのエイリアス
ハッシュマルチハッシュ // 対象の暗号化ハッシュ
Size int // ターゲットの合計サイズ
}
IPFSObject構造体型{
links []IPFSLink //リンク配列
data []byte //不透明なコンテンツデータ
}

IPFS Merkle DAG は、データを保存するための非常に柔軟な方法です。唯一の要件は、オブジェクト参照が (a) コンテンツアドレス可能であり、(b) 上記の形式でエンコードされていることです。 IPFS を使用すると、アプリケーションはデータドメインを完全に制御できます。アプリケーションは、IPFS で理解できないデータであっても、任意のカスタム形式のデータを使用できます。独立した内部オブジェクトリンクテーブルにより、IPFS は次のことが可能になります。

すべてのオブジェクト参照をオブジェクト形式で一覧表示します。例:

> ipfs ls /XLZ1625Jjn7SubMDgEyeaynFuR84ginqvzb
XLYkgq61DYaQ8NhkcqyU7rLcnSa7dSHQ16x 189458 以下
XLHBNmRQ5sJJrdMPuu48pzeyTtRo39tNDR5 19441 スクリプト
XLF4hwVHsVuZ78FZK6fozf8Jj9WEURMbCX4 5286 テンプレート

foo/bar/baz などの文字列パス検索を解決します。オブジェクトが与えられると、IPFS は最初のパスコンポーネントを解析し、それをハッシュしてオブジェクトのリンクテーブルに格納し、次にパスの 2 番目のコンポーネントを取得して、このプロセスを繰り返します。したがって、Merkle DAG では、任意のデータ形式の任意の文字列パスを使用できます。
すべてのオブジェクト参照を再帰的に解決します。

> ipfs refs --recursive
/XLZ1625Jjn7SubMDgEyeaynFuR84ginqvzb さん
翻訳:
ＸＬＹｋｇｑ６１ＤＹａＱ８ＮｈｋｃｑｙＵ７ｒＬｃｎＳａ７ｄＳＨＱ１６ｘ
XLHBNmRQ5sJJrdMPuu48pzeyTtRo39tNDR5
XLWVQDqxo9Km9zLyquoC9gAP8CL1gWnHZ7z

オリジナルのデータ構造であるパブリックリンク構造は、あらゆるデータ構造を構築するための IPFS の必須コンポーネントです。 Git のオブジェクトモデルが DAG にどのように適合するかは簡単にわかります。その他の潜在的なデータ構造:

キーバリューストレージ
従来のリレーショナルデータ
トリプルデータストレージ
文書発行システム
コミュニケーションプラットフォーム
暗号通貨ブロックチェーン

これらのシステムはすべて IPFS Merkle DAG を適用できるため、これらのシステムのより複雑なアプリケーションで IPFS を転送プロトコルとして使用できるようになります。

3.5.1 ルート

IPFS オブジェクトは文字列パスを介して移動できます。パス形式は、従来の UNIX ファイルシステムおよび Web と一致しています。 Merkle DAG リンクにより、トラバーサルが容易になります。 IPFS のフルパスの形式は次のとおりです。

# フォーマット
ipfs の/

＃例

/ipfs/XLYkgq61DYaQ8NhkcqyU7rLcnSa7dSHQ16x/foo.txt

/ipfs プレフィックスを使用すると、マウントポイントが競合しない限り、既存のシステムにマウントできます (マウントポイント名はもちろん構成可能です)。 2 番目のパスコンポーネント (IPFS では最初のコンポーネント) はオブジェクトのハッシュです。グローバルルートが存在しない場合には、通常はこれが当てはまります。ルートオブジェクトには、分散 (場合によっては切断) 環境内の何百万ものオブジェクト間で一貫性を維持するという不可能なタスクがあります。したがって、アドレスのアドレス指定可能性を使用してルートをシミュレートします。すべてのオブジェクトはハッシュを通じてアクセスできます。つまり、パスオブジェクト /bar/baz を指定すると、最終オブジェクトは誰でもアクセスできます。

ipfs の/バー/バズ
ipfs の/バズ

ipfs の

3.5.2 ローカルオブジェクト

IPFS クライアントには、IPFS によって管理されるオブジェクトのローカルの生データを保存および取得するための外部システムであるローカルストレージが必要です。ストレージのタイプは、ノードの使用事例によって異なります。ほとんどの場合、このストレージはハードディスク領域の一部にすぎません (leveldb などのキー値ストアを使用してローカルファイルシステムによって管理されるか、IPFS クライアントによって直接管理されます)。非永続キャッシュなどのその他のケースでは、ストレージは RAM の一部です。

最終的に、すべてのブロックは IPFS でアクセス可能になり、ブロックは一部のノードのローカルストレージに保存されます。ユーザーがオブジェクトを要求すると、そのオブジェクトが検索され、ダウンロードされ、少なくとも一時的にローカルに保存されます。これにより、設定可能な時間にわたって高速シークが提供されます。

3.5.3 オブジェクトのロック

特定のオブジェクトの存続を確保したいノードは、このオブジェクトをロックできます。これにより、この特定のオブジェクトがノードのローカルストレージに保存されることが保証されます。関連するすべての派生オブジェクトを再帰的にロックすることも可能です。これにより、指定されたすべてのオブジェクトがローカルストレージに保存されます。これは、参考資料を含む文書の長期保存に特に役立ちます。これにより、IPFS はリンクが永続的であり、オブジェクトが他の指定されたオブジェクトの存続を保証できる Web になります。

3.5.4 オブジェクトの公開

IPFS はグローバルに分散されています。何千ものユーザーファイルが共存できるように設計されています。 DHTは、コンテンツハッシュアドレス指定テクノロジーを使用して、オブジェクトの公開を公平、安全、完全に分散させるようにします。オブジェクトのキーをDHTに追加し、ピアノードとして追加して、他のユーザーにパスを提供することにより、オブジェクトを公開できます。 Gitのように、オブジェクトは本質的に不変であることに注意することが重要です。新しいバージョンには異なるハッシュ値があるため、新しいオブジェクトです。追跡バージョンは、追加のバージョンオブジェクトのジョブです。

3.5.5オブジェクトレベルの暗号化

IPFSは、オブジェクトレベルの暗号化操作を処理できます。暗号化または署名されたオブジェクトは、生のバイトの暗号化と検証を可能にする特別なフレームワークに包まれています。

タイプ暗号化されたObject struct {
オブジェクト[]バイト//暗号化された元のオブジェクトデータ
タグ[]バイト//オプションの暗号化タグ
タイプSignedObject struct {
オブジェクト[]バイト//署名された生のオブジェクトデータ
署名[]バイト// HMAC署名
publicKey [] multihash //複数のハッシュアイデンティティキー
}

暗号化操作は、オブジェクトのハッシュ値を変更し、新しい異なるオブジェクトを定義します。 IPFは署名を自動的に検証し、ユーザー指定のキーチェーンを使用してデータを復号化します。暗号化されたデータへのリンクも保護されており、復号化キーなしでオブジェクトを通過することは不可能です。また、親オブジェクトが1つのキーで暗号化される可能性があるという現象もありますが、子オブジェクトは別のキーで暗号化されているか、まったく暗号化されていません。これにより、共有オブジェクトへのリンクが安全になります。

3.6ファイル

IPFは、Merkle DAGの上にバージョンされたファイルシステムをモデリングするための一連のオブジェクトも定義します。このオブジェクトモデルはgitに似ています。

ブロック：データの可変サイズのブロック
リスト：ブロックまたはその他のリンクリストのコレクション
ツリー：ブロック、リンクされたリスト、またはその他の木のコレクション
コミット：バージョンの履歴の木のスナップショット

Gitオブジェクト形式と一致するモデルを使用したいと思っていましたが、分散ファイルシステムに役立つ特定の機能を導入するには、ある程度の分離が必要だったでしょう。

高速サイズのルックアップ（オブジェクトにすでに追加されている合計バイトサイズ）
大きなファイルの複製を削除する（リストオブジェクトに追加）
コミットは木に埋め込まれています。

ただし、IPFSファイルオブジェクトはgitに非常に似ており、2つの間で通信することができます。さらに、情報を失うことなく、Gitオブジェクトのセットをインポートおよび変換できます。（UNIXファイル許可など）。

タグ：次のファイルオブジェクト形式はJSONを使用します。 IPFにはJSON変換が含まれていますが、ファイルオブジェクトの構造は依然としてProtoBUFSバイナリエンコードを使用していることに注意してください。

3.6.1ファイルオブジェクト： BLOB

BLOBオブジェクトはファイルを表し、アドレス指定可能なデータのユニットが含まれています。 IPFSブロブは、Gitブロブまたはファイルシステムブロックのようなものです。ユーザーのデータを保存します。 IPFSファイルは、リストまたはブロブを使用して表現できることに注意する必要があります。ブロブにはリンクがありません。

{
「データ」：「ここにあるデータ」、//ブロブにはリンクがありません
}

3.6.2ファイルオブジェクト：リスト

リストオブジェクトは、いくつかのIPFSブロブから連結された大きなファイルまたは重複排除されたファイルを表します。リストには、並べ替えられたブロブまたはリストオブジェクトのシーケンスが含まれています。ある意味では、IPFSリスト関数は間接ブロックファイルシステムのようなものです。リストには他のリストが含まれている可能性があるため、リンクされたリンクリストとバランスの取れた木のトポロジを含めることができます。指示されたグラフの同じノードが複数の異なる場所に表示され、ファイル内の重複排除が可能になります。もちろん、ループはハッシュアドレス指定によって強制されるため、不可能です。

{
'data'：['blob'、 'list'、 'blob']、//リストには、データとしてオブジェクトタイプの配列があります
「リンク」：[
{'hash'： 'xlykgq61dyaq8nhkcqyu7rlcnsa7dshq16x'、
「サイズ」：189458}、
{'hash'： 'xlhbnmrq5sjjrdmpuu48pzeyttro39tndr5'、
「サイズ」：19441}、
{'hash'： 'xlwvqdqxo9km9zlyquoc9gap8cl1gwnhz7z'、
「サイズ」：5286} //リンクリストには名前がありません
]

}

3.6.3ファイルオブジェクト：ツリー

IPFのツリーオブジェクトは、ディレクトリ、ハッシュの名前のマップを表すGitのツリーオブジェクトと似ています。ハッシュ値は、塊、リスト、その他の木、またはコミットを示しています。従来のパスの命名は、長い間Merkle Dagによって実装されてきたことに注意してください。

{
「データ」：['Blob'、 'list'、 'blob']、//ツリーには、データとしてオブジェクトタイプの配列があります
「リンク」：[
{'hash'： 'xlykgq61dyaq8nhkcqyu7rlcnsa7dshq16x'、
'name'： 'less'、 'size'：189458}、
{'hash'： 'xlhbnmrq5sjjrdmpuu48pzeyttro39tndr5'、
「名前」：「スクリプト」、「サイズ」：19441}、
{'hash'： 'xlwvqdqxo9km9zlyquoc9gap8cl1gwnhz7z'、
「名前」：「テンプレート」、「サイズ」：5286} //木には名前があります
]
}

3.6.4ファイルオブジェクト：コミット

IPFのコミットオブジェクトは、バージョン履歴の任意のオブジェクトのスナップショットを表します。 gitと同様ですが、あらゆる種類のオブジェクトを表すことができます。また、イニシエーターオブジェクトもリンクします。

3.6.5バージョン制御

コミットオブジェクトは、履歴バージョンのオブジェクトの特定のスナップショットを表します。 2つの異なるコミットでオブジェクト（およびサブオブジェクト）を比較すると、ファイルシステムの2つの異なるバージョン間の違いが明らかになります。コミットとすべての子オブジェクトへのすべての参照にアクセスできる限り、すべての以前のバージョンが利用可能になり、すべてのファイルシステムの変更のすべての履歴がアクセスできます。これは、Merkle DAGオブジェクトモデルから分離されています。

GITバージョン制御ツールのすべての機能は、IPFのユーザーが利用できます。オブジェクトモデルは正確に一貫していませんが、互換性もあります。これは

Gitツールバージョンを構築して、IPFSオブジェクトグラフに変換します。
ヒューズファイルシステムを構築し、IPFSツリーをGITリポジトリとしてマウントし、Gitファイルシステムの読み取り/書き込みをIPFS形式に変換します。

3.6.6ファイルシステムパス

Merkle DAGに見られるように、IPFSオブジェクトは、String Path APIを使用して通過できます。 IPFSファイルオブジェクトは、IPFをファイルシステムをUNIXに簡単にマウントできるように特別に設計されています。ファイルオブジェクトは、ディレクトリを表すために、ツリーにデータを持たないように制限します。コミットは、ディレクトリの代表の形で表示されるか、ファイルシステムに完全に隠される可能性があります。

3.6.7リストとブロブにファイルを分離します

大きなファイルのバージョンと配布における最も重要な課題の1つは、それらを個別のブロックに分離する正しい方法を見つけることです。 IPFがファイルの異なるタイプごとに正しい分離方法を提供できると考えるのではなく、IPFは次のオプションを提供します。

LBFS [？]と同じように、Rabinフィンガープリント[？]を使用して、より適切なブロック境界を選択します。
rsync [？]ローリングチェックサムアルゴリズムを使用して、バージョン間のブロックの変化を検出します。
ユーザーは、特定のファイルに調整された「高速分離」機能を指定できます。

3.6.8パス検索パフォーマンス

パスベースのアクセスには、オブジェクトグラフを通過する必要があります。各オブジェクトを取得するには、DHTでキーを探す必要があり、ピアノードに接続してからブロックを取得します。これにより、特に見つかったパスが多くのサブパスで構成されている場合、かなりのオーバーヘッドが作成されます。次の方法では、頭上を遅くすることができます。

ツリーキャッシュ：すべてのオブジェクトはハッシュアドレスであるため、無限にキャッシュできます。さらに、木は一般的に小さいため、IPFはブロブと比較して最初に木をキャッシュします。
平らな木：どのツリーでも、特別な平らな木がリンクされたリストを作成でき、すべてのオブジェクトにこのツリーからアクセスできます。平らな木では、名前は元の木から分離されたパスで、スラッシュで区切られています。

たとえば、上記のTTT111の平らな木の場合、次のように：
{
'データ'：
['ツリー'、「ブロブ」、「ツリー」、 'list'、 'blob' 'blob']、
「リンク」：[
{'Hash'： ' '、'サイズ '：1234
'name'： 'ttt222-name'}、
{'Hash'： ' '、'サイズ '：123、
'name'： 'ttt222-name/bbb111-name'}
{'Hash'： ' '、'サイズ '：3456、
'name'： 'ttt333-name'}、
{'Hash'： ' '、'サイズ '：587、
'name'： 'ttt333-name/lll111-name'}、
{'Hash'： ' '、'サイズ '：22、
'name'： 'ttt333-name/lll111-name/bbb222-name'}、
{'Hash'： ' '、'サイズ '：22
'name'： 'bbb222-name'}
]}

3.7 IPN： 命名および揮発性状態

これまでのところ、IPFはコンテンツアドレス可能なDAGオブジェクトを形成するためにピアブロック交換を形成しています。これにより、不変のオブジェクトの公開と取得が提供されます。これにより、これらのオブジェクトのバージョン履歴を追跡することもできます。ただし、ここには1つの重要な成分が残っています。可変ネーミングです。これがなければ、リンクがIPFを送信した場合、すべての新しいコンテンツの通信は間違いなく偏っています。これで、同じパスの変数状態を取得する方法が必要です。

これは、最終的な不安定なデータが必要な場合、不変のマークルダグの構築に多くの努力を払う理由について詳しく説明する価値があります。 IPFをMerkle DAGの特徴として扱うだけです。オブジェクトは、（a）ハッシュ値、（b）整合性チェック、（c）他のオブジェクトをリンクし、（d）無限のキャッシュを介して取得できます。 ある意味で： オブジェクトは永遠です。

これらは、ネットワーク全体のリンク間でファイルを移動するのは非常に高価な高性能分散システムの重要な機能です。 Object Contentableは、次の特性を備えたWebを構築します。（a）優れたブロードバンド最適化、（b）信頼できないコンテンツサービス、（c）永遠のリンク、（d）オブジェクトとその参照を永久に予約します。

不変のコンテンツアドレス指定可能なオブジェクトとMerkle Dagsという名前で、可変ポインターはMerkle Dagを指し、多くの成功した分散システムに現れる二分法をインスタンス化します。これらのシステムには、不変のオブジェクトと可変リファレンスを使用したGITのバージョン制御システム、およびUNIX分散後継者Plan9 [？]ファイルシステムが含まれます。 LBFS [？]は、変数インデックスと不変のブロックも使用します。

3.7.1自己認証名

SFS [12、11]のネーミングスキームを使用して、暗号化されたグローバルネームスペースで変異できる自己認証名を作成する方法を提供します。 IPFSソリューションは次のとおりです。

IPFSで思い出してください：
nodeid = hash（node.pubkey）
このパスの下で各ユーザーに変数名空間を割り当てます。
/IPNS/
ユーザーは、このパスの下で自分の秘密鍵で署名されたオブジェクトを公開できます。
/ipns/xlf2ipq4jd3udex5xp1kbehrhemutaa8vm/
他のユーザーがオブジェクトを取得すると、署名が公開キーとnodeidと一致するかどうかを検出できます。これは、ユーザーの公開されたオブジェクトの信頼性を検証し、変数状態の取得を達成します。

次の詳細に注意してください。

IPN（Inter Planetaryの名前空間）別々のプレフィックスは、プログラムのために、そして人間の読書の利便性のために、可変性と不変のパスの間に簡単に認識できる区別を作成します。
これはコンテンツアドレス可能なオブジェクトではないため、公開することは、IPFSおよびルーティングシステムの唯一の変数状態割り当てシステムに依存します。プロセスは、（1）このオブジェクトを最初に通常の不変のIPFSオブジェクトとして公開し、（2）このオブジェクトのハッシュ値をルーティングシステムへのメタデータの値として公開します。
routing.setValue（nodeid、）
公開されたオブジェクトのリンクは、コマンドスペースのサブ名として機能します。
/ipns/xlf2ipq4jd3udex5xp1kbehrhemutaa8vm/
/ipns/xlf2ipq4jd3udex5xp1kbgehrhemutaa8vm/docs
/ipns/xlf2ipq4jd3udex5xp1kbgehrhemutaa8vm/docs/ipfs
一般に、Commitオブジェクトやその他のオブジェクトを公開するときに履歴バージョンのレコードを使用することをお勧めします。これにより、ユーザーは以前に使用した名前を見つけることができます。ただし、これは必ずしも必要ではないため、ユーザーに選択する必要があります。

ユーザーがオブジェクトを公開する場合、同じ方法を使用してオブジェクトを公開できないことに注意してください。

3.7.2人間の友好的な名前

IPNは実際に名前を割り当てて割り当てる良い方法ですが、長いハッシュ値を名前として使用するため、それほど使いやすいものではなく、そのような名前を覚えにくいことはよく知られています。 IPNはURLを処理するのに十分ですが、多くのオフライン送信作業で使用するのはそれほど簡単ではありません。したがって、IPFは次のテクノロジーを使用して、IPNのユーザーフレンドリーを高めます。

ピアノードリンク

SFSに触発されて、ユーザーは他のユーザーのオブジェクトを独自のオブジェクト（コマンドスペース、ホームディレクトリなど）に直接リンクできます。これの利点の1つは、信頼できるWebを作成することです（古いAuthenticity認証モデルもサポートします）：

＃アリスはボブにリンクします
IPFSリンク//友達 /ボブ /
＃イブがアリスへのリンク
IPFS link /<eve-pk-hash /friends /alice /
＃イブもボブにアクセスできます
/<eve-pk-hash/friends/alice/friends/bob
＃Verisign認証ドメインにアクセスしてください
/ /foo.com

DNS TXT IPNレコード

/ IPNS /が有効なドメイン名である場合、IPFはDNS TXTレコードで重要なIPNを探します。 IPFは、見つかった値を1つのオブジェクトのハッシュ値または別のIPNのパスに変換します。
＃DNSTXTレコード
ipfs.benet.ai。 txt 'ipfs = xlf2ipq4jd3u ...'
＃シンボリックリンクとして動作します
LN -S /IPNS /XLF2IPQ4JD3U /IPNS/FS.BENET.AI

Proquit Readable Identifier

バイナリエンコードを読み取り可能なファイルに変換する方法は常にあります。 IPNSはProquit [？]をサポートしています。次のように：
#proquitステートメント
/ipns/dahih-dolij-sozuk-vosah-luvar-fuluh
＃次の形式に分解します
/IPNS/KHAWNPRXYVXKQPDZ

名前サービスを短くします

多くのサーバーが出現し、名前を短くし、ユーザーに名前空間を提供するサービスを提供します。 DNSやWebのURLと同じように、今見ている：
＃ユーザーは、下からリンクを取得できます
/ipns/shorten.er/foobar
＃次に、名前空間に入れます

/ipns/xlf2ipq4jd3udex5xp1kbgehrhemutaa8vm

3.8 IPFの使用

IPFSは、さまざまな方法で使用されるように設計されています。ここで、私が追求し続ける使用法のいくつかを紹介します。

マウントされたグローバルファイルシステムとして、 /IPFおよび /IPNの下に取り付けられています
マウントされた個人同期フォルダーとして、バージョン管理、公開、およびバックアップを自動的に実行します
暗号化されたファイルまたはデータ共有システムとして
すべてのソフトウェアのバージョンパッケージマネージャーとして
仮想マシンとしてのルートファイルシステム
ファイルシステムをVMとして起動します（ハイパーバイザーの下）
データベースとして：アプリケーションはMerkle DAGデータモデルにデータを直接書き込み、すべてのバージョン、バッファー、IPFSが提供する割り当てを取得できます
リンクされた（および暗号化された）通信プラットフォームとして
CDNとして、大きなファイルの整合性を確認します（SSLを使用せずに）
暗号化されたCDNとして
Webページでは、Web CDNとして
リンクとして、常に新しい永遠のウェブがあります

IPFによって達成される目標：

IPFSライブラリは、使用するために独自のアプリケーションにエクスポートできます
コマンドラインツールはオブジェクトを直接操作できます
ヒューズ[？]またはカーネルモデルを使用してファイルシステムをマウントします

4。未来

IPFのアイデアは、数十年にわたる成功した探索と分散システムのオープンソースの産物です。 IPFは、これまでに成功してきたシステムの多くの優れたアイデアを組み合わせています。新しいBitsWapプロトコルに加えて、 IPFSの最大の機能は、システムの結合と包括的な設計です。

IPFSは、分散型ネットワークインフラストラクチャへの野心であり、多くの異なるタイプのアプリケーションをIPFに構築できます。少なくとも、グローバルでマウント可能なバージョン制御ファイルシステムおよび名前空間として、または次世代ファイル共有システムとして使用できます。最良のケースは、IPFがWebをレベルにアップグレードできることです。貴重な情報を公開するとき、興味のある人はそれを強制せずに公開できます。出版機関のみがそれを公開することを許可する必要があります。ユーザーは情報の内容を信頼できます。情報の送信者を信頼するかどうかは関係ありません。別の機能は、いくつかの重要だが非常に古いファイルが失われないことです。 IPFは、私たちを永遠のWDBの世界に連れて行くことを楽しみにしています。

5。ありがとう

IPFSは、多くの素晴らしいアイデアやシステムの複雑さです。巨人の肩に立っていなければ、IPFはそのような野心的な目標を持っていることを敢えてしません。私は個人的に、これらのアイデアの長期的な議論に関与している人々に感謝します：David Dalrymple、Joe Zimmerman、およびAli Yahya、特に：Merkle Dag（David、Joe）の全体的なアーキテクチャ、ローリングハッシュブロッキング（David）、S/Kademlia sybill Protection（David、Ali）、およびDavid Mazieres for worth of s/kademlia sybill保護。

ホワイトペーパーの元のアドレス（外部ネットワーク用）：

https://ipfs.io/ipfs/qmr7gsqm93cx5eag6a6yrznde1fqv7ul6x1o4k7zrja3lx/ipfs.draft3.pdf

<<: [上級小規模教室] IPFS の関係系譜、技術アーキテクチャ、動作原理

>>: データは嘘をつかない、ビットコイン急騰の原動力は機関投資家