如果 Vercel 開源、用 P2P 重寫，會長成這樣：Tau 把 PaaS 變成 Git native 的反 SaaS 實驗
Tau 用 Go + libp2p + WebAssembly 重新實作了一份開源、自架、去中心化的 PaaS。它不是 Vercel 替代品，是用另一種拓樸把 Vercel 的形狀重寫一次。
目錄+
Vercel、Firebase、Cloudflare Workers 三家拿走了現代開發者大部分的 backend——但這三家都不會開源，因為它們的商業模式就是「我幫你跑」。Tau 是 Taubyte 在 GitHub 上開源的一份 Go 專案，5,000+ stars、BSD-3 license、22 個 release，做的事情就是把 Vercel 的形狀用 Git-native + WebAssembly + P2P fabric 重寫一次，讓你可以自己架一個。
這篇拆五件事：Tau 的三個關鍵決策、四層架構、為什麼選 WASM 而不是 container 或 V8 isolate、P2P control plane 的 trade-off、以及它真實的場景與限制。
Tau 在做什麼：三個關鍵決策
Tau 不是「另一個 serverless framework」。它的設計從一開始就在解三個跟 Vercel 不一樣的題目。
決策一：Git 是基礎設施的源頭。Vercel 把 Git 當 trigger——你 push，它幫你 build。Tau 把 Git 當 schema——functions、KV namespaces、PubSub channels、domains、每一個資源都是 git repo 裡的檔案。branch 對應 environment（main = prod、dev = staging），merge 就是部署。整個 control plane 沒有 dashboard，只有 git。
決策二：runtime 統一是 WebAssembly。Tau 不跑 container，不跑 V8 isolate，所有使用者程式都被編譯成 WASM 後在內建 runtime 執行。這個選擇直接決定了它的多租戶安全模型、cold start 表現、與支援語言光譜——只要編得到 WASM，就能跑（Go、Rust、AssemblyScript、TypeScript via Javy 等）。
決策三：control plane 是 P2P 不是中心化。Tau 的節點之間用 P2P fabric（基於 libp2p 思路）做服務發現、路由、複製。沒有中央 scheduler，沒有 master node。任何一台機器加進叢集都是對等節點，掛掉一台不會影響其他節點繼續服務。
四層架構
把這三個決策疊起來，Tau 的架構就清楚了：
最上層是 Git source of truth：開發者 push 上去，repo 結構決定了整個 application 的形狀。
第二層是 Spore Drive auto-deploy：監聽 git event，把使用者程式碼編譯成 WASM artifact，丟進叢集。
第三層分兩塊。WASM Runtime 跑使用者函式，提供 multi-tenant 隔離；內建服務包括 KV、Object Storage、PubSub、DNS/HTTPS、private network、load balancer、E2E test，這些都不是 add-on，是 Tau 的一部分。
第四層是 P2P fabric，把上面所有東西串成可水平擴展、無單點故障的拓樸。請求流就是：HTTPS request → P2P 節點 routing → WASM 執行 → 內建服務 IO → 回應。沒有 control plane API call、沒有 scheduler bottleneck。
為什麼是 WASM 而不是 container 或 V8 isolate
選 runtime 是 PaaS 最關鍵的架構決策。三個選項各自有信徒：
Container（Docker / K8s 路線）——通用、什麼語言都能跑，但啟動成本高、隔離靠 OS 層、攻擊面大。AWS Lambda、Google Cloud Run 走這條路，cold start 動輒幾百毫秒到幾秒。
V8 isolate（Cloudflare Workers 路線）——cold start 極快、隔離夠用，但綁定 JavaScript 生態。Cloudflare 為了支援 Python 還得透過 Pyodide 把 CPython 編譯成 WASM 再丟進 V8，繞了一大圈。
WASM（Tau / Fermyon / Wasmer 路線）——cold start ms 級、隔離靠 sandbox 設計、語言中立。代價是生態還在長，許多 native lib 還沒 WASM 版本。
Tau 選 WASM 的邏輯很直接：如果 PaaS 的競爭力是「跨語言」+「快」+「安全」，container 太慢、V8 isolate 太綁 JS，WASM 是唯一同時打中三點的選項。這也是為什麼 2025–2026 年新一代開源 PaaS 幾乎都站到 WASM 這邊。
P2P control plane 的 trade-off
P2P 是 Tau 最有爭議的決策。它的好處很明顯——沒有單點故障、節點對等、自然支援邊緣部署、可以跨資料中心甚至跨家用電腦組叢集。但代價也是真實的。
一致性比較難。中心化 scheduler 可以保證「同一秒誰拿 lock」，P2P 要靠 gossip protocol 與分散式共識，狀態收斂有延遲。對 stateless function 沒問題，但對需要 strong consistency 的場景（金流、庫存）需要在應用層自己處理。
debug 比較難。中心化系統你看 control plane log 就知道發生什麼事，P2P 系統你要看一群節點的 log 才能拼出全貌。Tau 內建了 trace 工具但這是真實的營運成本。
節點規模的甜蜜點不一樣。中心化系統十台機器跟一千台機器架構不變，P2P 系統幾十個節點時最舒服，幾千個節點時 gossip 流量會變大。Tau 適合的是中型自架叢集，不是 hyperscale。
真實場景與限制
Tau 不是 Vercel 替代品。如果你今天有一個 SaaS 跑在 Vercel 上、想搬下來，Tau 不會是最短路徑——你還是會花很多時間自己處理 DNS、監控、備援。Tau 真正適合的場景是另外三類：
自架優先的團隊——金融、醫療、政府、軍工，資料不能離開自己機房，但又想要 Vercel 等級的開發體驗。Tau 給你 git push 即部署，不用自己拼 K8s + ArgoCD + Cert-manager。
邊緣運算情境——工廠、零售、IoT 場景，幾百個邊緣節點要自己跑函式，又要中央能管。P2P 拓樸天然適合這個 layout。
研究與教學——想理解 PaaS 內部怎麼運作、想自己改 runtime、想把 WASM 拿來實驗，Tau 是少數有完整原始碼可讀的開源 PaaS。
不適合的場景也很清楚：你只是想快速 deploy 一個 side project、不想管基礎設施——那直接用 Vercel free tier，沒必要自架。
收尾
Tau 不是要替代 Vercel。Tau 是證明 Vercel 的形狀可以脫離 Vercel 公司存在——只要你願意自己跑。在 hyperscaler 把開發者體驗鎖在自家平台的這個時代，這件事本身就是值得記住的訊號。下次有人說「serverless 一定要交給雲廠商」，你可以丟這個 repo 給他看。