ブロックチェーン |人気の分散ストレージプラットフォーム Swarm と IPFS の分析

ブロックチェーンと分散コンピューティングに関して最も重要なのは、コンセンサス アルゴリズム (ネットワーク全体が決定について合意に達する方法) とスマート コントラクト (集中型の世界で私たちが毎日使用するアプリケーションを可能にするもの) です。しかし、日常的なアプリケーションに関しては、これらの属性だけでは今日の世界のニーズを満たすのに十分ではありません。上記の 2 つの項目だけに頼っていると、Netflix のようにお気に入りの映画や TV シリーズを視聴したり、Facebook のように思い出に残るビデオや写真を保存または共有したり、お気に入りのオンライン ゲーム (DOTA など) をブロックチェーン上でプレイしたりすることは想像しにくいでしょう。

今日のアプリケーションには、堅牢で安全、かつ分散化されたコンテンツ ストレージおよび配信システムが欠けています。

以下では、最も人気のある分散ストレージ プラットフォームのいくつかを調査し、評価します。

この記事はシリーズの最初の部分であり、主に Swarm と IPFS を紹介します。シリーズの「中盤」と「後半」では、それぞれ Sia、Storj、MaidSafe を紹介します。

1. 群れ

ステータス: アクティブ

例:

Swarm は分散ストレージ プラットフォームおよびコンテンツ配信サービスであり、Ethereum Web3 スタックのネイティブ ベース レイヤー サービスです。 Swarm の主な目的は、Ethereum の公開レコードの完全に分散化された冗長ストレージを提供することであり、特に DApp コードとデータ、およびブロックチェーン データを保存および配布することです。経済的な観点から見ると、参加者はストレージ容量と帯域幅リソースを効率的にプールして、Ethereum からインセンティブを受け取りながら、ネットワーク内のすべての参加者にこれらのサービスを提供できるようになります。

ターゲット

Swarm のより広範な目標は、分散型 Web アプリケーション (DApp) 開発者にインフラストラクチャ サービス (具体的には、メッセージング、データ ストリーミング、ピアツーピア アカウンティング、可変リソースの更新、ストレージ保険、規制スキャンと修復、支払いチャネル、データベース サービス) を提供することです。

エンドユーザーの観点から見ると、アップロードが特定のサーバーでホストされない点を除けば、Swarm は World Wide Web とそれほど違いはありません。 Swarm は、DDos 耐性、ゼロダウンタイム、フォールト トレラント、検閲耐性、自立型を備えたピアツーピアのストレージおよびサービス ソリューションを提供します。ユーザーがピアツーピア会計を通じて取引リソースの支払いを行えるインセンティブ システムが組み込まれています。 Swarm は、ドメイン名解決 (ENS を使用)、サービス支払い、コンテンツの可用性保証のために、Ethereum の devp2p マルチプロトコル ネットワーク層および Ethereum ブロックチェーンと深く統合されることを目指しています。

注意: ENS 名を解決するには、Swarm ノードを Ethereum ブロックチェーン (メインネットまたはテストネット) に接続する必要があります。

概要

Swarm は、新しい分散型インターネットのベースレイヤー インフラストラクチャを提供することを目指しています。 Swarm は、リソース (ストレージ、メッセージ転送、支払い処理) を相互に提供することで分散デジタル サービスを提供するノードのピアツーピア ネットワークです。 Ethereum Foundation は Swarm テストネットを運営しており、これを使用して Ethereum テストネット (ropsten) と同様の方法で機能をテストできます。誰でも、サーバー、デスクトップ、ラップトップ、モバイル デバイスで Swarm クライアント ノードを実行することでネットワークに参加できます。方法については、「Swarm を使い始める」の記事を参照してください。 Swarm クライアントは Ethereum スタックの一部であり、リファレンス実装は golang で記述されており、go-ethereum リポジトリにあります。現在、すべてのノードで実行されているのは POC バージョン 0.3 です。

Swarm は、DApps またはコマンドライン ツールが Swarm と対話するために使用できるローカル HTTP プロキシ API を提供します。メッセージングなどのモジュールは、PRC-JSON API に基づいてのみ利用可能です。テストネット上のインフラストラクチャ サービスは、機能を簡単にデモンストレーションし、無料アクセスを許可するためのパブリック ゲートウェイを提供するため、ユーザーは独自のノードを実行せずに Swarm を試すことができます。

Swarm は devp2p ネットワーク内のノードの集合であり、各ノードは同じネットワーク ID 上で bzz プロトコル スイートを実行します。

Swarm ノードは、ドメイン名解決のために 1 つ (または複数) の Ethereum ブロックチェーンに接続したり、帯域幅とストレージの補償のために Ethereum ブロックチェーンに接続したりすることもできます。同じネットワーク ID を実行しているノードは、支払いのために同じブロックチェーンに接続する必要があります。 Swarm ネットワークは、任意の整数であるネットワーク ID によって識別されます。

Swarm ではアップロードと消失が許可されているため、どのノードでも Swarm にコンテンツをアップロードしてオフラインにすることができます。ノードが失われたり利用できなくなったりしない限り、ノード間で利用可能なデータを継続的に渡す「同期」プロセスがあるため、コンテンツには引き続きアクセスできます。

パブリックゲートウェイ

Swarm は、DApps が Swarm と対話するために使用できるローカル HTTP プロキシ API を提供します。 Ethereum Foundation は、無料アクセスを許可するパブリック ゲートウェイをホストしているため、ユーザーは独自のノードを実行しなくても Swarm を試すことができます。

Swarm パブリック ゲートウェイは http://swarm-gateways.net にあります。ここでは常に最新の安定バージョンの Swarm が実行されます。

現在、ゲートウェイは限られたサイズのアップロードのみを受け入れます。将来的には、このゲートウェイにアップロードする機能は完全になくなる可能性があります。

アップロードとダウンロード

データ コンテンツのアップロードは、次の手順で構成されます: コンテンツをローカル Swarm ノードに「アップロード」し、続いてローカル Swarm ノードが生成されたデータ ブロックをネットワーク内のピアと「同期」します。一方、コンテンツのダウンロードは次の手順で構成されます。ローカルの Swarm ノードがネットワーク内のピアに関連データ チャンクを照会し、コンテンツをローカルで再構成します。

コンテンツリゾルバー: ENS

ENS 名を解決するには、Swarm ノードを Ethereum ブロックチェーン (メインネットまたはテストネット) に接続する必要があります。

ENS は、Swarm が人間が読める名前 (theswarm.eth など) でコンテンツを参照するために使用するシステムです。これは DNS システムと同様に動作し、人間が判読できる名前をマシン識別子 (この場合は、参照しているコンテンツの Swarm ハッシュ) に変換します。名前を登録し、それをサイトのルート マニフェストのコンテンツ ハッシュに解決することで、ユーザーは bzz://theswarm.eth/ のような URL 経由でサイトにアクセスできるようになります。

現在、主流のブラウザ (Chrome、Firefox、Safari など) は bzz プロトコルをサポートしていません。現在、これらのブラウザから bzz プロトコルにアクセスする場合は、HTTP ゲートウェイ (https://swarm-gateways.net/bzz:/theswarm.eth/ など) を使用するか、bzz プロトコルをサポートするブラウザ (Mist など) を使用する必要があります。

可変リソースの更新

可変リソースの更新は、Swarm POC3 の非常に実験的な機能です。活発に開発中ですので、変更される部分があるかもしれません。

このガイドでは、Swarm でデータを変更すると、アップロードしたデータによって返されるハッシュ値が予期しない方法で変更される可能性があることを学びました。可変リソースの更新により、Swarm は変更されたデータの永続的な識別子を保持する組み込みの方法を提供します。

変更されたデータへの同じポインターを維持するために、一般的な方法は、Ethereum Naming Service ENS を利用することです。ただし、ENS はオンチェーン機能であるため、他の部分の機能が制限されます。

• ENS リゾルバの更新にはそれぞれガスコストがかかります。
• 新しいブロックがマイニングされるよりも速くデータを変更することはできません。
• ENS を正しく解決するには、常にブロックチェーンに同期する必要があります。

可変リソースの更新により、ENS を使用せずに、変数以外の識別子を持つデータを変更できます。可変リソースは、リソースの作成時に取得されたキーを使用して、通常の Swarm オブジェクトのように参照できます。

ENS リゾルバ コントラクトと可変リソース更新の両方を使用する場合、MRU_MAINFEST_KEY を登録するために必要な初期トランザクションは 1 つだけです。キーはリソースの最新バージョンに解決されます (リソースを更新してもキーは変更されません)。可変リソースの更新を操作するには、HTTP API、Golang API、Swarm CLI の 3 つの方法があります。

注記：

• リソースを作成した秘密鍵 (アドレス) のみがそれを更新できます。
• 変更可能なリソースを作成するときに指定する必要があるパラメータの 1 つは、予想される更新頻度です。これは、リソースが更新される頻度 (秒単位) を示します。他のレートでリソースを更新することもできますが、そうするとリソースのインデックス作成プロセスが遅くなります。

Swarm での暗号化

対称暗号化は POC 0.3 で導入され、Swarm up アップロード コマンドで対称暗号化を簡単に使用できるようになりました。この暗号化メカニズムは、情報を保護し、Swarm ノードを処理するときにブロック データを読み取り不可能にするために使用されます。

Swarm はカウンターモード暗号化を使用してコンテンツを暗号化および復号化します。 Swarm にコンテンツをアップロードすると、アップロードされたデータは 4 KB のチャンクに分割されます。これらの各ブロックは、独立してランダムに生成された暗号化キーを使用してエンコードされます。この暗号化プロセスは Swarm ノード上でローカルに実行され、暗号化されていないデータは他のノードと共有されません。個々のチャンク (およびコンテンツ全体) への参照は、エンコードされたデータ ハッシュと暗号化キーの組み合わせになります。つまり、参照は標準の暗号化されていない Swarm 参照よりもわずかに長くなります (32 バイトではなく 64 バイト)。

ノードがコンテンツの暗号化されたチャンクを他のノードと同期する場合、完全な参照 (または復号化キー) は他のノードと共有されません。つまり、他のノードは生データにアクセスできず、同期されたブロックが暗号化されているかどうかを検出できません。

データを取得する場合、データはローカルの Swarm ノードでのみ復号化されます。取得プロセス全体を通じて、これらのチャンクは暗号化された形式でネットワークを通過するため、参加しているピアはそれらを復号化できません。これらは、ダウンロードに使用される Swarm ノード上でのみ復号化され、再構築されます。

注記：

• Swarm は暗号化をサポートしています。アップロードを元に戻す方法がないため、暗号化されていない機密データやプライベートデータをアップロードしないことを強くお勧めします。ユーザーは違法、物議を醸す、または不道徳なコンテンツをアップロードしないでください。
• Swarm は現在、--encrypt フラグで示される暗号化された swarm up コマンドと暗号化されていない swarm up コマンドの両方をサポートしています。将来的には変更される可能性があります。
• 暗号化機能は非決定論的であり (アップロード要求ごとに生成されるキーはランダムであるため)、API のユーザーは結果のべき等性に依存すべきではありません。したがって、暗号化を有効にして同じコンテンツを Swarm に 2 回アップロードすると、参照が異なります。

追伸

PSS (Postal Service over Swarm) は、強力なプライバシー機能を備えた Swarm 上のメッセージング プロトコルです。 PSS API は、API リファレンスで説明されている JSON RPC インターフェースを通じて公開されており、ここでは基本的な概念と機能についてのみ説明します。

PSS はまだ実験的な機能であり、積極的に開発されており、Swarm の POC3 から利用可能になります。何かが変わることを期待してください。

基礎

PSS を通じて、Swarm ネットワーク上の任意のノードにメッセージを送信できます。メッセージは、ブロック取得要求と同じ方法でルーティングされます。 PSS メッセージはブロック ハッシュ参照を使用せず、代わりにメッセージのペイロードとは無関係に、オーバーレイ アドレス空間内の宛先を指定します。ターゲットは、完全なオーバーレイ アドレスの場合は特定のノードとして記述でき、部分的にのみ指定されている場合はネイバーとして記述できます。メッセージは、転送 kademlia アルゴリズムを使用して DevP2P ピア接続を介して転送されます。このアルゴリズムは、kademlia ルーティングを使用してリレー ノード間の半安全なポイントツーポイント TCP 接続を介してメッセージを配信します。対象地域内では、メッセージがゴシップを使用してブロードキャストされます。

PSS メッセージは暗号化されているため、最終的な受信者はメッセージを復号化できます。暗号化は、非対称暗号化または対称暗号化のいずれかを使用して実行できます。

メッセージ ペイロードは、受信ノードによってメッセージ プロセッサに配布され、API を介してサブスクライバーに配布されます。

現在、PSS はメッセージの順序付け (ベスト エフォート配信) もメッセージの配信 (つまり、オフライン ノードへのメッセージはキャッシュもリレーもされません) も保証しません。

プライバシー機能

エンドツーエンドの暗号化により、PSS はプライベート通信にも適しています。

PSS は転送 kademlia アルゴリズムを使用して送信者を匿名化します。

部分的なアドレス指定を使用すると、pss は調整可能な範囲の受信者の匿名性を提供します。ターゲットとなる近隣ノードの数が多くなり、意図した受信者のカバレッジ アドレスのプレフィックスが表示される数が小さくなると、実際の受信者を特定することが難しくなります。一方、ダーク ルーティングは非効率的であるため、匿名性とメッセージ配信の遅延および帯域幅 (したがってコスト) の間にトレードオフがあり、どちらを選択するかはアプリケーションに委ねられます。

ハンドシェイク モジュールを使用すると、前方秘匿性が提供されます。

DAppノート

機密コンテンツは暗号化する必要があります。暗号化されたコンテンツの場合、アップロードされたデータは「保護」されます。つまり、ルート ブロックへの参照 (ファイルの Swarm ハッシュと暗号化キー) を知っているユーザーだけがコンテンツにアクセスできます。参照を公開するには（ENS または MRU で）追加の​​手順が必要になるため、ユーザーが暗号化を使用している限り、不注意な公開から簡単に保護できます。 Swarm のストレージ容量が限られているため、Swarm は明示的に保護されていないコンテンツを削除し、最終的にこれらのノードをゴミ箱に移動します。

ストレージ保険が実装されるまで (詳細についてはロードマップを参照)、テストネットではアップロードされたコンテンツの永続性が保証されません。参加しているすべてのノードは、義務を負うことなく自発的にサービスを提供し、自らの意志でコンテンツを削除しているものとみなされます。したがって、インセンティブ システムが運用される前は、ユーザーはいかなる状況でも Swarm を安全なストレージ メディアとして考慮しないでください。

Swarm は永続的なデータ構造であるため、Swarm には削除または除去操作の概念はありません。これは、コンテンツが、それを提供するインセンティブを持つ Swarm ノードに伝播されるためです。

2. IPFS

[[255016]]

ステータス:アクティブ (これはインセンティブ システムであり、「Filecoin」は非アクティブです)

例:

IPFS (Interplanetary File System) は、世界中で情報を配信する方法を根本的に変えることを目的としたピアツーピア (P2P) ファイル共有システムです。これは Swarm に似ていますが、Swarm は IPFS に似ているとも言えます。

IPFS には、通信プロトコルと分散システムにおけるいくつかの革新が含まれており、これらが組み合わさって独自のファイル システムが生成されます。したがって、IPFS が達成しようとしていることの幅広さと深さを理解するには、それを可能にする技術的な進歩と、IPFS が解決しようとしているすべての問題を理解することが重要です。

IPFS は HTTP を置き換えると主張しています。それでは、今日のインターネットがどのように機能するかを見てみましょう。

つまり、今日のインターネットは、ネットワーク全体でデータがどのように移動するかを記述するプロトコルの集合体です。時間の経過とともに、開発者はさまざまなプロトコルを使用し、このインフラストラクチャ上にアプリケーションを構築してきました。これらのプロトコルのうちの 1 つは、Web のバックボーンである HTTP (ハイパーテキスト転送プロトコル) です。これは 1991 年にティム・バーナーズ・リーによって発明されました。

HTTP は要求応答プロトコルです。クライアント (Web ブラウザなど) が外部サーバーにリクエストを送信します。その後、外部サーバーは応答メッセージを返します。たとえば、Google のホームページをクライアントに返します。これは位置アドレス指定可能なプロトコルです。つまり、ブラウザに google.com と入力すると、それが Google サーバーの IP アドレスに変換され、リクエストと応答のサイクルが開始されます。

HTTPの問題

あなたが授業中に座っていて、教授が特定の Web サイトにアクセスするように指示したとします。クラスの各生徒がウェブサイトにリクエストを送信し、応答を受け取ります。つまり、まったく同じデータがクラスのすべての生徒に個別に送信されることになります。生徒が 100 人いれば、リクエストも 100 件、応答も 100 件あります。明らかに、これは最も効率的なアプローチではありません。理想的には、これらの学生は物理的な近さを活用して、必要な情報をより効率的に取得できるようになります。

ネットワーク通信回線に問題がある場合、HTTP にも大きな問題が発生し、クライアントがサーバーに接続できなくなります。これは、ISP が停止した場合、国が特定のコンテンツをブロックした場合、またはコンテンツが単に削除または移動された場合に発生する可能性があります。この種の切断は、HTTP Web のいたるところで発生します。

HTTP の位置ベースのアドレス指定モデルは集中化を促進します。これにより、すべてのデータを少数のアプリケーションに簡単に信頼できるようになりますが、これにより Web 上の膨大な量のデータが無駄になります。これにより、これらのプロバイダーは私たちの情報に対して大きな責任と権限を持つことになります (Facebook など)。

HTTP は Web サイトの読み込みには最適ですが、大量のデータ (オーディオ ファイルやビデオ ファイルなど) を転送するようには設計されていません。これらの欠陥により、Napster (音楽共有ソフトウェア) や BitTorrent (映画やほぼすべてのもの) などのファイル共有システムに代わるシステムが登場し、主流の成功を収めることができた可能性があります。

2018 年現在、オンデマンドの HD ビデオ ストリーミングとビッグ データは普及しつつあります。私たちは、データを処理するためのますます強力なコンピューターを開発しながら、ますます多くのデータを生産/消費し続けています。クラウド コンピューティングの大きな進歩がこの移行を支えるのに役立っていますが、このすべてのデータを配布するために使用されるインフラストラクチャはほとんど変わっていません。

解決

IPFS はもともと、バージョン管理された科学データを迅速に移動できるシステムを構築するための Juan Benet の取り組みでした。これは、インターネット テクノロジ (DHT、Git バージョン コントロール システム、Bittorrent) のテスト済みの組み合わせです。 IPFS オブジェクトの交換を可能にする P2P Swarm を作成します。すべての IPFS オブジェクトは、暗号的に認証されたデータ構造 (Merkle DAG) を形成し、これを使用して他の多くのデータ構造を構築できます。あるいは、言い換えれば:

「IPFS は、すべてのコンピューティング デバイスを同じファイル システムに接続することを目的とした分散ファイル システムです。ある意味では、これは Web の本来の目的に似ていますが、IPFS は実際には Git オブジェクトを交換する Bittorrent Swarm に似ています。IPFS は、インターネットの重要な新しいサブシステムになる可能性があります。正しく構築されれば、HTTP を補完または置き換えることができます。より多くのものを補完または置き換えることができます。クレイジーに聞こえます。はい、クレイジーです。」

IPFS は基本的に、ファイルを取得して管理し、どこかに保存し、時間の経過とともにバージョンを追跡できるバージョン管理されたファイル システムです。 IPFS は、これらのファイルがネットワーク上でどのように移動するかも記録するため、分散ファイルシステムでもあります。

IPFS には、データとコンテンツがネットワーク上でどのように移動するかを管理するルールがあり、その性質は Bittorrent に似ています。このファイル システム層は、次のような非常に興味深いプロパティを提供します。

• ウェブサイトは完全に分散されています。
• このウェブサイトにはオリジンサーバーがありません。
• ウェブサイトは完全にクライアントのブラウザ上で実行できます。
• ウェブサイトをサーバーに接続する必要はありません。

これらのさまざまな技術革新がどのように連携するかを見てみましょう。

分散ハッシュテーブル

ハッシュ テーブルは、情報をキーと値のペアとして保存するデータ構造です。分散ハッシュ テーブル (DHT) では、データがコンピューターのネットワーク全体に分散されるため、効率的に調整され、ノード間の効率的なアクセスと検索が可能になります。

DHT の主な利点は、分散化、フォールト トレランス、およびスケーラビリティです。ノードは中央調整を必要とせず、ノードが故障したりオフラインになったりしてもシステムは確実に動作し、DHT は数百万のノードに対応できるように拡張できます。これらの特性に基づいて、Swarm はクライアント サーバー構造よりも柔軟性が高くなります。

ブロック交換

人気のファイル共有システム Bittorrent は、革新的なデータ交換プロトコルを利用することで、何百万ものノード間のデータ転送を正常に調整できますが、これはトレント エコシステムに限定されています。 IPFS は、BitSwap と呼ばれるプロトコルの一般化バージョンを実装しており、これはあらゆる種類のデータのマーケットプレイスとして機能します。この市場は、IPFS 上に構築された P2P ストレージ市場である Filecoin の基盤です。

マークルDAG

Merkle DAG は、Merkle ツリーと有向非巡回グラフ (DAG) のハイブリッドです。マークルツリーは、P2P ネットワーク上で交換されるデータ ブロックが正しく、破損しておらず、変更されていないことを保証します。この検証は、データ ブロックの暗号化ハッシュ関数を使用して行われます。これは、入力を受け取り、その入力に対応する一意の英数字文字列 (ハッシュ) を計算する関数です。与えられたハッシュ値に対して、入力が同じ値を生成するかどうかを確認するのは簡単ですが、ハッシュ値から入力を推測するのは困難です。

個々のデータ ブロックは「リーフ ノード」と呼ばれ、ハッシュされて「非リーフ ノード」を形成します。これらの非リーフ ノードは、すべてのデータ ブロックが単一のルート ハッシュ値で表せるようになるまで、一緒にハッシュされます。これを概念化する簡単な方法は次のとおりです。

DAG は、非循環のトポロジカルシーケンス情報をモデル化する方法です。 DAG の簡単な例としては家系図があります。 Merkle DAG は基本的に、ハッシュを使用して DAG 内のデータ ブロックとオブジェクトを参照するデータ構造です。これにより、いくつかの便利な機能が生まれます。各データ ブロックには一意のハッシュ値があるため、IPFS 上のすべてのコンテンツを一意に識別できます。さらに、次の図に示すように、データが変更されるとハッシュ値も変更されるため、データは改ざん不可能になります。

IPFS の基本原則は、生成された Merkle DAG 上ですべてのデータをモデル化することです。この安全機能の重要性はいくら強調してもし過ぎることはありません。たとえば、この原則は数兆ドル相当の資産を保護することができ、このアイデアがいかに強力であるかを示しています。

バージョン管理システム

Merkle DAG 構造のもう 1 つの強力な機能は、分散バージョン管理システム (VCS) の構築を可能にすることです。その典型的な例が GitHub です。GitHub を使用すると、開発者はプロジェクトで同時に簡単に共同作業を行うことができます。 GitHub 上のファイルは Merkle DAG を使用して保存およびバージョン管理されます。これにより、ユーザーはファイルの複数のバージョンを個別にコピーして編集し、保存し、後で編集したバージョンを元のファイルと結合することができます。

IPFS はデータ オブジェクトに対して同様のモデルを使用します。つまり、元のデータに対応するオブジェクトと新しいバージョンにアクセスできる限り、ファイル履歴全体を取得できます。データ ブロックはネットワーク経由でローカルに保存され、永続的にキャッシュできるため、IPFS オブジェクトは永続的に保存できます。

さらに、IPFS はインターネット プロトコルへのアクセスに依存しません。データはオーバーレイ ネットワーク全体に分散できます。オーバーレイ ネットワークは、別のネットワークの上に構築されたネットワークです。これらの機能は、検閲耐性ネットワークの中核要素であるため、注目に値します。これは、世界中で蔓延しているインターネット検閲に対抗し、言論の自由を促進するツールになり得ますが、悪意のある行為者による悪用の可能性があることにも注意する必要があります。

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

最初に紹介する IPFS の重要なコンポーネントは、自己認証ファイル システム (SFS) です。データを交換するために特別な権限を必要としない分散ファイルシステムです。クライアントに提供されるデータはファイル名によって認証されるため、「自己認証」となります。その結果、ローカル ストレージの透過性を維持しながらリモート コンテンツに安全にアクセスできるようになります。

この概念に基づいて、IPFS は InterPlanetary Name Space (IPNS) を作成しました。これは、公開鍵暗号化を使用して、ネットワーク ユーザーが公開したオブジェクトを自己認証する SFS です。先ほど、IPFS 上のすべてのオブジェクトは一意に識別できると述べましたが、これはノードにも適用されます。ネットワーク上の各ノードには、公開鍵、秘密鍵、ノード ID のセットがあり、ノード ID は公開鍵のハッシュ値です。したがって、ノードは、公開するデータ オブジェクトに秘密鍵を使用して「署名」し、送信者の公開鍵を使用してそのデータの信頼性を検証できます。

ここでは、主要な IPFS コンポーネントを簡単に説明します。

• 分散ハッシュテーブルを通じて、ノードは中央の調整なしにデータを保存し共有できる。
• IPNS を使用すると、公開鍵暗号化を使用して、交換されたデータを即座に事前認証および検証できます。
• Merkle DAGは、データの一意の識別、改ざん防止、安全な保存を可能にします。

ネットワーク内でファイルがどのように配布されるかについては、ConsenSys が書いたこの記事で詳しく知ることができます (詳しく読んでください)。さらに、IPFS のホワイト ペーパーもご覧ください。

注記：

• 機密コンテンツは常に暗号化してください。暗号化されたコンテンツでは、アップロードされたデータは「保護」されます。つまり、ルート ハッシュ (ファイルのルート ハッシュと暗号化キー) への参照を知っているユーザーだけがコンテンツにアクセスできます。
• IPFS は永続的なデータ構造であるため、IPFS には削除または除去操作の概念はありません。これは、コンテンツが、それを提供するインセンティブを持つノードに伝播されるためです。
• アップロードされたデータがネットワーク上で保持されるという保証はありません。参加しているすべてのノードは、正式な義務を負わずにボランティアとして参加していると見なされ、必要に応じてコンテンツを削除できます。したがって、インセンティブ システム (Filecoin) が適切に機能するまで、ユーザーはいかなる状況でも IPFS を安全なストレージとして考えるべきではありません。

著者について

Vaibhav Saini 氏は、MIT ケンブリッジ イノベーション センターで育成されたスタートアップ企業 TowardsBlockchain の共同創設者です。彼は、Ethereum、Quorum、EOS、Nano、Hashgraph、IOTA など、複数のブロックチェーン プラットフォームに取り組んでいる上級ブロックチェーン開発者です。現在、彼はインド工科大学デリー校の2年生です。

英語のオリジナル記事を読む: https://hackernoon.com/storagepedia-an-encyclopedia-of-5-blockchain-storage-platform-8aa13c630ace