分散型ファイルシステム「IPFS」は本当に分散型なのか

IPFSといえば、分散型ファイルシステムとしてスマートコントラクトと相性が良いと言われており、多くのDAppsで画像やデータの格納場所として利用されています。
DApps内で使用する画像をIPFS上で管理したり、ERC721と合わせで画像自体をNon-Fungible Tokenとしたりと用途は様々です。

しかしこのIPFS、BitcoinやEthereumといったBlockchainとは異なり、各Nodeで全てのデータを格納しているのではなく、それぞれで一部のキャッシュを保持しているにすぎません。
また、Nodeを運営すること自体にインセンティブもないため、自前でNodeを持たずにIPFS Gatewayを使用しているサービスも多く見かけます。
このような状態でIPFSのネットワークは、どのように分散化されているのでしょうか。

この疑問を解決するため、IPFSにおいてどのように分散的にファイルが管理されているのか調べてみることにしました。

調べた内容に関しては、Blockchain.tokyo #11のLTで発表しました。
その時の資料はこちら。

speakerdeck.com

まず、IPFSでファイルをアップロードした場合、下記のようにIPFSネットワーク上に自動で分散的に管理されるイメージを持っている人は多いと思います。

1.ファイルをアップロードする

2.ファイルが分散的に管理される

しかし、実際に自分でNodeをたててみると分かるのですが、自分で立てたNodeにファイルをアップロードするだけではファイルはその他のNodeに伝播ししません。
他のNodeからアップロードされたファイルにアクセスがあった時に初めて、そのNodeにキャッシュが作成されます。

具体的には下記のような動きになります。

1.ファイルをアップロードする

2.アップロードしたファイルがピンどめされる

3.その他のNode(例えばIPFS Gateway)からアップロードしたコンテンツにアクセスする

4.アクセスしたNodeにキャッシュが作られる

このように、様々なNodeからアクセスがあることで、ファイルが分散的に管理されていきます。
しかし、IPFS Gatewayのようなアクセスの多いNodeだと頻繁にキャッシュが削除されるため、一定期間アクセスがないと、また最初の状態に戻ってしまいます。

5.キャッシュが削除される

これらの挙動から、IPFSは以下の特徴があるといえます。

IPFSの特徴

  1. ピン止めされたコンテンツしか永続的に保存されない
    • アップロードしたNodeではデフォルトでピン留される
    • ピン止めされていないコンテンツはキャッシュとして対象のNodeに残り続けるが、garbage collectionが走ると消える可能性がある。(IPFS Gatewayはアクセスが多いため、頻繁にキャッシュが消えていると思われる。)
  2. アップロードしたNodeでしかピン留めされない
    • その他のNodeのコンテンツをピン止めするメリットは基本的にないため、アップロードした Nodeでしたピンどめされないと思われる。
  3. そもそもキャッシュが作られない
    • ほとんどのケースでアップロードしたNodeからしかコンテンツにアクセスしないため、他のNodeでキャッシュが作られない

つまり、単純に画像やデータの格納場所としてIPFSを利用しているDAppsでは、ファイルは全く分散化されていないということになります。
IPFSで静的なwebサイトをホスティングしているケースなどその最たるものです。

ではこれらの特徴を踏まえ、どのようにIPFSを使用すれば分散的にファイルを管理できるのでしょうか。

1.Nodeをたてて同一ファイルにアクセスするメリットがあるケース

自分でNodeをたて、そこにキャッシュが存在していることでユーザー体験が大きく向上するものであれば、多くのNodeから同一ファイルにアクセスすることになるので、アップロードされたファイルは十分に分散化していきます。
例えば、P2Pの音楽ファイル共有サービスのようなものが当てはまるでしょう。
音楽を聴くたびにネットワークに問い合わせていては時間がかるので、より便利に使いたいユーザーは自前のNodeにキャッシュを保持することになると思われます。
消えて欲しくないキャッシュに対しては、ピン留めするユーザーもいるかもしれません。

2.ピン留めに何かしらのインセンティブがあるケース

現在ピンどめにインセンティブは存在していません。
ファイルを保持することに暗号通貨でインセンティブを与えたものがFilecoinやStorjです。
IPFSでは暗号通貨のような直接的なインセンティブが今後実装されることはないと思いますが、何かしらのインセンティブ設計がされればより分散的なっていくでしょう。

3.コントラクトを利用するサービスの提供者が複数発生するケース

1つのコントラクトを利用するサービスの提供者が複数現れ、それぞれが自前のNodeを持つような設計になっていれば、サービス単体では分散化していなくても、複数のサービスから同じコントラクト、同じファイルを参照することになるので、IPFS上のファイルは分散化していくと考えられます。
ちなみに、複数のIPFSノードでコンテンツを同期するIPFS CLUSTERというツールもあるので、Cluster構成のIPFSというのも構築できるようです。

IPFS CLUSTER

おわりに

IPFSは、InterPlanetary File System(惑星間ファイルシステム)という壮大な名前がつけられているだけあって目指しているものはとても興味深いのですが、現状はまだまだ発展途上な技術なだけあって、使いどころは難しいと思います。

単純にIPFSネットワーク上にファイルをアップロードするだけなら簡単ですが、ファイルが分散的に管理されるようにするには、工夫したサービス設計が必要でしょう。
DAppsを開発する上で分散型であることには強い魅力があり、スマートコントラクトの弱点を補完する技術でもあるので、IPFSを使ったサービスは今後さらに増えていくと思います。
さらなるIPFSの発展に期待です。

The following two tabs change content below.
Akihiro Tanaka

Akihiro Tanaka

Engineer/UI Designer
UI設計を得意とするエンジニア。 現在はDApps開発しています。
好きな言語はTypeScript、好きなフレームワークはIonic、Angular。 趣味はハーレー、キャンプ、アンティーク。
WEB: http://tanakas.org/