撰文：imToken 以太坊下一次大规模升级，已经进入冲刺阶段。 按照当前的以太坊官方路线图，Glamsterdam 升级计划于 2026 年下半年正式上线主网，截至 6 月底也进入开发者网络最终测试阶段，正围绕多客户端开发网，持续测试内置 PBS、区块级访问列表和 Gas 重新定价等核心功能，不过具体激活时间尚未最终确定。 与此同时，在各大社交媒体上，讨论度最高的无疑是升级后「主网冲击 10000 TPS」这样直观的性能叙事，但在此之外，本次升级对以太坊的区块生产流水线和执行引擎进行了脱胎换骨式的重构，其改动之深、波及面之广，被开发者社区普遍誉为「自 The Merge（以太坊合并）以来最大规模的升级」。 那么，这个名字听起来有点酷炫的 「Glamsterdam」（由共识层升级 Gloas 与执行层升级 Amsterdam 组合而成），究竟改了什么？它将如何告别过去的痛点，又会给我们的日常链上体验带来哪些颠覆性的变化？ 一、为什么它是「Merge 以来最大规模的升级」？ 如果说此前的 Dencun 和 Fusaka 升级主要在为 L2 的数据可用性（Blob）铺路，那么 Glamsterdam 则是将重心重回 L1，掀起了一场 L1 性能与架构的大修。 这其实也是以太坊如今「让 L1 再次伟大」最真实的底层写照，那就是怎样让 L1 容纳更多交易，同时不让运行节点的成本和网络的中心化风险一起上升。 不过对于普通用户而言，历届以太坊升级通常会被简化为一个最直观的问题：Gas 会不会更便宜？吞吐量会不会更大？但说实话，即将到来的 Glamsterdam 很难只用简单的「降费」或者「扩容」来概括。 总的来看，这次升级涉及以太坊底层的多个关键环节，包括区块由谁构建、交易如何执行、节点如何读取和同步状态，以及不同链上操作应该支付多少 Gas，等于是要重新设计以太坊生产和处理区块的基础范式，且按照目前披露的技术细节，最值得关注的核心变化主要集中在三个方面： 内置 PBS（ePBS）：重构区块提议者与构建者之间的博弈关系，消除外部中继依赖； 区块级访问列表（BALs）：给交易执行提前画好地图，为并行处理和更快的节点同步铺路； Gas 重新定价：引入更精准的资源计费模型，控制高吞吐量环境下的状态膨胀； 首先，要理解内置 PBS，需要知道以太坊上的区块目前并不一定由 Proposer 亲自提交。尤其是在当前的 MEV-Boost 架构下，绝大部分 Proposer 会把收集交易、排列顺序和寻找 MEV 收益的工作，外包给专业的区块 Builder，而 Proposer 则主要负责从多个候选区块中选择报价最高的一个提交给网络。 这种「Builder 负责组装，Proposer 负责提交」的分工，就是 PBS（Proposer-Builder Separation）。 只不过问题在于，当前这套机制并没有被完整写入以太坊的底层协议——Proposer、Builder之间必须通过协议外的第三方软件以及 MEV-Boost Relay 服务来完成区块报价、内容交付和付款。 那就意味着 Relay 既要确保 Builder 最终公开完整区块，又要避免 Proposer 提前偷看区块内容后「黑吃黑」拒绝付款，因此承担了脆弱且中心化的「可信中间人」角色。 而 EIP-7732 提出的 ePBS（Enshrined PBS）正是为了解决这一痛点，它准备将这套博弈关系直接纳入以太坊的共识协议本身，直接取消第三方中继，使 Builder 成为协议原生识别的参与者，先提交区块承诺和报价，协议自动锁定相应付款，再由专门的「负载及时性委员会（Payload Timeliness Committee）」判断 Builder 是否按时公开了执行负载。 那就能将共识区块和执行负载的部分处理过程拆开，使执行负载的传播与处理窗口从大约 2 秒延长至约 9 秒。这几秒钟看似不多，对以太坊扩容却非常关键——意味着节点能够获得更多时间，接收和处理更大的区块以及更多 Blob 数据，从而为进一步提高 Gas Limit 腾出空间。 其次，Glamsterdam 在执行层的另一项核心突破，是 EIP-7928 提出的区块级访问列表（BALs，Block-Level Access Lists）。 众所周知，目前以太坊节点在拿到一个区块之前，并不能直接从区块中获知每笔交易将读取哪些账户、访问哪些合约存储，又会修改哪些状态，而是通常需要在执行交易的过程中，才逐步发现这些数据依赖。 这就像进入一座大型仓库取货，却没有完整的货物位置清单，工作人员只能一边寻找，一边处理，因此为了避免两个人同时修改同一批库存，大量工作必须严格按照固定顺序（单线程串行）完成。 而区块级访问列表（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 Token 转账通常会产生标准化的 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 更广阔的费率下降空间，或许都将深深受益于 Glamsterdam 在 2026 年下半年为以太坊重新铺设的这套地基。