Google Cloud 入局，Puffer UniFi 能補上 Based Rollup 的最後一哩路嗎？

一家 Web2 大廠的入局，把「Gateway」這個此前更多存在於技術語境的新概念，推向了大众视野。

9 月 22 日，Puffer 宣布與 Google Cloud 達成合作，Google Cloud 將作為關鍵基礎設施合作夥伴，透過 Puffer Preconf 運行 Gateway，支持 Puffer UniFi 的執行層，協助處理交易，並在交易最終結算至以太坊之前提供 Execution Preconfirmation。

更值得關注的是，Puffer UniFi 將成為首個使用 Google Cloud Gateway 的 Rollup。

不過，如果只把這理解為「又一家 Web2 巨頭進入 Web3」，可能會錯過這次合作背後更值得討論的部分。

因為 Google Cloud 這次扮演的，並不是傳統意義上為區塊鏈項目提供算力、節點託管或雲服務的外圍角色。相反，它正在直接進入 Puffer UniFi 的實時執行架構，成為連接交易處理、Preconfirmation 與最終以太坊結算的 Gateway 層之一。

這也引出了一個更大的問題：Puffer UniFi 究竟在構建什麼？為什麼它需要 Gateway？而 Google Cloud 又為什麼會選擇從這個相對底層的位置切入以太坊？

答案，或許要從以太坊 L2 正在進入的新階段說起。

一、Puffer UniFi：下半場 Rollup 的一種答案

步入 2026 年後，以太坊的 Rollup 戰略，明顯處於一個微妙的時刻。

從 Vitalik Buterin 掀起對 L2 路徑的反思開始，L2 作為以太坊擴容工具的階段性歷史使命，就在市場和輿論層面宣告完成。

一個問題開始變得越來越尖銳，即當 L2 不再只是為 L1 分擔擁堵壓力的擴容工具，它到底該如何定義自己的存在？又該如何與 L1 重新形成更統一的安全、排序、流動性和可組合性關係？

Puffer UniFi，正試圖給出其中一種答案。

Puffer UniFi 選擇的並不是繼續運行一套相對獨立的中心化排序體系，而是走向 Based Rollup：讓 Rollup 的排序權更加直接地錨定 Ethereum L1，由以太坊驗證者體系參與排序，並最終繼承 Ethereum 本身的安全性與中立性。

這並不意味著 L2 已經失去意義。

更準確地說，隨著單純擴容的階段性任務逐漸完成，Rollup 開始需要重新回答自己的價值定位：未來究竟是繼續作為一條泛化執行層存在，還是圍繞更明確的應用、場景與用戶體驗，成為與以太坊更緊密協同的應用基礎設施？

畢竟對 5 年前的以太坊來說，L2 擴容稱得上一條非常現實、也非常成功的路線，但 5 年後的今天，資產和流動性被分散在數十個獨立的孤島上，Rollup 有必要進行重新定位，譬如 Vitalik 倡導的有明確應用場景和業務邊界的應用鏈導向。

Based Rollup 的意義，就在於試圖重新調整這種關係。

它的核心思路並不複雜，既然 Rollup 最終仍然依賴以太坊完成結算和安全驗證，那麼排序權也可以更直接地回到以太坊 L1，由以太坊驗證者體系來負責 Rollup 排序，那理論上不僅可以消除 Rollup 對單一排序器的依賴，也能真正實現 L1 與 L2 之間的同步可組合性。

換句話說，Based Rollup 給出的不是「再造一條更快的 L2」，而是一個更接近以太坊原生路線的答案——讓擴容不再意味著分裂，讓 L2 的增長重新反哺 L1 的安全與價值。

這是一個在理論上幾乎無可挑剔的方向，但問題在於，理論上的最優解，並不自動等於現實中的可用系統：

• 第一道現實約束是速度。以太坊 L1 出塊時間約是 12 秒，如果 Rollup 排序完全跟隨 L1 節奏，那每筆交易都至少要等一個 L1 區塊才能獲得相對可靠的確認，普通轉賬也許還能接受，但對即時支付、訂單簿、永續合約乃至高頻 DeFi 應用而言，顯然無法與中心化排序器提供的亞秒級反饋相提並論（延伸閱讀《Preconfs 進化論：從「補丁」到「基建」，UniFi AVS 如何影響 Based Rollup 的遊戲規則？》）；
• 第二道約束是執行負擔。眾所周知，以太坊長期堅持降低驗證門檻，致力於讓更多普通硬件和個人節點能夠參與網絡共識，但 Based Rollup 要求 L1 驗證者直接承擔高頻排序、低延遲執行等角色，難免助推驗證者的硬件、網絡和運維門檻被抬高，反而可能在執行層造成新的中心化壓力；
• 第三道約束則來自激勵結構。對於很多 L2 團隊來說，如果遷移到 Based 架構意味著技術複雜度上升、又得不到足夠收益，那麼繼續維持自己的中心化排序器，仍然是更理性的選擇；

所以，Based Rollup 的問題從來不是方向不對，而是距離真正可用還缺一層現實基礎設施——只要系統完全被 L1 的 12 秒節奏鎖住，它就很難兼顧速度；而如果想在不重新中心化的前提下，既保留主網的中立性，又獲得接近中心化排序器的交互體驗，就必須在執行層引入新的角色分工。

這也是 Puffer UniFi 必須解決的核心矛盾。

Puffer Preconf 正是在這一背景下被納入 Puffer UniFi 的核心技術棧——作為建立在 EigenCloud（原 EigenLayer）上的一套預確認服務，排序權依然錨定在 Ethereum L1，但高性能排序、低延遲反饋與執行預確認，不必全部由 L1 Validator 親自完成。

換句話說，如果 Based Rollup 回答的是 Puffer UniFi「最終依賴誰排序和結算」，那麼 Puffer Preconf 解決的，則是「在最終結算之前，用戶如何獲得實時且可信的執行體驗」。

而這也正是理解 Gateway 的起點。

二、實時執行：Puffer UniFi 為什麼需要 Preconf？

理解 Gateway 之前，首先要理解 Preconfirmation 到底在承諾什麼。

事實上，在主流 L2 中，用戶之所以能夠快速看到交易反饋，往往是因為中心化排序器先給出了一種 soft guarantee，告訴你這筆交易已經進入隊列，前端也很快顯示執行結果，讓用戶在體驗上感覺「已經確認」。

但嚴格來說，這種快速反饋更多建立在對單一排序器的信任之上。

一旦排序器宕機、延遲、作惡或遭遇審查，這種承諾往往缺乏足夠強的經濟約束和可驗證責任機制。換句話說，傳統 Rollup 的「快」，很大程度上來自排序器本身的信譽。

對於 Puffer UniFi 來說，這顯然不夠，而 Puffer Preconf 要解決的，正是這個問題。

它試圖把「快速確認」從一種對單一操作者的信任，提升為一種由經濟擔保、簽名承諾與責任機制支撐的執行承諾——這不只是讓 Puffer UniFi 更快，更要讓這份「快」變得可信。

想理解這套架構，就必須看清它的角色分工。

在 Puffer Preconf 的設計中，L1 驗證者仍然是排序權的最終來源，也是以太坊安全性與中立性的錨點，但卻不需要親自運營高性能排序系統，也不需要直接承擔所有低延遲執行工作，相反，透過再質押與委託機制，驗證者可以把這部分複雜工作交給更專業的 Gateway，由 Gateway 代表其承接 Sequencing 與 Execution Pre-Confirmation。

換言之，真正承接排序與預確認職責的，是新角色 Gateway。

它並不是傳統中心化 Sequencer 的簡單改名，更不是某個額外附著在 Rollup 上的「加速插件」，它更像是在 L1 主權之下，被委託承擔排序與預確認職責的專業執行代理層：

• 一方面，它幫助 L1 Proposer 提供更高性能的排序與預確認服務；
• 另一方面，它又通過抵押、簽名承諾、罰沒與收益分配等機制，避免自己變成新的無約束中心化節點；

Gateway 使得驗證者不必親自運營一個高性能排序系統，但排序權的最終歸屬仍然錨定在以太坊 L1。

這也解釋了為什麼 Puffer 強調的是 Execution Pre-Confirmation，而不僅是 Inclusion Promise：Inclusion promise 只承諾這筆交易會被放進區塊，Execution Preconfirmation 進一步解決的是「這筆交易是否會按照預先承諾的狀態被執行」的問題。

這個差別對於高價值鏈上應用極其重要。

以永續合約 DEX 為例。對這類場景而言，用戶最怕的並不是訂單沒有被打包進區塊，而是雖然被打包了，但最終成交價格、成交順序或清算狀態已經發生偏移。在此背景下，Execution Preconf 就能保證用戶按下單時看到的狀態成交，而不是承受額外滑點或不可預期的執行結果。

同樣的邏輯也適用於鏈上中央限價訂單簿、機構訂單流、支付結算、借貸清算、跨層實時狀態讀取等場景。CLOB 需要確定性的執行順序與低延遲反饋，機構交易需要可追責的狀態承諾，支付與薪資分發需要可預測的結算體驗，清算系統則需要在劇烈行情下盡可能減少狀態漂移。

當然，任何強承諾都必須伴隨強約束。在 Puffer Preconf 這類架構中，Gateway 的可信度並不來自它自稱可信，而是來自它必須為自己的行為承擔經濟後果，這裡至少有兩層約束：

Gateway 需要提供抵押才能進入 lookahead 調度；如果某個 Gateway 在自己負責的窗口內沒有按要求及時把 batch 提交到 L1，後續 Gateway 可以代為提交，並觸發對前者的罰沒；

從用戶視角看，如果某筆帶有預確認承諾的交易最終沒有被兌現，用戶可以利用帶簽名的承諾收據去索賠或申請退款；

需要注意的是，具體罰沒機制會隨著網絡階段和實現版本演進而變化，因此更準確的說法不是「Gateway 已經在所有場景下被 slashing」，而是 Puffer Preconf 的設計方向，是用抵押、獎勵、懲罰和簽名責任，取代傳統中心化排序器下缺乏約束的軟承諾。

除了技術架構之外，另一個繞不開的問題，是激勵。

畢竟傳統 Rollup 模式下，大部分排序收益歸 Rollup 運營方；純 Based 架構下，這部分收益又更自然地流向 L1 驗證者，兩邊都不夠平衡。

Puffer Preconf 的思路，是把預確認費用和排序相關收益，拆分給 L2 Operator、Gateway、L1 Validator 與協議本身等不同角色，這樣一來，L2 團隊不必在「保持體驗」與「回歸以太坊」之間二選一，L1 驗證者也有動力參與更高性能的預確認服務，Gateway 則成為承接專業執行能力的新經濟角色。

這裡的重點不在於「再切一次蛋糕」，而在於把原本存在利益張力的幾類角色，拉進同一套可協作的經濟模型中，使得 L2 可以繼續獲得收益分成，L1 Validator 獲得新的參與激勵，Gateway 則用專業化能力換取服務收入，並通過抵押、簽名承諾和潛在罰沒機制承擔責任。

走到這裡，也就更容易理解 Puffer Preconf 對 Puffer UniFi 的意義。

接下來真正的問題，也就變成了：誰來運行 Gateway？

Google Cloud 的加入，正是在回答這個問題。

三、從架構到現實：Google Cloud 補上 Puffer UniFi 的 Gateway 拼圖

理解完前面的技術關係，再回頭看 Google Cloud 與 Puffer 的合作，意義就更加清楚了。

Google Cloud 這次進入的，並不是一個孤立存在的 Preconf 網絡，它正在以 Gateway 身份，直接進入 Puffer UniFi 的實時執行架構。

按照雙方公佈的合作方式，Google Cloud 將作為關鍵基礎設施合作夥伴，透過 Puffer Preconf 運行 Gateway，支持 Puffer UniFi 執行層的交易處理，並在交易最終結算至 Ethereum 之前提供 Execution Preconfirmation。

這也是為什麼，這次合作不能簡單理解為一家 Web2 巨頭「給 Puffer Preconf 背書」，對於 Puffer 來說，更重要的意義在於，企業級基礎設施開始真正進入 Puffer UniFi 的執行架構。

畢竟，Puffer UniFi 如果希望服務下一代 DeFi、機構交易甚至 AI Agents，那麼實時執行需要面對的將是真實的交易負載、基礎設施穩定性、網絡性能以及持續運行能力。

協議可以定義規則，但最終仍然需要有人把這些規則穩定地跑起來，Google Cloud 作為 Gateway 加入，補上的恰恰是這一塊。

而把視野再拉遠一點，Puffer UniFi 的意義也不僅僅在於自己成為一條新的 Based Rollup，它更像是 Puffer 首先把整套架構產品化的地方。

更值得關注的是，如果 Puffer UniFi 能夠證明 Based Sequencing、Preconfirmation 與 Ethereum Settlement 可以在真實生產環境中同時成立，那麼它驗證的就不只是一條 Based Rollup，而是一套新的 Ethereum-native Rollup 架構。

對 Puffer UniFi 來說，Puffer Preconf 是其中實現實時執行的關鍵模組；而從更長遠的基礎設施視角看，這套 Preconfirmation 能力未來也可以進一步向更多 Rollup 輸出。

對現有 Rollup，它的吸引力也主要體現在兩點。

首先，可以讓 Rollup 團隊不再獨自承擔排序器運維壓力，使得 Sequencing 工作由 Gateway 與 L1 validator 體系共同承接，但同時 Rollup 團隊也可以通過收益分配機制繼續參與價值捕獲，而不是簡單失去全部排序收入。

換句話說，它不是要求 Rollup 把蛋糕完全交出去，而是重新設計 Rollup owner、Gateway、L1 validator 與協議之間的分潤方式。

其次，它可以提供更強的狀態一致性承諾。對於普通用戶來說，幾美分或幾美元的交易滑點可能不明顯，但對於機構訂單、鏈上訂單簿、衍生品交易和大額清算來說，簽名時看到的價格與最終成交狀態是否一致，直接決定了系統能否承載更高價值的交易流。

因此，從 Puffer UniFi 的整體架構來看，Puffer Preconf 首先承擔的是實時執行基礎設施的角色：它幫助 Based Rollup 解決低延遲與可信執行承諾的問題，並通過 Gateway 將專業化的交易處理能力引入執行路徑。

但 Puffer UniFi 要驗證的並不只是 Preconfirmation 本身，而是 Based Sequencing、實時執行、同步可組合性與 Ethereum Settlement 能否真正組合成一套可用的高性能 Rollup 架構。

從這個意義上看，Puffer UniFi 並不是 Puffer Preconf 的「試驗場」，而是 Puffer 關於下一階段 Rollup 的整體判斷第一次被真正做成一個產品。

Preconf 是其中的實時執行模組，Gateway 是承載這一能力的專業基礎設施，而 Google Cloud 的加入，則讓 Puffer UniFi 的這套架構距離真實生產環境又近了一步。

寫在最後