分散ファイルシステムIPFSおよびFileCoin
この記事では、最近人気のあるピアツーピア分散ファイルシステムであるIPFS(InterPlanetary File System)についてお話したいと思います。HTTPプロトコルの登場から半世紀以上が経過しており、できる設計はほとんどありません。 HTTPネットワーク全体を強化するか、新しい機能を追加します。
HTTPプロトコルを使用して比較的小さなファイルを転送することは、実際には非常に安価で便利ですが、コンピューティングリソースとストレージスペースの急激な増加に伴い、いつでも大量のデータを取得する必要があるという問題に直面しています。IPFSはこの問題を解決することです。
建築デザイン
分散ファイルシステムとして、IPFSは、大きなファイルの展開と書き込み、および配布とバージョン管理をサポートするプラットフォームを提供します。上記の目的を達成するために、IPFSプロトコルは次のサブプロトコルに分割されます。
上記の7つのサブプロトコルは、IPFSのさまざまな機能を担当します。次の章では、各プロトコルの機能とIPFSの実装方法を紹介します。
身元
IPFSネットワークでは、すべてのノードは、ビットコインアドレスにいくらか似ている一意のNodeIdによって識別されます。これは、実際には公開キーのハッシュです。ただし、攻撃者のコストを増やすために、IPFSは前述のようにS / Kademliaを使用します。このアルゴリズムは、新しいIDを作成するコストを増加させます。
difficulty = <integer parameter>
n = Node{
}
do {
n.PubKey, n.PrivKey = PKI.genKeyPair()
n.NodeId = hash(n.PubKey)
p = count_preceding_zero_bits(hash(n.NodeId))
} while (p < difficulty)
各ノードは、IPFSコードのノード構造で表されます。この構造には、NodeIdと、公開キーと秘密キーのペアのみが含まれています。
type NodeId Multihash
type Multihash []byte
type PublicKey []byte
type PrivateKey []byte
type Node struct {
NodeId NodeId
PubKey PublicKey
PriKey PrivateKey
}
つまり、IDシステムの主な役割は、IPFSネットワーク内の各ノードを表し、IPFSを使用して各「ユーザー」を表すことです。
インターネット
分散ストレージシステムとして、ノード間の通信と情報転送は、さまざまなトランスポートレイヤープロトコルを使用でき、信頼性、接続性、情報の整合性、および信頼性を確保しながら、ネットワークを介して実行する必要があります。
IPFSは、任意のネットワークを使用して通信できます。IPプロトコルで実行する必要があるとは想定していませんが、multiaddrの形式を使用して、ターゲットアドレスと使用するプロトコルを示し、互換性を保ち、将来登場する可能性のある他のネットワークプロトコルを拡張します。
/ip4/10.20.30/40/sctp/1234/
/ip4/5.6.7.8/tcp/5678/ip4/1.2.3.4/sctp/1234/
ルーティング
分散システムでは、他のノードに格納されているリソースを取得またはアクセスするためにルーティングシステムが必要です。IPFSはS / KademliaとCoralに基づくDSHTを使用してルーティングシステムを実装します。libp2p/ go-libp2p-routingを使用できます。 /routing.goでIPFSルーティングシステムインターフェイスを見つけます。
type IpfsRouting interface {
ContentRouting
PeerRouting
ValueStore
Bootstrap(context.Context) error
}
type ContentRouting interface {
Provide(context.Context, *cid.Cid, bool) error
FindProvidersAsync(context.Context, *cid.Cid, int) <-chan pstore.PeerInfo
}
type PeerRouting interface {
FindPeer(context.Context, peer.ID) (pstore.PeerInfo, error)
}
type ValueStore interface {
PutValue(context.Context, string, []byte) error
GetValue(context.Context, string) ([]byte, error)
GetValues(c context.Context, k string, count int) ([]RecvdVal, error)
}
ここから、IPFSでのルーティングには、コンテンツルーティング、ノードルーティング、およびデータストレージの3つの基本機能を実装する必要があることがわかります。これらのインターフェースを実装する「ルーター」は、システムの他の部分の作業に影響を与えることなく、最下層で置き換えることができます。現在、IPFSはグローバルDHTとDNSを使用してルーティングレコードを解決しますが、KademliaDHTには次の利点があります。
- バッチノードでターゲットアドレスをすばやく見つけます。時間の複雑さはlog2(n)log_2(n)です。l o g2(n )、つまり、10,000,000ノードで必要なクエリは20個だけです。
- ノード間の制御メッセージの長さを最適化し、情報調整のコストを削減します。
- 長期ノードを優先的に選択することにより、複数のネットワーク攻撃に抵抗します。
- BitTorrentやGnutellaなどのポイントツーポイントアプリケーションで広く使用されており、テクノロジーは比較的成熟しています。
データ交換
IPFSでは、データの配布と交換はBitSwapプロトコルを使用します。BitSwapは、他のノードから必要なブロックを要求することと、他のノードにブロックを提供することの2つの役割を果たします。
他のノードからBlockを要求したり、他のノードにBlockを提供したりする必要がある場合は、主に送信者のウォントリストとデータブロックの2つの部分を含むBitSwapメッセージを送信します。メッセージ全体はProtobufを使用してエンコードされます。
message Message {
message Wantlist {
message Entry {
optional string block = 1; // the block key
optional int32 priority = 2; // the priority (normalized). default to 1
optional bool cancel = 3; // whether this revokes an entry
}
repeated Entry entries = 1; // a list of wantlist entries
optional bool full = 2; // whether this is the full wantlist. default to false
}
optional Wantlist wantlist = 1;
repeated bytes blocks = 2;
}
BitSwapシステムには、2つの非常に重要なモジュール要件マネージャー(Want-Manager)と決定エンジン(Decision-Engine)があります。前者は、ノードがブロックを要求するか適切な要求を発行すると、対応するブロックをローカルに返します。後者は、他のノードにリソースを割り当てる方法を決定します。ノードがWantlistを含むメッセージを受信すると、メッセージは決定エンジンに転送され、エンジンはノードの元帳に基づいて要求を処理する方法を決定します。
BitSwapとSpecの実装の詳細について詳しく知りたい読者は、BitSwapSpecの他のコンテンツを読むことができます。
IPFSは、ノード間で送信されるメッセージを定義することに加えて、ネットワーク全体に「悪意のある」ノードがないことを保証するためのインセンティブとペナルティも導入します。元帳は、2つのノード間のデータ交換を格納するために使用されます。
type Ledger struct {
owner NodeId
partner NodeId
bytes_sent int
bytes_recv int
timestamp Timestamp
}
意思決定エンジンは、2つのノード間の元帳を介して債務比率を計算します。
デットレシオは、ノード間の信頼度を測定するために使用され、攻撃者が多数のノードを作成するのを防ぐだけでなく、ノードが短時間使用できない場合に既存のトランザクション関係を保護し、ノード関係が悪化する前にトランザクションを終了します。
IPFSは、元帳を使用してインセンティブとペナルティのあるネットワークを作成し、ネットワーク内のほとんどのノードがデータを交換して正常に動作できるようにします。
ファイルシステム
DHTとBitSwapを使用すると、IPFSは、データブロックを格納および配布するための大規模なピアツーピアシステムを構築できます。さらに、IPFSはMerkle DAGを構築し、各IPFSオブジェクトには現在のノードにリンクとデータのセットが含まれる場合があります。
type IPFSLink struct {
Name string
Hash Multihash
Size int
}
type IPFSObject struct {
links []IPFSLink
data []byte
}
次のコマンドを使用して、オブジェクトの下にあるすべてのリンクを一覧表示できます。
$ ipfs ls QmYwAPJzv5CZsnA625s3Xf2nemtYgPpHdWEz79ojWnPbdG
QmZTR5bcpQD7cFgTorqxZDYaew1Wqgfbd2ud9QqGPAkK2V 1688 about
QmYCvbfNbCwFR45HiNP45rwJgvatpiW38D961L5qAhUM5Y 200 contact
QmY5heUM5qgRubMDD1og9fhCPA6QdkMp3QCwd4s7gJsyE7 322 help
QmdncfsVm2h5Kqq9hPmU7oAVX2zTSVP3L869tgTbPYnsha 1728 quick-start
QmPZ9gcCEpqKTo6aq61g2nXGUhM4iCL3ewB6LDXZCtioEB 1102 readme
QmTumTjvcYCAvRRwQ8sDRxh8ezmrcr88YFU7iYNroGGTBZ 1027 security-notes
元のデータとユニバーサルリンクは、IPFSでデータ構造を構築するための基礎です。キー値ストレージ、従来のリレーショナルデータベース、および暗号化されたブロックチェーンはすべて、IPFSのMerkleDAGに保存および配布できます。
これに加えて、IPFSは、バージョン制御をサポートするファイルシステムを構築するための一連のオブジェクトを定義します。これは、Gitのオブジェクトモデルと非常によく似ており、すべてのファイルオブジェクトは実際にはProtobufを介してバイナリエンコードされます。
IPFSファイルは、リストとblobで表すことができます。
- ブロブにはリンクは含まれず、データのみが含まれます。
- ただし、リストには、blobとリストの順序付きキューが含まれています
- ツリーファイルオブジェクトはGitのツリーと非常によく似ており、名前からハッシュまでのファイルディレクトリを表します。
- 最後のコミットは、任意のオブジェクトのスナップショットを表します。
上記のファイルオブジェクトグラフでは、トップレベルのコミットは特定の履歴スナップショットを表しています。2つのコミットと子ノードで構成されるツリーを比較すると、2つのスナップショットの違いがわかります。MerkleDAGとファイルオブジェクトが構成していると考えることができます。 IPFSのファイルシステム全体。
ネーミングシステム
これまで、IPFSテクノロジースタックは、ノード間でDAGオブジェクトを送信し、不変のオブジェクトをプッシュおよび取得できるポイントツーポイントのデータ交換システムを提供してきましたが、変数の命名システムもネットワークの不可欠な部分です。結局のところ、Webサイトの更新によってドメイン名を変更できないため、異なるステータスを取得するには同じアドレスを使用する必要があります。したがって、IPFSはこの問題を解決するために「ドメインネームサービス」を提供する必要があります。
これらの問題を解決するために、IPFSで次の変数名前名を使用できます。ユーザーはオブジェクトを公開でき、他のノードはipnsとユーザーのノードアドレスを介してネットワークに公開されたこれらのオブジェクトにアクセスできます。
/ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm/
もちろん、TXTレコードを既存のDNSシステムに追加して、ドメイン名を介してIPFSネットワークで公開されているファイルオブジェクトにアクセスできるようにすることもできます。
ipfs.benet.ai. TXT "ipfs=XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm"
/ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm
/ipns/ipfs.benet.ai
IPFSでは、ハッシュを使用して可変オブジェクトにアクセスできるだけでなく、既存のDNSサービスに組み込んで適切に実行し、基盤となるサービスのシームレスな切り替えの問題を解決することもできます。
励起
今日、IPFSの基盤となるブロックチェーンテクノロジーについて説明するとき、IPFS上に構築されたFileCoinについて言及する必要があります。これは、ホストとアップローダーが取引する市場を提供し、ストレージのコストを調整してアップロードすることができます。ユーザーは、価格に基づいて速度、冗長性、およびコストを選択できます。
ノード
ほとんどのブロックチェーンネットワークには単一タイプの標準ノードしかありませんが、FileCoinにはストレージノードと取得ノードの2つの異なるノードがあります。
誰もがストレージノードになり、自分のディスクに追加のストレージスペースを貸し出すことができます。FileCoinはこれらのディスクを使用して、暗号化された小さなファイルの一部を保存します。一方、取得ノードは、より多くのストレージノードにできるだけ近い必要があり、さらに必要です。より高い帯域幅とより低い待ち時間により、ユーザーはファイルを最も速く返す検索ノードの料金を支払うことになります。
ファイルをアップロードするときは、一定のストレージ料金を支払う必要があります。ストレージノードはファイルを保存する権利の見積もりを出します。FileCoinはファイルを保存するための最低価格のストレージノードを選択します。保存されたファイルは暗号化され、複数の部分に分割されます。また、複数のノードに送信されると、ファイルの場所がグローバルテーブルに保存されます。その後、秘密鍵を持つノードのみが、アップロードされたファイルのクエリ、アセンブル、および復号化を行うことができます。
コンセンサスアルゴリズム
すべてのブロックチェーンアプリケーションには、複数のノードが特定の結果についてコンセンサスに到達し、競合を解決するためのコンセンサスアルゴリズムが必要であると言えます。現在、BitcoinとEthereumはコンセンサスアルゴリズムとしてProof-of-Workを使用していますが、FileCoinはProof-of-Replication(PoRep)を使用して、ネットワークの内部問題を解決します。
Proof-of-Replication(PoRep)スキームを導入します。これにより、証明者Pは(a)Dのn個の異なるレプリカ(物理的に独立したコピー)を格納することを確約し、(b)検証者VにPが実際にそれぞれを格納していることを納得させることができます。レプリカの。
PoRepは、証明者Pが提出し、ストアn個の異なるDのコピーを、そしてPはこれらのコピー保存しなかったことを検証Vを説得することができます。
Proof of Replicationの記事では、ディスクスペースプロバイダーが実際にリソースを格納していることを確認するために使用されるPoRepやPoS(Proof-of-Storage)などのコンセンサスアルゴリズムを見つけることができます。ここではそれらを紹介しません。
総括する
IPFSは、ブロックチェーンの非常に興味深い基盤技術であり、既存のインターネットプロトコルとの互換性に基づいてポイントツーポイントのファイルストレージシステムを実装し、ビッグデータストレージのソリューションを提案します。著者は公式のIPFSクライアントを試しました。 ipfsは確かに使いやすいですが、プロジェクトの初期段階でもあります。多くのモジュールと機能はまだ完成しておらず、IPFSに基づくFileCoinには、リリースされる正確なログの複製証明がありません。このホワイトペーパーはWIP(Work)としてもマークされています。処理中)では、一部の部品が完成していないため、この技術の成熟を待つのに長い時間がかかります。