以太坊Glamsterdam升级是什么：ePBS与BALs如何推动L1扩容，主网为何推迟至Q4

来源：Odaily Planet Daily（作者：jk）

以太坊核心开发者认为，即将到来的Glamsterdam升级是自The Merge以来最大规模的协议级重组。其名称由两部分组合而来：执行层升级沿用“Amsterdam”，取自此前Devconnect活动的举办地；共识层升级命名为“Gloas”，源自一颗恒星。在Fusaka升级之后，Glamsterdam通过重组网络处理交易和管理不断增长的数据库的方式，从根本上更新以太坊创建和验证区块的机制，以此推进L1扩容。

这次升级围绕三个核心目标展开：

加速处理（并行化）：重组网络记录数据依赖的方式，使其能够安全地同时处理大量交易，而非逐一缓慢处理。

可扩展性：拆分区块创建与验证的繁重工作负载，让网络有更充裕的时间传播更大量数据，而不会降低速度。

可持续性：调整网络费用以准确反映存储新数据的长期硬件成本，为今后提高Gas上限扫清障碍，同时避免硬件性能下降。

此次升级的两项核心提案分别聚焦共识层与执行层：

两项核心提案。来源：Ethereum

核心提案一：ePBS，将“外包中介”转为“内置规则”

先来看共识层的核心提案，其将提议者与构建者在协议内进行分离，英文简称为ePBS（EIP-7732）。

以太坊每次出块实际上分两步：一人负责“选择哪个区块”（提议者），另一人负责“实际组装区块内的交易”（构建者）。目前，这种分工并非由以太坊协议本身规定，而是依赖一组链下“中介公司”（通常称为relay）来促成。这种链外关系在区块验证阶段形成了一条路径，迫使验证者必须在紧张的2秒窗口内匆忙完成交易广播与执行，限制了网络可处理的数据量。打个比方，这好比一家餐厅的点餐与出餐流程依赖独立的外部联络员来协调传菜，一旦联络员失灵，厨房与前台就可能对不上。

ePBS所做的，就是把这套“点餐-烹饪”分工写进餐厅自己的运营手册，不再依赖外部联络员。由此，可信的链上区块交付与支付机制被直接内置到协议中，无需第三方中间件。不过，如果双方希望使用协议尚未规定的复杂功能，仍可回退到外部联络员模式。此外，为防止“传菜”阶段出现混乱，ePBS设立了“菜品核验组”，检查“谁下的单”和“菜品是否按时备好”，从而将原本2秒的交付窗口延长至约9秒，让餐厅能同时处理更多订单，也意味着以太坊可以承载更多面向Layer 2的数据。

核心提案二：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日；随后是原定2026年8月3日的Sepolia测试网分叉，以及原定8月17日的Hoodi测试网分叉，主网激活目标日期曾定为2026年9月16日。

原定时间表面向2026年上半年。来源：Ethereum

然而，根据最新进展，这一时间表很可能已被推迟。EthPandaOps团队近期上线了名为Plataberget的新测试网，这是首个专为Glamsterdam设立的短期公共测试网。Sepolia与Hoodi的官方部署预计将推迟到9月，主网启动目标也相应移至2026年第四季度。这是Glamsterdam时间线的第二次延期，此前已从原定的2026年上半年推迟过一次。核心开发者反复强调，升级的正确性优先于满足任何具体日期，因此在正式的ACD会议锁定具体区块高度之前，我们可能要到第四季度甚至年底才能见到该升级上线。

Glamsterdam升级核心要点

从协议设计看，Glamsterdam通过ePBS将区块提议与构建的分工内置到共识层协议，消除第三方中继依赖，并把验证交付窗口从2秒延长至约9秒；BALs则在执行层引入区块级访问列表，使无冲突交易可并行处理，同时让新节点通过复制访问结果而非重放历史交易来完成同步。费用层面，存储与计算费用分离，配合查询操作码提价，目标是将链上数据年增长控制在120 GiB，保障普通硬件可持续运行。

主网推迟的关键观察指标

短期需关注Plataberget测试网的验证结果，以及Sepolia和Hoodi测试网能否在9月完成官方部署。由于核心开发者坚持“正确性优先于时间表”，正式ACD会议何时敲定主网区块高度，仍是决定2026年Q4能否如期激活的最后环节。在区块高度未锁定前，市场不宜将其视为确定性的时间节点。