Google Cloud 入局，Puffer UniFi 能补上 Based Rollup 的最后一公里么？

Google Cloud 以 Gateway 身份进入 Puffer UniFi，引出了 2026 年 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 主权之下，被委托承担排序与预确认职责的专业执行代理层：