从 Glamsterdam 到 Hegotá：扩容之后，以太坊下一阶段解决什么？

BiRun 消息，撰文：imToken 如果把过去几年以太坊的升级串成一条线，主题词毫无疑问就是「扩容」。 从 Dencun 引入 Blob 给 Rollup 大幅减税，到 Pectra 调整验证者效率和质押机制，再到 Fusaka 落地 PeerDAS 降低数据分发负担，协议层几乎把所有精力都砸在了一件事上：让以太坊吞下更多数据，同时别把节点门槛抬得太高。 这套组合拳确实管用，Rollup 的数据成本打下来了，主网 Gas Limit 也在稳步提升，以太坊不再像上一轮牛市那样动辄几十刀手续费让人望而却步。 但路修宽了，车怎么开，依然很别扭： 我们还是要在三四条 L2 之间搬运资产，稍不留神就提错链； 一笔转账明明几秒就打上包了，桥和交易所非要你干等十几分钟才敢确认； 专业 Builder 几乎垄断了区块打包，你想发一笔敏感交易，随时可能被协议外的潜规则拒之门外； 更别提直到今天，一个刚进圈的用户如果只是想转几百块 USDC，还得先去搞明白为什么钱包里必须有 ETH、什么是 Nonce、什么又是 Gas； 这些问题表面上都表现为用户体验的摩擦，背后却牵涉确认规则、区块构建、抗审查与账户模型等更底层的协议机制。 而这也正是从 Glamsterdam 到 Hegotá，从 2026 年 Q4 到 2027 年，以太坊开始集中处理的新问题。 一、扩容不停，但开始「缝合」L1 与 L2 当然，扩容不会踩刹车。 Glamsterdam 依然带有很重的性能取向，其中最引人关注的两项，一个叫 ePBS（EIP-7732），另一个叫 BAL（Block-level Access Lists，EIP-7928），简单理解的话： ePBS 就是把今天已经大量存在于协议外部的 Proposer 与 Builder 分工，更正式地写入协议，顺便把出块和验证的时间窗口切分得更科学，给未来跑更大区块留足缓冲； BAL 则相当于让区块在开头就列出一张「访问清单」，节点一眼扫过去就能提前预取数据甚至并行处理，专治存储 I/O 瓶颈； 只是在扩容之外，今天大部分人的真实痛苦，根本不是以太坊 TPS 够不够高，而是 「链太多了」。 譬如 ETH 在主网，玩的 meme 在 Robinhood Chain，支付结算用的 USDC 又可能在 Arbitrum，想抄底的 USDC 在 Base..... 对以太坊基金会来说， Rollup 们都是以太坊版图的一部分，但对用户来说，这跟跨国换汇、办签证没什么区别。 因此，要把散落的拼图重新缝成一张网，除了跨链协议各显神通，协议层最近在推的一项底层机制很值得关注——FCR（Fast Confirmation Rule，快速确认规则）。 很多人以为交易被打包进区块就算成了，但在密码学与共识层面，一个刚出的区块完全可能遭遇微小重组，真正不可逆的「最终性（Finality）」，以太坊需要走完两个 Epoch，大概耗时 13 分钟。 这平时转账无所谓，但对跨链桥、大额清算和中心化交易所来说简直是折磨，为了不担重组风险，它们只能让你硬等。 FCR 的巧思在于，不必傻等十几分钟的完整 Finality，而是利用验证者本来就会持续产生的 Attestation， 根据已经累积的投票权重，更早判断某个区块是否已经获得足够强的共识支持。 按照以太坊基金会给出的目标，在网络保持正常同步的情况下，FCR 有望把这种「强确认」提前到大约 15～30 秒，虽然不等同于完整 Finality，但对于许多今天不得不等待最终性的桥、跨链通信和基础设施而言，已经足以提供一个更早、且具备明确安全。