作者|jk
以太坊即将迎来的 Glamsterdam 升级,是继 The Merge 之后核心开发者眼中改动幅度最大的一次协议级重构。这个名字来自两部分的组合:执行层升级部分沿用“Amsterdam”,取自往届 Devconnect 举办地阿姆斯特丹;共识层升级部分则命名为“Gloas”,以一颗恒星命名。继此前的 Fusaka 升级之后,Glamsterdam 通过重组网络处理交易和管理其不断增长数据库的方式来推进 L1 扩容,从根本上更新了以太坊创建和验证区块的方式。
这次升级围绕三个核心目标展开:
- 加速处理(并行化):重组网络记录数据依赖关系的方式,使其能够安全地同时处理大量交易,而非缓慢的逐笔顺序处理。
- 扩容:拆分区块创建和验证的繁重工作,让网络有更多时间传播更大量的数据而不减速。
- 可持续性:调整网络费用以准确反映存储新数据的长期硬件成本,为未来的 Gas 上限提升扫清障碍,同时避免硬件性能出现退化。
升级的两项头牌提案分别落在共识层和执行层:
有两大Headliner(头牌)提案。来源:以太坊
头牌提案一:ePBS,把"外包中间商"变成"内置规则"
先说共识层的头牌提案,协议内提议者与构建者分离,英文简称 ePBS(EIP-7732)。
以太坊每次出块,其实分两步:一个人负责“选中哪个区块”(提议者),另一个人负责“把区块里的交易实际组装好”(构建者)。目前这个分工不是以太坊协议本身规定的,而是靠一批链下的“中介公司”(行话叫中继)来撮合完成。这种链外关系还在区块验证期间造成了一条路径,迫使验证者在紧张的2秒窗口内匆忙完成交易广播和执行,限制了网络能够处理的数据量。打个比方,这就好比一家餐厅的点单和做菜环节,原本要靠一个独立的外部对接人来协调传菜,一旦这个对接人掉链子,厨房和前台就可能对不上账。
ePBS 做的事情,就是把这套“点单-做菜”的分工规则,写进餐厅自己的运营规范手册里,不再依赖外部对接人。这样一来,链上可信的区块交付和付款机制被直接构建进协议本身,从而不再需要依赖第三方中间件,不过如果双方想用一些协议里还没规定的复杂功能,仍然可以选择继续用回外部对接人。同时,为了不再让“传菜”环节手忙脚乱,ePBS 还专门设立了一个“验菜小组”,分别检查“谁点的单”和“菜有没有按时做好上桌”这两件事,原来2秒的传菜时间窗口也因此扩大到了约9秒,让餐厅能一次性处理更多订单,也就是让以太坊能承载更多面向 Layer2 的数据。
头牌提案二:BALs,出发前先把“购物清单”列好
再说执行层的头牌提案,区块级访问列表,英文简称 BALs(EIP-7928)。
现在以太坊处理交易的方式,有点像一个人蒙着眼睛去超市买东西:必须先摸到一件商品、确认是什么,才能决定下一步怎么走,所以只能一件一件排队来。因为不提前知道一笔交易会用到哪些数据,比如会涉及哪些账户,系统必须严格按顺序逐笔处理交易,否则两笔交易可能会意外地同时想要修改同一份数据(比如同一个地址的余额),造成冲突出错。
BALs 相当于让这个人在出发前,先拿到一份写清楚“要去哪几个货架、要拿哪几样东西”的购物清单。有了这份清单,系统提前就能看出哪些交易之间完全不会互相“打架”,于是可以把互不相关的交易分成几组,同时并行处理,而不必再一件一件排队。这份清单还有一个额外的好处:新节点加入网络时,可以直接照抄这份清单里记录的最终结果,而不必把所有复杂的历史交易重新算一遍,这样新节点同步进度会快很多。为了配合这份清单真正在网络里流通起来,Glamsterdam 还打包了一项配套的传输协议升级,让节点之间能够实际共享这些访问列表,这项传输协议目前已经成为所有执行层客户端的强制要求。
配套提案:给“占地方”的操作重新算账
除了这两项头牌提案,Glamsterdam 还打包了两项重新定价的配套提案,可以理解成给网络的"仓储费"和"查询费"分别做了一次价目表调整。
- 第一项是新建账户、部署合约这类会在网络里“永久占地方”的操作,以前的收费和它实际占用的空间不太成正比,现在要按照"每占用一份空间就收对应的钱"来重新计费,目标是把整个网络的数据增长速度控制在每年120 GiB这样一个安全、可预测的水平上,确保用普通硬件也能持续跑得动这个网络。同时这笔仓储费会单独开一个账户来核算,不再和处理交易本身的计算费用混在一起,只要开发者愿意多付一点仓储费,依然可以部署规模更大、更复杂的应用,不会被总的 Gas 上限一下子卡死。
- 第二项是查询、读取网络里已有数据这类操作,以前定价偏低,跟不上现在数据量变大之后实际的查询成本,这次会把这类操作码的收费标准提高,让价格更贴近现代硬件真实的负载情况,同时也能防止有人钻费用太便宜的空子,故意用大量查询请求把网络堵住。
主网上线时间:目前还没有定好
在时间表方面,Glamsterdam 目前正处在一个颇为微妙的阶段。官方层面,最近一次可查证的全体核心开发者执行层会议(ACDE)是第241次,在7月16日,主要议程包括 Glamsterdam Devnet 阶段的最新进展汇报,以及为下一次升级 Hegota 投票选出头牌提案。此前业内广泛引用的一份排期显示,Devnet 阶段共进行了从0到7的八轮迭代,时间跨度为2026年3月28日至7月8日,随后 Sepolia 测试网分叉原定于2026年8月3日,Hoodi 测试网分叉原定于2026年8月17日,主网激活的目标日期为2026年9月16日。
原本排期是2026年上半年,来源:以太坊
但从最新动向看,这份排期大概率已经推后。EthPandaOps 团队近期推出了名为 Plataberget 的新测试网,这是专门为 Glamsterdam 设计的第一个短期公共测试网,正式的 Sepolia 与 Hoodi 部署预计要推迟到9月才会跟进,主网上线目标也相应后移至2026年第四季度。这也是 Glamsterdam 继此前从原定的2026年上半年推迟之后,第二次出现日期滑动。核心开发者此前已多次强调,升级的正确性优先于赶上任何特定日期,因此在正式的 ACD 会议锁定具体区块高度之前,我们可能要在第四季度甚至年底才能看到这次升级了。
