Google Cloud 以 Gateway 身份进入 Puffer UniFi，引出了 2026 年 Rollup 路线的一道必答题。

撰文：农民 Frank

一家 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 应用而言，显然无法与中心化排序器提供的亚秒级反馈相提并论；

• 第二道约束是执行负担。众所周知，以太坊长期坚持降低验证门槛，致力于让更多普通硬件和个人节点能够参与网络共识，但 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 的这套架构距离真实生产环境又近了一步。

写在最后

Rollup 时代不会终结。

只是，L2 完成了「帮助以太坊扩容」的第一阶段历史使命，需要 Based Rollup 等新路线给出一个更贴近以太坊长期路线的答案。

这也是理解 Puffer UniFi 和 Preconf 最准确的方式。

随着 Google Cloud 这样的外部基础设施参与者以 Gateway 身份加入，Puffer UniFi 承载真正的 Rollup 执行需求，Puffer Preconf 提供预确认与经济安全框架，Gateway 则将专业化的交易处理与低延迟执行带进网络，最终状态仍然回到 Ethereum 完成结算。

如果 Puffer UniFi 能够证明，一条 Rollup 可以同时拥有毫秒级执行体验、Ethereum-native Settlement、同步可组合性，以及更加开放的 Gateway 网络，那么它所验证的就不只是一条新的 Based Rollup，而是一种新的可能：

应用可以拥有自己的高性能执行环境，却不必因此离开 Ethereum。

Puffer Preconf 所提供的实时执行能力，也有机会随着这套架构得到验证，进一步服务更多 Rollup、DeFi、机构应用乃至 AI Agents。

毕竟，Make Ethereum Whole，从来不只是一个漂亮口号。

让我们拭目以待。 

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。