以太坊即将推进的 glamsterdam 升级，被核心开发者视为自 the merge 以来改动幅度最大的一次协议级重构。这个名称由两部分组成：执行层升级沿用“amsterdam”，取自往届 devconnect 举办地阿姆斯特丹；共识层升级则命名为“gloas”，名称来源于一颗恒星。
如果用更容易理解的话来说，这次升级的重点不是简单增加几个功能，而是要重新整理以太坊处理交易、传递区块数据以及管理不断增长链上数据的方式。在此前 Fusaka 升级之后，Glamsterdam 继续围绕以太坊 L1 扩容展开，并进一步调整区块创建与验证的底层机制。
从目标来看，Glamsterdam 主要集中在三个方向：
- 提升处理效率（并行化）：优化网络记录数据依赖关系的方式，在不牺牲安全性的前提下，让更多交易有机会同时处理，而不是只能一笔接一笔执行。
- 继续推进以太坊扩容：把区块创建和验证过程中负担较重的部分拆分出来，为网络传播更多数据腾出空间，同时尽量避免整体处理速度被拖慢。
- 增强网络可持续性：重新调整费用模型，让费用更贴近新增数据带来的长期硬件成本，为后续提高 Gas 上限创造条件，也帮助缓解节点硬件压力。
在这次以太坊 Glamsterdam 升级中，市场关注度最高的两项核心提案，分别对应共识层和执行层。
Glamsterdam 包含两项最受关注的 Headliner 提案。来源：以太坊
以太坊 Glamsterdam 升级头牌提案一：ePBS 是什么？
共识层最受关注的提案，是协议内提议者与构建者分离，也就是 ePBS（EIP-7732）。
先理解两个角色会更容易看懂这项提案。在以太坊出块流程中，通常可以分成两部分：一方负责决定采用哪个区块，也就是“提议者”；另一方负责把交易真正打包成区块，也就是“构建者”。
目前，这种分工并不是完全由以太坊协议本身直接规定的，而是依赖一套链下中继体系来协调。这意味着，在区块验证阶段会多出一层外部配合流程，验证者需要在比较紧张的约 2 秒窗口内完成交易广播和执行。这个限制，也在一定程度上压缩了网络可承载的数据规模。
ePBS 的核心思路，就是把“提议者—构建者”这套协作方式直接写进协议规则里，让区块交付和付款机制在链上原生完成，从而减少对第三方中间件的依赖。当然，如果参与方还需要协议没有覆盖的复杂功能，依然可以继续使用外部协调机制。
除此之外，ePBS 还重新设计了验证流程，把“谁来提议区块”和“区块有没有按时交付”拆开处理。这样一来，原本大约 2 秒的处理窗口，有机会延长到约 9 秒。对于普通读者来说，这意味着网络在传播更多区块数据时会更从容一些，也让以太坊未来承载更多面向 Layer2 的数据有了更大空间。
以太坊 Glamsterdam 升级头牌提案二：BALs 怎么提升执行效率？
执行层最核心的提案，是区块级访问列表，即 BALs（EIP-7928）。
要理解 BALs，先要知道当前以太坊为什么很多时候仍然偏向顺序执行交易。原因在于，系统在一笔交易真正执行之前，往往无法完全确定它会访问哪些状态数据，比如会动到哪些账户，或者读取、修改哪些合约存储。
如果事先不知道这些内容，系统通常只能按顺序逐笔执行交易。因为一旦两笔交易同时修改同一份状态数据，就可能发生冲突，影响执行结果的正确性。
BALs 的作用，就是让交易在进入执行流程前，先带上一份明确的访问列表，提前说明自己会读取或修改哪些状态对象。这样一来，系统就能先判断哪些交易之间不会互相影响，再把这些互不冲突的交易分组并行处理，而不是让所有交易都排队等待。
对于新手来说，可以把它理解为：系统先看“哪些任务彼此不抢资源”，然后让这些任务同时进行。这样做的直接好处，就是执行效率有机会提升。
这类访问列表还有一个重要价值：新节点在同步网络时，可以根据列表中记录的最终状态结果完成同步，而不一定要把所有历史交易从头到尾重新执行一遍，这有助于提升节点同步效率。为了让这套机制能在网络里顺利传输，Glamsterdam 还纳入了一项配套的传输协议升级，用于让节点之间共享这些访问列表。按当前进展，这项传输协议已经成为所有执行层客户端的强制要求。
配套提案：Glamsterdam 如何重新评估存储与读取成本
除了两项头牌提案之外，Glamsterdam 还包含两项与重新定价相关的配套提案，重点是重新评估网络中的“存储成本”和“读取成本”。
- 第一项，针对长期占用链上空间的操作重新计费。例如新建账户、部署合约等行为，会持续占用链上存储资源。过去这部分收费与实际空间占用并不完全匹配，新方案将按照占用空间重新计费，目标是把全网数据增长速度控制在每年 120 GiB 左右的安全且可预期范围内，以便普通硬件仍有机会持续运行节点。同时，这部分仓储成本会单独核算，不再与交易执行本身的计算费用混在一起。这样一来，开发者如果愿意承担更高的存储成本，仍然可以部署体量更大、逻辑更复杂的应用，而不必完全受制于统一的 Gas 上限。
- 第二项，调整读取链上数据的成本。过去，查询和读取已有链上数据的定价相对偏低，已经越来越难反映当前数据规模扩张后的真实读取成本。这次升级将上调相关操作码的费用标准，使其更接近现代硬件的实际负载情况，同时也有助于压缩利用低成本查询操作制造网络拥堵的空间。
以太坊 Glamsterdam 主网上线时间：目前仍未最终确定
从当前进度看，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 会议确认具体区块高度之前，外界更可能在第四季度甚至年底才看到这次升级真正落地。
对于以太坊生态来说，这类大型协议升级本身就通常伴随较长的测试和审查周期，因此后续进展仍应以开发者会议内容和测试网部署结果为准。
还需要注意的是，协议升级时间表本身具有动态调整空间。测试结果、客户端适配情况以及社区协调进度，都可能影响最终上线安排。关注以太坊 Glamsterdam 升级的用户，更适合持续跟踪后续开发者会议和测试网进展，而不是过早对具体上线时间作出确定性判断。对于普通用户来说，了解升级方向和核心机制，比单纯盯着某一个日期更有参考价值。
