IPNSを使いたいのでIPFSのdaemonのnamesys-pubsubオプションを有効にしてみた。

はじめに

IPFSにファイルを置くと、IPFSのGateway経由するURLを指定することによりアクセスができるようになります。

しかし、URLに含まれるIPFSのCIDはファイルであればファイルの中身、ディレクトリであればその配下にあるファイル及びその中身(以下、これらをまとめて「コンテンツ」と呼ぶことにします。)を元にしてハッシュ値を生成するため、コンテンツやディレクトリの構成が変わってしまうとCIDが変わってしまうため、それを含むURLも変わってしまいます。

そこで、コンテンツが変化することによってURLが変わってしまうことを防ぐために、コンテンツを公開鍵のハッシュ値と紐づけるための仕組みとして、IPNS(InterPlanetary Naming System)を利用することができます。

URLの一部として使用される公開鍵のハッシュ値自体は鍵ペアを変えない限り変わらないので、コンテンツの中身が変わったら都度紐づけ(=publish)を行って公開鍵のハッシュ値の紐づけ先を変更することにより、公開鍵のハッシュ値を含むURLが示すコンテンツの内容を変えることができるという寸法です。

さっそく使ってみることにしました。

ユースケース

ipfs files mkdirコマンドを使ってディレクトリを作り、そのディレクトリのアドレスをIPNSに対してpublishし、さらにその下にこのサイトで使っているバナー画像(vsse_banner_v2_1200x311.jpg)を置き、バナー画像のリンク先として記述するURLをIPFSへのゲートウェイ経由のものに変更するというユースケースを考えます。

IPNSへのpublish

1st try: ひたすら実行。

まずは、以下のコマンドを順番にひたすら実行します。

$ ipfs add vsse_banner_v2_1200x311.jpg

added QmSP17d12X8Hj1L8rVfsMhdNixireDtEWsJi1nLyeTRGQg vsse_banner_v2_1200x311.jpg

 142.97 KiB / 142.97 KiB [=============================================] 100.00%

$ ipfs files cp /ipfs/QmSP17d12X8Hj1L8rVfsMhdNixireDtEWsJi1nLyeTRGQg /vsse_banner_v2_1200x311.jpg

$ ipfs files mkdir /vsse

$ ipfs files mv /vsse_banner_v2_1200x311.jpg /vsse

$ ipfs files ls -l /

nightview_of_yokohama.jpg       QmdwpM8cd5M82sjT2yN2bVyxbiJLZK15QuL65ZfJLwLGzn 2056386

vsse/                           QmW53sbFADDpUeBTcd2me9TAYpVgLRyd7ejrBwCAL72vLv  0

$ ipfs name publish QmW53sbFADDpUeBTcd2me9TAYpVgLRyd7ejrBwCAL72vLv

Published to k51qzi5uqu5dgl9vqr7048dee9fnf1fhqq3zywm2rpq5ekh3kwegd22r2flijf: /ipfs/QmW53sbFADDpUeBTcd2me9TAYpVgLRyd7ejrBwCAL72vLv

ipfs filesコマンドを使ってvsseという名前のディレクトリを作り、それをpublishしています。なお、nightview_of_yokohama.jpgは気にしない方向でお願いいたします。🙇

最後のコマンドの実行結果の行に表示される「k51」から始まる文字列がpublishされたディレクトリに紐づけられたIPNSのアドレス(ハッシュ値)です。

ここまでの各コマンドの実行がそれぞれ一瞬で終了したので、以下のURLにブラウザでアクセスしてみたのですが…

https://ipfs.io/ipns/k51qzi5uqu5dgl9vqr7048dee9fnf1fhqq3zywm2rpq5ekh3kwegd22r2flijf/vsse_banner_v2_1200x311.jpg

ものの見事にタイムアウトしてしまいました。＿|￣|○

原因を究明してから2nd try

HTTPSでのアクセスができない原因を探るべくいろいろと調べていると、どうもipfs daemonのnamesys-pubsubオプション(=IPNSのレコード配布をpubsubで行うオプション)が有効になっておらず、かつpubsubのかわりに使われるDHTの処理が遅いのが原因のような気がしてきました。

そこで、前の記事で作ったipfs daemonの起動用のユニットファイルを以下のように変更してみました。

daemon機能時のオプションに --enable-namesys-pubsub を追加しています(8行目)。

ipfs daemonを再起動してから、再度publishしてみます。

$ ipfs name publish QmW53sbFADDpUeBTcd2me9TAYpVgLRyd7ejrBwCAL72vLv
(30-40秒後…)
Published to k51qzi5uqu5dgl9vqr7048dee9fnf1fhqq3zywm2rpq5ekh3kwegd22r2flijf: /ipfs/QmW53sbFADDpUeBTcd2me9TAYpVgLRyd7ejrBwCAL72vLv

1st tryでは一瞬で終わってしまいましたが、今回は30-40秒くらいかかっていて「作業をやってます感」を醸し出してきたので、期待できそうです。

再度、以下のURLのいずれかにアクセスしてみます。

バナー画像が表示されることが確認できます。

サーバのメモリが十分にipfsプロセスに対して十分にallocateできる(512MB程度)状態になっている場合には、読み込みに要する時間は1のURLが一番早く、2及び3のURLの方が時間を要するようです。

というわけで、このサイトのバナー画像及びTwitter CardのURLをIPFSゲートウェイ経由のものに変更してみました。

いい感じです。👍

まとめ & おまけ

--enable-namesys-pubsubオプションの他にも--routing=dhtclientオプションを追加してみたりしたのですが、IPNSが使えなくなってしまったため、--routing=dhtclientについては追加しないこととしました。

IPFS daemonによるPubSubを用いたIPNSのレコード配布機能が使えそうであれば、バナー画像等の静的なコンテンツでかつ容量が大きめのものをIPFSに切り出すことによって、サーバやネットワークにかかる負荷をある程度は分散させることができそうです。

なお、前節でURLを3通り示したのはレスポンスのスピードの比較が目的ですが、以下のように変遷しています。

この記事を最初に書いた時点(2021年12月)ではipfs.io(前節の1の方)をIPNSでのアクセス用のURLとして使っていました。
その後2022年1月に前節の3のURLを用いた表示が速そうであることがわかったので、切り替えました。
当初からipfs daemonのメモリのallocateに失敗することが原因でサーバ全体が止まってしまう現象が発生していたので原因を調べたところ、GROWIの設定に誤りがあったために本来allocateされるべきでないメモリが余分にallocateされていたようで、当該の設定を修正したところサーバが停止しなくなったため、1のURLに再度切り替えました(2022年2月)。

他のIPFSゲートウェイでレスポンスが速いことが確認できるものがあれば、そちらに切り替えるかもしれません。

この記事は以上です。