Glamsterdam 升级，以太坊的 L1 扩容答案

原创 | 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 会议锁定具体区块高度之前，我们可能要在第四季度甚至年底才能看到这次升级了。