如何用 IPFS 架設去中心化網站?

本篇分享如何使用 IPFS 架設網站,分別提供使用第三方服務 Pinata 託管的方法,或是折騰自己架設 IPFS 節點。最後使用 CloudFlare 綁定網域,脫離落落長的 IPFS 網址。以及探討一下,使用 IPFS 架站的網站速度是否滿意。

Easy Way:使用 Pinata 服務託管

首先前往 Pinata 申請一個免費帳號,進入 PinManager,會發現功能非常簡單,只是一個上傳與管理檔案的頁面

如何用 IPFS 架設去中心化網站?

點選 Upload,可以選擇要上傳的檔案或資料夾

如何用 IPFS 架設去中心化網站?

延伸閱讀:用前端框架開發 IPFS Web3 DApp 有哪些坑?

回到 PinManager,可以直接點名稱查看網站。或將 CID 接在 Publice IPFS Gateway 後面查看,如

https://cloudflare-ipfs.com/ipfs
/QmV3NBfZLSFq8oQgiEKBraiEWEyrpPcDeifWUEahUuzRfc

https://ipfs.io/ipfs
/QmV3NBfZLSFq8oQgiEKBraiEWEyrpPcDeifWUEahUuzRfc/

Hard Way:自行架設 IPFS 節點

雖然標題寫 Hard Way,但 IPFS 對不同系統平台都有推出簡易的安裝方式。其中 IPFS Desktop 應該是最簡易的方法了,下載安裝檔安裝後開箱即用。

但一般筆電可能不會長時間開機,為了讓 IPFS 節點能夠一直在網路上,我們可以使用 Raspberry Pi 等單板電腦來架設,使用以下 docker-compose 檔案快速建立:

version: "2.3"
services:
  ipfs:
    image: linuxserver/ipfs:2.14.0
    container_name: ipfs
    environment:
      - PUID=1000
      - PGID=1000
    volumes:
      - ./data:/config
    ports:
      - 80:80
      - 4001:4001
      - 5001:5001
      - 8080:8080
    restart: always
    networks:
      ipfs-network:

networks:
   ipfs-network:
     driver: bridge

其中

  1. 80 port :
    IPFS Web Dashboard 頁面入口
  2. 4001 port:
    IPFS 節點溝通使用,如果 IPFS 架在 router 後面,據官方文件表示搜尋網路上檔案速度會較慢,可以考慮做 port forwarding。但單純 hosting 實測起來沒有明顯差異,port forwarding 我認為可選。
  3. 5001 port:
    IPFS Web Dashboard API 入口
  4. 8080 port:
    IPFS Gateway 入口

然後 docker-compose up -d 即可

如果是桌面版直接開啟 IPFS app 就能進入 Web Dashboard,若架設在 Raspbery pi 則在瀏覽器輸入 http://<YOUR_RASP_PI_IP>:8080,會看到如下頁面:

如何用 IPFS 架設去中心化網站?

因為 Web Dashboard 預設會去抓 local 的 5001 port 打 api,我們在最下面修改 api 的位置到 <YOUR_RASP_PI_IP>:5001 即可修正

如何用 IPFS 架設去中心化網站?

切換到「檔案」頁面,點選匯入即可上傳檔案,操作方式與 Pinata 非常相似

如何用 IPFS 架設去中心化網站?

上傳完即能取得 CID。如果同一份檔案上傳到 Pinata CID 一定會一樣,所以可以安心多處上傳增加 host

如何用 IPFS 架設去中心化網站?

如何透過 IPNS 替代 CID?

因為 CID 是由檔案內容計算 Hash 所得,只要網頁有所變動,都會產生不同的 CID,這行為造成網頁進版時網址一定會發生變化!有辦法用一個變數取代 CID 嗎? 我們可以使用 IPNS!

IPNS 全名 InterPlanetary Name System。操作原理如下:
每一個節點初始化後都會預設一把 key,IPNS 可以用這把 key 的 public key hash 作為 domain name,將其指向一特定的 CID,就好像傳統 DNS 服務,將網域指向某一個 IP !

實際操作方式,進入 IPFS container 鍵入以下指令

$ ipfs name publish /ipfs/<CID>

比如說:

$ ipfs name publish /ipfs/QmV3NBfZLSFq8oQgiEKBraiEWEyrpPcDeifWUEahUuzRfc

Published to k51qzi5uqu5dlw5jnmyj9sviak0nlpvho02o53zwudqaesjr9tsqfi75idt0nk: /ipfs/QmV3NBfZLSFq8oQgiEKBraiEWEyrpPcDeifWUEahUuzRfc

此時就可以透過 IPNS 查看網頁

https://cloudflare-ipfs.io/ipns/<public_key_hash>

比如:

https://ipfs.koding.work/ipns
/k51qzi5uqu5dlw5jnmyj9sviak0nlpvho02o53zwudqaesjr9tsqfi75idt0nk

下次進版得到新的 CID,再跑一次指令即可切換指向。

實測 name publish 指令發現需要跑超級久,目前是已知的問題,而且有時候透過 public IPFS Gateway 可能還會發生找不到的錯誤,這也是 decentralize 的缺點之一,後面我們再一起探討。

如何透過 IPNS + DNSLink 簡化網址?

是否有別的方法將落落長的 CID 做簡化與指向,同時避免上一個方法的問題呢?此時就要引入一點中心化的解決方案,使用傳統 DNS 的 DNSLink 來解決。

DNSLink 的原理是在 DNS 中增加一條 TXT record 指向對應 CID 路徑,其中參數為:

  1. 名稱:_dnslink.<YOUR_DOMAIN_NAME>
  2. 內容:dnslink=/ipfs/<CID>

比如說我想用 nft-viewer-ipfs.koding.work 作 DNSLink,設定如下:

如何用 IPFS 架設去中心化網站?

使用 public IPFS Gateway 測試看看:

https://cloudflare-ipfs.com/ipns/nft-viewer-ipfs.koding.work

即可看到一樣的網站!

如何透過 CloudFlare 綁定網域?

但這樣網址還是太長,有沒有辦法直接使用網域即可?如 https://nft-viewer-ipfs.koding.work ,答案是可以!還是得透過中心化服務 CloudFlare 來達成。

到 DNS 設定頁面,新增一條 CNAME Record 如下:

  1. 名稱:<YOUR_DOMAIN_NAME>
  2. 目標:cloudflare-ipfs.com

以我的例子如下:

如何用 IPFS 架設去中心化網站?

同時也新增一條 TXT Record for DNSLink 如下

  1. 名稱:_dnslink.<YOUR_DOMAIN_NAME>
  2. 內容:dnslink=/ipfs/<CID>
如何用 IPFS 架設去中心化網站?

這樣就能直接透過簡單的網址連結

https://nft-viewer-ipfs.koding.work

原理是 DNS 透過 CNAME 將 request 路由到 Cloudflare 的 public IPFS Gateway,Gateway 再去抓 DNSLink TXT 的值,即可回傳對應 CID 的檔案。

IPFS hosting 網站速度快嗎?

IPFS 其實是一種 P2P Network 的實現,和 BT 其實差不多。因此也會和 BT 一樣有種子數太少時速度很慢的缺點。

在 IPFS 的世界裡,只要 Pin 該檔案的節點數少,或是擁有該檔案快取的節點數少,回傳的速度都非、常、慢!有時候還會 Timeout error!在實際用戶體驗上非常糟糕,解決方法可能會是:

  1. 自己多架幾個 IPFS 節點 pin 相同的檔案
  2. 多找幾個 IPFS 第三方服務 pin 相同的檔案

或是引入一點中心化的方法,透過 public IPFS Gateway 作為入口,如 Cloudflare,只要流量夠,在 Cloudflare 的 Cache 就不容易被清除,網站速度就變快了。

甚至也可以自架 IPFS 節點,或是付錢使用 Pinata 的專有 IPFS Gateway,將 request 直接導向「必定有檔案」的節點上,這樣回應速度也會很快。不過這和 IPFS 去中心化的概念又有點相左。

因此可以發現,若要完全堅持去中心化,可能就會犧牲效能(網路速度),若要追求速度,就必須引入中心化,這也是目前 Web3 發展過程中不可避免的 trade-off。同時使用者可能未必在意你的網站是否去中心化,而是在意開啟網頁的速度要快,甚至還不願意自己跑節點。這部分蠻值得研究著墨,或許發展幾年後有機會改善這個問題,讓我們觀察下去!

延伸閱讀:
用前端框架開發 IPFS Web3 DApp 有哪些坑?
實測!用 Unstoppable Domains 鑄造區塊鏈域名並架站
自己寫 NFT 吧!- 實現 ERC-721 – 以 Python Brownie 開發

J
Written by J
雖然大學唸的是生物,但持著興趣與熱情自學,畢業後轉戰硬體工程師,與宅宅工程師們一起過著沒日沒夜的生活,做著台灣最薄的 intel 筆電,要與 macbook air 比拼。離開後,憑著一股傻勁與朋友創業,再度轉戰軟體工程師,一手扛起前後端、雙平台 app 開發,過程中雖跌跌撞撞,卻也累計不少經驗。可惜不是那 1% 的成功人士,於是加入其他成功人士的新創公司,專職開發後端。沒想到卻在採前人坑的過程中,拓寬了眼界,得到了深層的領悟。