以太坊合并以来最大升级 Glamsterdam影响解析
时间:2026-07-01 10:52
以太坊Glamsterdam升级通过内置PBS、区块级访问列表和Gas重新定价重构区块生产与执行引擎,旨在提高主网容量并遏制状态膨胀,为未来大幅提升GasLimit奠定基础,被视作自TheMerge以来最大规模升级。
以太坊的下一次大规模升级,眼下已经进入了最后的冲刺阶段。
根据官方路线图,这次名为**Glamsterdam**的升级计划在2026年下半年正式上线。到6月底,开发者网络已进入最终测试阶段,多个客户端正在围绕内置PBS、区块级访问列表和Gas重新定价这些核心功能做最后的压测——当然,具体的激活时间还没定。
与此同时,各大社交媒体上讨论最热烈的,毫无疑问是“主网冲击10000 TPS”这种直观的性能叙事。但抛开这些直观的数字,这次升级本质上是对以太坊的区块生产流水线和执行引擎做了一次脱胎换骨的重构。其改动之深,波及面之广,被开发者社区普遍看作“自The Merge以来最大规模的升级”。

那么,这个听起来有点酷炫的组合词「Glamsterdam」(由共识层升级Gloas和执行层升级Amsterdam拼接而成),到底改了什么?它要解决什么历史遗留问题?又会怎样改变我们日常的链上体验?
### 一、为什么它是“The Merge以来最大规模的升级”?
如果说此前的Dencun和Fusaka升级,重点是为L2的数据可用性(也就是Blob)铺路,那么这次Glamsterdam则把重心重新拉回了L1本身——一场针对主网性能和架构的大修。
说到底,这正是以太坊如今“让L1再次伟大”最真实的底层逻辑:怎样让主网承载更多交易,同时又不让运行节点的成本和网络的中心化风险同步攀升。
不过,对于普通用户来说,历届以太坊升级往往会被简化为一个最直白的问题:**Gas费会不会降?速度会不会快?** 但说实话,即将到来的Glamsterdam很难用简单的“降费”或“扩容”来概括。
这次升级涉及以太坊底层的多个关键环节,包括区块由谁来构建、交易如何执行、节点如何读取和同步状态、不同操作该支付多少Gas。它等于是在重新设计以太坊生产和处理区块的基础范式。按照目前已披露的技术细节,最值得关注的核心变化主要集中在三个方面:
- **内置PBS(ePBS)**:重构区块提议者与构建者之间的博弈关系,消除外部中继依赖;
- **区块级访问列表(BALs)**:为交易执行提前画好地图,为并行处理和更快的节点同步铺路;
- **Gas重新定价**:引入更精准的资源计费模型,控制高吞吐量环境下的状态膨胀;

先从内置PBS说起。要理解它,需要先知道以太坊上的区块目前并不一定由Proposer亲自提交。
尤其是在当前的MEV-Boost架构下,绝大多数Proposer会把收集交易、排序、寻找MEV收益这些活儿外包给专业的Builder,自己只负责从多个候选区块中挑一个报价最高的提交上去。这就是所谓的**PBS(Proposer-Builder Separation)**,也就是提议者与构建者分离。
问题在于,这套机制并没有被写入以太坊的底层协议。**Proposer和Builder之间需要依赖一个协议之外的第三方服务——MEV-Boost Relay——来完成报价、交付和付款。** 而这,就带来了一个信任难题:Relay既要保证Builder乖乖交出完整的区块,又要提防Proposer偷看内容后耍赖不付款,实际上扮演了一个异常脆弱又高度中心的“信用中介”。
**EIP-7732提出的ePBS(Enshrined PBS),就是要把这套博弈直接嵌入以太坊的共识协议本身。** 它取消了第三方中继,让Builder成为协议原生识别的参与者。流程变成了:Builder先提交区块承诺和报价,协议自动锁定对应款项,然后由一个专门的“负载及时性委员会(Payload Timeliness Committee)”来判定Builder是否按时公开了执行负载。
这样一来,共识区块和执行负载的处理过程就被拆开了,执行负载的传播和处理窗口从原来的大约2秒延长到了大约9秒。**不要小看这几秒——它对以太坊扩容非常关键:意味着节点能获得更多时间去接收和处理更大的区块、更多的Blob数据,从而为未来提高Gas Limit腾出空间。**
接下来是执行层的另一项核心突破:**EIP-7928提出的区块级访问列表(BALs)**。
目前,以太坊节点在拿到一个区块之前,其实并不知道每笔交易会读取哪些账户、访问哪些合约存储、修改哪些状态。它只能一边执行交易、一边慢慢发现这些数据依赖。这就像进一座大型仓库取货,但没有完整的货物位置清单,工作人员只能一边找一边处理。为了避免两个人同时修改同一批库存,大量工作必须严格按顺序(单线程串行)完成。
而BALs,相当于给每个区块附带了一张完整的“状态访问地图”。**它在区块头就提前声明了:这个区块里的交易集合,会触及哪些地址和Storage Slots,以及交易执行完成后的状态结果。** 通过这张地图,节点在执行前就能一眼判断出哪些交易会竞争同一块数据、哪些交易互不冲突。
对于互不冲突的那部分,节点可以提前从硬盘读取状态,并行处理部分交易的验证和状态根计算,不用再把所有工作都挤进一条严格的单人队伍。更妙的是,由于BALs还记录了交易完成后的状态变化,部分节点在同步和追赶网络状态时,可以利用这些结果直接重建状态,而不必在所有场景下都从头执行每一笔交易——这里有点分片理念的味道。长期来看,这也是以太坊主网突破性能天花板的关键底层技术。

最后是**Gas重新定价**,通过经济杠杆对多项链上操作的Gas费用进行大刀阔斧的校准。
你猜真正的原因是什么?很简单:**当前以太坊的Gas成本和节点实际承担的资源消耗,根本对不上号。** 比如一次纯粹的计算,执行完就结束了,不会给节点留下什么长期负担。但创建一个新账户、部署一份智能合约、写入一个新存储槽,这些操作会产生需要全球所有全节点永久保存的数据。
过去,这些“状态创建”行为的费用,并没有完全反映它们带来的永久存储成本(也就是“状态爆炸”)。如果以太坊在提高Gas Limit后还维持原有定价,更多的区块空间就可能迅速变成失控的状态数据,最终彻底压垮节点的硬件。
已经被确认纳入Glamsterdam范围的**EIP-8037**,就是要彻底重构这套规则。它的核心思路是:计算与状态分离核算——按新增状态数据的体积重新计算成本,把普通计算Gas和状态Gas分开。这样一来,创建大量新账户、部署冗余合约或者频繁写入新状态的应用,操作成本会上升;而主要消耗即时计算资源、不持续增加状态的应用,费用结构会更友好。
说到底,Glamsterdam的Gas改革不是简单的“全面降费”,而是理清一笔交易到底消耗了多少即时计算资源,又给网络留下了多少长期存储负担,然后让不同的操作按照更接近真实物理成本的方式去付费。
把这三部分放在一起看,会发现它们看似独立,但**最终都指向同一个目标:为以太坊主网进一步大幅提高Gas Limit和处理能力,提前改造好底层的基础设施。**
### 二、为什么不能直接把区块调大?
很多人可能会问:既然嫌慢嫌贵,为什么不直接调大Gas Limit,把区块容量翻倍就行?
这是个老生常谈的问题。理论上,提高主网容量最直接的办法确实就是提高Gas上限——Gas Limit越高,一个区块能容纳的交易和计算就越多。
但Gas Limit不是能无限上调的数字。区块一旦盲目变大,就会引发多米诺骨&牌效应:节点需要在相同时间内接收更多数据、执行更多交易、计算新的状态。如果处理速度跟不上,配置较弱的节点就容易掉队,区块传播和验证可能出现延迟,最终增加网络分叉和中心化风险。
更糟的是,更多交易还意味着更多永久写入以太坊数据库的账户、合约和存储数据。这些数据不会因为交易结束就消失,而是会不断积累在以太坊的状态数据库中,导致状态更快膨胀。
所以,以太坊扩容面对的不是一个简单的数学问题,而是需要同时解决三个难题:
- 第一,怎么给节点留出更多传播和处理大区块的时间;
- 第二,怎么减少交易按顺序执行带来的性能瓶颈;
- 第三,怎么防止更多区块空间迅速转化为失控的状态膨胀;
**这正是Glamsterdam的核心逻辑:不是先盲目扩容、再让节点去硬扛,而是先重构区块生产、交易执行和资源定价的方式,从底层疏通管道,再自然地为提高主网容量打开大门。**
其中,ePBS通过重新安排Slot内的区块处理流程,为节点赢取更多时间;BALs通过显式提供状态访问关系,提高客户端读取、执行和同步的效率;Gas重新定价则负责遏制不可持续的状态增长。
在2026年4月的Glamsterdam协作测试中,核心开发者们围绕多客户端实现进行了集中压测,明确提出了升级后以**2亿Gas作为可信容量下限**的技术目标。而这一目标的背后,正是ePBS、BALs和状态Gas重定价共同提供的底层支撑。
当然,2亿Gas更接近升级后系统具备的承载能力,以及未来可以逐步演进的方向。这并不是说,主网会在Glamsterdam激活当天立刻把Gas Limit跳到这个水平。
真正重要的信号是:**以太坊正在从过去的“谨慎试探性扩容”,转向“通过底层结构重构,为更大幅度的主网扩容提前做准备”。**
### 三、普通用户和以太坊生态会受到哪些影响?
对普通用户来说,Glamsterdam升级最值得关心的问题,毫无疑问是:交易费用会降吗?
整体的答案更偏向“有望下降并变得更稳定”,而不是“所有交易立刻变便宜”。
由于ePBS和区块级访问列表为更高Gas Limit创造了条件,**可以预见的是,每个区块能容纳的交易量会增加。在链上需求不变的情况下,区块空间供给增加,自然有助于缓解拥堵,降低Base Fee突然上涨的概率。**
但具体到单笔交易,不同操作的变化可能并不一致。比如,普通ETH转账可能从基础Gas优化中受益;同时,由于BALs提前告知了状态路径,钱&包在预估Gas费时的准确度会大幅提升。过去那种因为行情波动导致钱&包Gas预估不准、交易失败却还是扣手续费的糟糕体验,将成为历史。
但另一方面,部署合约、批量创建账户或写入大量新状态的操作,可能因为状态重新定价而增加成本。所以,Glamsterdam更可能带来的结果是:**简单交易成本下降,拥堵时期费用更稳定,同时状态密集型应用开始为长期占用的网络资源支付更准确的价格。**

对主要使用L2的用户来说,这次升级也并非没有关系。ePBS把执行负载的数据传播窗口从约2秒延长到约9秒,不仅支撑更大的主网区块,也为以太坊处理更多Blob数据留出了空间。Blob容量继续扩大后,Rollup提交交易数据的空间会更加充裕,长期看有助于稳定L2的数据成本。
对钱&包、交易所和跨链桥来说,一个容易被用户感知的变化,可能来自**EIP-7708**。
目前,ERC-20代币转账通常会产生标准化的Transfer日志,但部分智能合约之间的原生ETH转移,并不会留下同样清晰的事件记录。钱&包和交易平台经常需要依赖额外的“内部交易追踪”工具,才能识别这部分ETH流动。
EIP-7708要求非零ETH转账和ETH销毁操作生成标准日志,让钱&包、交易所和跨链桥更可靠地识别充值、变钱和合约内部的ETH变动。未来用户看到的ETH资产记录会更加完整,部分此前需要复杂追踪才能展示的内部转账,也更容易被钱&包直接识别。
对节点运营者和质押用户,影响则更加直接。Glamsterdam同时改变执行层和共识层的区块处理方式,节点和验证者需要在主网激活前升级到支持Glamsterdam的客户端版本。普通持币用户不需要迁移ETH,也无需进行任何所谓的“资产升级”或“代币兑换”。
**更进一步看,Glamsterdam真正影响的,是以太坊在“扩容”和“去中心化”之间如何重新寻找平衡。** 毕竟区块容量提高后,如果运行节点所需的硬件成本同步大幅上升,虽然主网吞吐量变高了,但网络可能越来越依赖大型机构。
而ePBS、区块级访问列表和状态Gas重定价的组合,试图形成另一种扩容路径:不是简单要求节点在相同时间内处理更多工作,而是重新安排区块生产流程、提前提供交易依赖信息、让不同资源按实际负担收费。
**这正是Glamsterdam与一次普通Gas Limit上调最本质的区别:它没有试图用单个EIP解决所有问题,而是同时改造了区块生产、交易执行和状态增长这三套相互关联的机制。**
### 总结
放眼长远,Glamsterdam真正深刻影响的,是以太坊在“高性能扩容”与“绝对去中心化”之间重新寻找平衡的叙事走向。
这也是以太坊一向的初心——面对高性能单体公链的步步紧逼,不选择简单粗暴地提高硬件门槛,而是选择一条尽量维持去中心化底色、更具底层韧性的路径。这次通过重写区块流水线(ePBS)、提前显式提供交易依赖(BALs)、让不同资源按物理负担精准收费(Gas重新定价)的组合拳,**最终目的还是:在保证普通人可以运行节点、可以参与验证的前提下,硬生生抠出更庞大的主网容量。**
从这一点来看,未来我们支付的每一笔更划算的Gas费、钱&包里更精准清晰的内部ETH账单、L2更广阔的费率下降空间,或许都将在2026年下半年深深受益于Glamsterdam为以太坊重新铺设的这套地基。