一次比肩"合并"的底层手术

熟悉以太坊的人都知道,"合并"(The Merge)是一次历史性的技术切换——它让以太坊从耗电的 PoW 转向了 PoS。而接下来要登场的 Glamsterdam 升级,被核心开发者们称作合并以来最大规模的一次协议级重构。

这名字听起来有点奇怪,其实是两部分拼出来的:执行层升级沿用了"Amsterdam"(阿姆斯特丹),这是之前某届 Devconnect 大会的举办城市;共识层升级则叫"Gloas",是一颗恒星的名字。换句话说,这是一次"城市+恒星"的联名升级。

在它之前,以太坊刚完成 Fusaka 升级。如果说 Fusaka 是修补,那 Glamsterdam 更像是动刀——它要重新设计以太坊处理交易、管理数据库增长的方式,从底层改变区块的创建和验证流程。

为什么这次升级很重要?

要理解 Glamsterdam 的分量,得先看以太坊现在卡在哪儿。

L1(Layer 1)主网的处理能力一直是个瓶颈。交易得一笔一笔排队验证,数据稍微多点就容易堵车。过去几年,整个行业的解题思路是把流量往 Layer 2 疏导——既然主路堵,那就走辅路。但辅路(各种 L2)扩容的前提是,主路得有能力承载它们不断回传的数据。如果 L1 本身的数据吞吐上不去,L2 的天花板同样受限。

Glamsterdam 的思路很直接:升级 L1 本身的能力。它围绕三个目标展开:

  • 并行处理:重新梳理网络记录数据依赖的方式,让大量交易可以同时处理,而不是一个个排队

  • 可扩展性:把区块创建和验证的"重活"拆开,给网络留出更多时间去传播更大的数据块,不会因此拖慢速度

  • 可持续性:调整网络费率,让费用真实反映长期存储数据的硬件成本,为未来提高 gas 上限扫清障碍,同时避免硬件性能被拖垮


一句话概括:这次升级就是在不牺牲去中心化的前提下,让以太坊主网本身变得更快、更能装。

主打提案一:ePBS,把"外包中介"变成"内置规则"

先看共识层的主打提案:ePBS(EIP-7732),全称是"In-Protocol Proposer-Builder Separation",即"协议内提议者-构建者分离"。

以太坊每个区块的生产,本质上分两步:一方负责"决定选哪个区块"(提议者/proposer),另一方负责"实际组装区块里的交易"(构建者/builder)。这本来是再正常不过的流水线分工,但问题在于——这种分工目前并不是以太坊协议本身定义的,而是靠一组链下的"中间人"来协调,业内管它们叫 relay(中继器)。

这个"外包"模式带来了连锁反应:区块验证时出现了瓶颈,验证者被迫在一个极其紧张的 2 秒窗口内完成交易广播和执行,这直接限制了网络能处理的数据量。

打个比方:一家餐厅,点单和后厨之间靠一个外部协调员传话——协调员一掉线,前台和后厨就可能对不上。ePBS 做的事情,就是把"点单-做菜"的分工直接写进餐厅自己的运营手册里,不再依赖外部协调员。

这样一来,区块交付和支付的信任机制就被内置到协议里,不再需要第三方中间件。当然,如果你想用协议还没定义的复杂功能,双方仍然可以自己选择继续用外部协调员。

ePBS 还顺手解决了一个隐患:为了避免"送菜"环节出乱子,它建立了一个专门的"菜品检查小组",分开核查"谁下的单"和"菜有没有按时做好端上来"。这把原来 2 秒的交货窗口拉长到了大约 9 秒。

窗口拉长意味着什么?餐厅能同时接待更多订单——以太坊就能为 L2 网络承载更多数据。这对整个 Rollup 生态来说,是实打实的利好。

主打提案二:BALs,出发前先备好"购物清单"

执行层的主打提案是 BALs(EIP-7928),全称"Block Access Lists",即区块访问列表。

目前的以太坊处理交易,有点像一个人蒙着眼睛逛街:你必须先摸到一件商品、确认它是什么,才能决定下一步。因为系统事先不知道一笔交易会用到哪些数据——比如会涉及哪些账户——所以它必须严格按顺序处理交易。否则两笔交易可能同时想改同一份数据(比如同一个地址的余额),就会产生冲突、报错。

BALs 的思路,相当于给这个人一张提前写好的购物清单:"去几号货架、拿哪件商品"都写清楚了。有了这张清单,系统就能提前看出哪些交易之间根本不会冲突,于是可以把不相关的交易分组,并行处理。

清单还有额外福利:新节点加入网络时,可以直接复制清单里记录的最终结果,不用把历史上复杂的交易全部重算一遍——新节点的同步速度会大幅提升。

不过,要让清单能在网络上真正流通,还需要配套升级。Glamsterdam 里就包含了一个传输协议的强制升级,让节点之间能够共享这些访问列表。这个传输协议升级已经被列为所有执行层客户端的必选项。

配套提案:给"占空间"的操作重新定价

除了两个主角,Glamsterdam 还打包了两个配套的"重新定价"提案。说白了,就是调整网络"存储费"和"查询费"的价格表。

第一项针对的是"永久占用空间"的操作,比如创建新账户、部署合约。以前,这些费用跟实际占用空间的比例关系不合理。现在改成"占一单位空间,付一单位钱",目标是让整个网络的数据年增长率控制在一个安全可预测的水平——每年 120 GiB。这样,网络在普通硬件上也能长期保持可持续运转。

另外一个细节是,这些存储费会被单独记账,不再跟交易的计算成本混在一起。只要开发者愿意支付稍高的存储费,依然可以部署更大、更复杂的应用,不会因为整体 gas 上限突然被限制。

第二项针对的是查询和读取现有数据的操作。以前这些操作定价过低,没有反映出现代硬件处理日益庞大的数据集的真实成本。这次升级会提高这些操作码的费用,让价格更贴合实际负载,同时也能防止有人利用低费用故意刷大量查询来堵塞网络。

时间线:从 H1 推到 Q4,主网日期仍未锁定

按最初的规划,Glamsterdam 应该在 2026 年上半年上线。当时流传的排期是这样的:

> Devnet 阶段从 3 月 28 日到 7 月 8 日,迭代了 8 个版本(0 到 7);Sepolia 测试网分叉原定 2026 年 8 月 3 日;Hoodi 测试网分叉原定 8 月 17 日;主网激活目标日期是 2026 年 9 月 16 日。

但这个排期已经落空了一次。最新的消息是,EthPandaOps 团队推出了一个叫 Plataberget 的新测试网,这是第一个专门为 Glamsterdam 设计的短期公共测试网。正式的 Sepolia 和 Hoodi 部署,预计要等到 9 月才会跟进。

主网上线目标也随之滑到了 2026 年 Q4。 这是 Glamsterdam 时间表的第二次延期。

以太坊核心开发者反复强调过一句话:正确性永远比赶时间重要。在协议升级这件事上,一次有漏洞的上线可能带来灾难性后果,而推迟几个月只是让社区多点耐心。所以,除非官方 ACD 会议锁定具体的区块高度,否则我们大概率要等到 Q4 甚至年底,才会在以太坊主网上正式看到这次升级。

> 一句话总结:Glamsterdam 是一次真正意义上的底层重构,它想做的事情——并行执行、协议内 PBS、更合理的存储定价——都是冲着"让 L1 重新变得重要"去的。但对于以太坊而言,"慢"不是错误,它是这个网络最可靠的品格。