IPFSでのコンテンツ配信を10倍高速化！私たちが取り組んだ最適化手法を公開

IPFSを用いたコンテンツ公開プロセスを、どのようにして従来の10倍の速さまで引き上げたのか。その具体的な技術的アプローチと最適化のポイントについて解説します。

検索（lookup）を高速化することはできるのかな？以前使った時は、CIDを見つけるのに数分かかったから、あんまり使わなくなったんだよね。

「PUT RPCのほとんど（全部じゃない）が成功した時点でユーザーに制御を戻し、残りはバックグラウンドで処理を続ける」

処理を減らして（同じことをせずに）高速化するっていうのは、コンピューティングの世界じゃ昔からの鉄板だよね！でも、実際には同じ作業をしてるわけじゃなくて、単に完了待ちをやめて非同期にしただけなのに、プロバイディング（公開）が高速化したって呼ぶのはちょっとミスリーディングな気がしちゃう。

これだと、ユーザー側は「全部ちゃんと公開された」と思ってるのに、他の人がアクセスしようとするとまだレコードが公開されてない、っていう問題が起きない？俺の理解が正しければ、CID全体が他の人から利用可能になるまでの時間は結局ほとんど変わらないはずで、「速くなった」のは公開する側のエンドユーザーUXだけなんじゃないかな？

デフォルト設定のままだと、今でもDHTに内部・外部IPの割り当て全部漏らしてるの？

最後にチェックした時は、セキュリティの姿勢がマジで最悪だったんだけど。

あと当然のように、クソみたいなコイン（shitcoin）もくっついてるよね。FileCoinに加担するなんて絶対ごめんだよ。最近は何でもかんでも、投機家とかを釣るために金銭的な要素を無理やりぶち込んでくるよね。

「まだ〜なの？」っていう質問に一つ付け加えさせて。

最後に聞いた話だと、IPFSからはデータを削除する方法がないってことだったんだけど。少なくとも強制力のある手段はないよね。ネット上の公開データは削除が「不可能」だってことは置いておいても、サーバーをシャットダウンできるっていうのは一つの魅力だと思うんだ。IPFSでホストされたコンテンツだと、それが難しい気がして。

コンテンツの削除に関して、何か詳しい人いる？

今でもIPFSを本番環境で使ってる人っているのかな？（あるいは使ってたことある？）

Wikipedia-on-IPFSみたいな技術デモの話じゃなくてさ（あれは確かに動作してたし感動したけど）、IPFSに何らかの機能をガッツリ依存させてるようなケースの話ね。

2年前にlibp2pのDHT（rust-libp2pのDouble Hashing）を少し触ってた身としては、改善が進んでるのは本当に嬉しい。
ただ、高密度ネットワークでCDNレベルの速度を目指すなら、ネットワークトポロジーをDHT内のPeerID/アイデンティティにエンコードしないのは、やっぱりアーキテクチャ上の欠陥だと思う。まずは5つのRIRを使うところから始めるとか。もっと高度なやり方だと、以前いろいろ考えたんだけど、Geo DNSの分散型エニーキャストIPアドレスを使って新しいピアを近隣にブートストラップし、それをDHTアイデンティティに紐付ける手がある。でも、インターネットのガバナンス構造の中に、BGPを分散システムの手で組み込めるものなのかな？

ちなみに、俺たちがHyveOSのプロジェクトでやってた時は、Batman-advのルーティングテーブルを使って、爆速で新しいピアをシステムにブートストラップさせてたよ。

あー……たまに、こういう開発してた頃が懐かしくなるよ。

記事の本筋とはちょっと逸れるけど（面白い記事だと思うよ）、IPFSの最大の問題はクライアントのパフォーマンスの酷さだったと思う。リフレッシュストームとか、スパースなルーティングテーブル、到達不能なピア、それにルックアップ速度の遅さとかが原因だった記憶がある。結局評判が悪すぎてみんな寄り付かなくなったし、俺も自分のプロジェクトではボツにした。ユーザーがクリプト詐欺系のプロジェクトばっかりだったら、もうおしまいだよね。