IPFS Shipyard 宣布停止營運：Protocol Labs 中止資助，IPFS 核心生態進入轉型期

編按：本文綜合整理自 IPFS Shipyard 官方公告、Hacker News 討論串，並加入 Siami 編輯部觀點與分析。

2026 年 8 月 24 日，IPFS Shipyard 聯合創辦人 Cameron Wood 與 Adin Schmahmann 共同發表了一篇震動點對點網路社群的公告——Protocol Labs 已通知他們，將不再續約 Shipyard 的資金支持。這意味著負責維護 IPFS 核心實作與公共基礎設施的關鍵團隊，將在 9 月底前全面停止營運。

一則難以啟齒的公告

Cameron Wood 在開頭直言：「我們有一些艱難的消息要向 IPFS 及更廣大的點對點社群分享。」Shipyard 在過去三年負責打造現代 IPFS 生態系，協助使用者擁有更具韌性、更自主的技術。然而隨著 Protocol Labs 中止資助，Shipyard 將逐步停止所有 IPFS 相關的工程維護與基礎設施營運。

這不是一個臨時決策——Protocol Labs 同時也是 ipfs.io、dweb.link、check.ipfs.network、delegated-ipfs.dev 等網域名稱與基礎設施的所有者，這些服務的未來走向，將由 Protocol Labs 自行決定。

「雖然這個章節正在落幕，但我們仍然為共同完成的一切感到驕傲，並希望這些工作能為未來的發展打下堅實基礎。」—— Cameron Wood, Adin Schmahmann

過去三年的關鍵成就

在宣布結束之前，Shipyard 列出過去三年交付的重要里程碑。這些不只是程式碼數字的累積，而是 IPFS 從「加密貨幣附屬技術」走向「真正可用基礎設施」的轉捩點：

• inbrowser.link：讓使用者可以直接在瀏覽器內取得可驗證的網站與檔案下載，無需額外安裝客戶端
• Gateway 基礎設施重構：在維持穩定性的前提下，將可承載流量提升約 3 倍，同時營運與維護成本降低約 80%
• HTTP-native IPFS 推動：相較於傳統 libp2p-based 託管，大幅簡化部署、開發與營運成本
• 核心實作維護：Kubo、Helia、Boxo、Rainbow、IPFS Desktop、IPFS Companion 等生態系每日仰賴的專案持續改進

實質影響：這些專案都將失去專職維護者

公告最實質的衝擊，是 Shipyard 過去負責的所有專案不再有專人負責新功能、錯誤修正、版本發布或長期維護。具體受影響的專案包括：

1. Kubo（Go 語言 IPFS daemon，GitHub 17,108 stars）
2. Helia（JavaScript IPFS 實作）
3. Boxo（下一代 IPFS 工具箱）
4. Rainbow（進階 IPFS 網路服務）
5. IPFS Desktop（桌面 GUI 客戶端）
6. IPFS Companion（瀏覽器擴充套件）
7. Someguy、Service Worker Gateway、IPFS Check 等

除此之外，Shipyard 對 go-libp2p 與 js-libp2p 這兩個上游函式庫的貢獻也將停止。對 IPFS 規格、標準及生態系協調的工作同樣畫下句點。

基礎設施層面，ipfs.io、dweb.link、check.ipfs.network、delegated-ipfs.dev、IPFS bootstrap nodes，以及 Wikipedia-on-IPFS 等協作叢集都將停止營運。對依賴這些公共入口的開發者與終端使用者而言，是實質可見的轉變。

為什麼這件事重要

從表面上看，這只是「一個團隊的 funding 中止」。但放在 IPFS 十年的發展脈絡下，Shipyard 的退場反映出點對點網路協議在商業現實面前的結構性困境。

IPFS 自 2015 年由 Protocol Labs 提出以來，一直是「Web3」敘事的核心技術之一。它的內容定址（content addressing）機制承諾解決中心化儲存的多項問題：抗審查、可驗證、地址不隨伺服器位置改變。然而十年過去，IPFS 在主流網際網路的使用場景依然有限——大多數實際部署仍依賴 HTTP gateway 將 IPFS 內容「翻譯」回傳統 URL，本質上仍由少數公共 gateway 節點集中服務。

這正是 Hacker News 上 toomuchtodo 留言指出的核心矛盾：

「我看這跟 IPv4 跟 IPv6 的採用很像。對大多數使用情境來說，非內容定址的 URL 就夠用了；而 bittorrent 在持久、內容定址式檔案分送上其實就很好用了。我們真的需要 IPFS 嗎？」

更深層的問題是激勵機制。IPFS 從未真正解決「為什麼節點運營者要免費為他人提供儲存與頻寬」這個根本問題。Filecoin 曾被視為解方，但 Storacha 等品牌在 2026 年併入 FilOz（Filecoin 旗下），顯示 Protocol Labs 已將重心從「IPFS 開源社群」轉向「Filecoin 商業服務」。

對開發者而言，短期內不會感受到劇烈變化——Kubo、Helia 等程式碼仍在 GitHub 上，pushed_at 顯示 8 月仍有更新。但缺乏專職維護者意味著：

• 安全漏洞的修補速度將放慢
• 新功能開發停滯
• 上游函式庫（libp2p）的不相容變更需要社群自行吸收
• 公共 gateway 可能在 Protocol Labs 決定放手後直接停擺

數據解讀：誰是真正的贏家與輸家

讓我們從數字層面看清這個事件的全面貌：

從使用者角度，Web3 NFT 生態系是最大受衝擊者——絕大多數 NFT 圖片當年託管在 IPFS（許多透過 ipfs.io gateway），若 gateway 停擺，這些 NFT 將「指向不存在的地方」。Hacker News 上 Macha 留言一語道破：「那些 NFT 持有者，當年 NFT 解析到 ipfs.io 連結的，現在都崩潰了。」

從開發者角度，Kubo/Helia 的使用者短期內仍可運作，但需要密切觀察 GitHub issue 處理速度。一旦漏洞修補停滯，企業級使用者將被迫尋找替代方案（如託管型 IPFS gateway、私有叢集）。

質疑：Protocol Labs 的策略轉向意味著什麼

公告中提到，Shipyard 原本規劃的下一代工作包括：

• 更簡化的 HTTP-native IPFS 實作
• 具韌性且可持續的內容路由
• 大型原生 SHA-256 物件支援
• 透過 Tor 與 onion services 的匿名託管與檢索

這些都是 IPFS「真正落地」的關鍵拼圖。但 Protocol Labs 選擇不再資助，意味著在他們的優先順序中，這些功能不再是當前戰略重心。相對地，他們已將資源投入 Filecoin 商業化（FilOz 平台、Storacha 品牌整合）以及 AI 資料基礎設施（FilOz 主打 S3 物件儲存方向）。

這樣的策略轉向，與 IPFS Shipyard 公告中提到的「We were excited about delivering the next chapter for IPFS」形成強烈對比。Shipyard 還想做 Protocol Labs 已經不買單的東西。

另一個值得質疑的點是交接期僅至 9 月底。從 8 月 24 日公告到 9 月 30 日只有 37 天，對一個維護十幾個核心專案的團隊而言，過渡時間極為緊迫。Protocol Labs 沒有給予額外的 transition funding，這本身就是一個訊號。

未來觀察重點

短期（1-3 個月）：

• Kubo、Helia 等專案的 GitHub issue 回應速度是否顯著下降
• Protocol Labs 是否宣布 ipfs.io、dweb.link 等基礎設施的接手或關閉計畫
• 是否出現新的社群主導維護團隊（例如 PL 之外的 IPFS working group）

中期（6-12 個月）：

• IPFS 在 NFT、Web3 應用中的實際使用率變化
• 替代方案興起：Ceramic、Hypercore、Iroh 等點對點技術是否能填補空缺
• Filecoin / Storacha 商業化路線是否成功

長期（2 年以上）：

• IPFS 是走向「類 IPv6」的技術（標準存在但採用緩慢），還是真正成為主流 Web 基礎設施的一環
• 點對點儲存協議是否能找到可持續的商業模式

相關資源

• 原始公告：The end of IPFS at Shipyard（Cameron Wood, Adin Schmahmann，2026-08-24）
• Hacker News 討論串（285 分、145 留言）
• IPFS Shipyard 官方網站
• IPFS Project GitHub 組織（226 個公開 repo）
• Kubo：Go 語言 IPFS daemon
• Helia：JavaScript IPFS 實作

編按：Siami 將持續追蹤 IPFS 核心專案的後續維護狀況。若有新的社群主導團隊成立或 Protocol Labs 宣布基礎設施的接手計畫，將另發報導更新。