以太坊 Glamsterdam 的关键赌注：扩容的不是区块，而是整条处理流水线

Glamsterdam 将验证时间、执行可见性与状态增长三项约束纳入同一扩容方案。本报告原创编辑插图。

研究日期：2026 年 8 月 21 日

执行摘要

计划于 2026 年第四季度实施的以太坊 Glamsterdam 升级，不应被简单理解为又一次提高网络容量。更准确地说，它在重构支撑更高容量所必需的底层机器：只有当验证者获得更长的检查时间、客户端能够预先看见一批交易会触碰哪些状态，而制造永久状态的用户支付更接近长期硬件负担的价格时，大幅提高 L1 吞吐量才真正可信。因此，协议内置提议者—构建者分离（ePBS）、区块级访问列表（BAL）与状态成本重定价并非随意拼接的功能，而是相互依赖的三道控制机制。

这种区分对机构尤其重要。提高 gas limit 可以迅速增加区块空间供给，但若传播、执行与存储机制不变，也会同时放大漏签、重组与节点硬件压力。Glamsterdam 的选择是先解决这些瓶颈，再为后续容量提升创造条件。以太坊官网将其目标概括为并行化、扩大容量和抑制数据库膨胀，并把时间窗口更新为 2026 年第四季度。以太坊基金会的工程进展则披露：团队已经形成可信的 Glamsterdam 后 2 亿 gas 下限目标，几乎所有客户端都跑通了外部构建者端到端流程，状态重定价参数也已在互操作活动中确定。需要强调：这些是工程目标与测试里程碑，不是主网上线即兑现的吞吐量承诺。

潜在收益十分可观。ePBS 将完整执行验证移出每个 slot 最紧张的早期阶段；BAL 把状态依赖显式化，为并行磁盘读取、更快同步以及最终的并行执行提供基础；状态重定价则让永久数据库占用得到更明确的计量。代价也同样真实：出块协议更复杂，构建者成为协议原生角色，部分创建状态的操作会显著变贵，而多客户端实现成熟度仍是上线门槛。审慎的判断既不是“Glamsterdam 已经解决扩容”，也不是“提高 gas limit 必然导致中心化”，而是观察这三条支柱能否同步成熟。

核心论点：容量首先是系统工程问题

以太坊基础层长期采用顺序执行，并要求验证者在很窄的投票窗口里完成多项重任务。若不改变这条流水线就提高 gas limit，就像扩大工厂进料口，却不扩建质检与仓储：更多订单能够进入，但安全产能仍由最慢的下游环节决定。

Glamsterdam 将三种资源分别处理。第一是时间：验证者接收与检查 payload 的时间有多长。第二是信息：客户端能否事先知道区块访问了哪些账户和存储槽。第三是持久性：一个区块给所有全节点数据库永久增加多少状态。升级方案试图让这三项原本隐性的约束变得可观察、可计量、可管理。

flowchart LR
    A[L1 需求上升] --> B{三项瓶颈}
    B --> C[验证窗口过短]
    B --> D[执行依赖不透明]
    B --> E[永久状态持续增长]
    C --> F[ePBS 分离承诺与载荷]
    D --> G[BAL 记录被触碰的状态]
    E --> H[按物理占用重定价状态创建]
    F --> I[容量提升更可信]
    G --> I
    H --> I
    I --> J[提高 gas limit 并约束节点压力]

这一系统视角也能纠正最常见的误读：Glamsterdam 并不会让每一种交易立刻变便宜。官网称，另一个降低交易固有 gas 的提案，可能让既有账户之间的简单 ETH 转账成本最高下降 71%；BAL 与 ePBS 则为后续容量增长做准备，若供给增加，拥堵成本可能随之下降。与此相反，创建账户、存储槽和合约代码的操作会被主动提高价格。所以，“费用下降”是一个过度粗糙的结论。设计者真正追求的是：丰富的短期资源更便宜，稀缺且长期占用的资源得到更准确的定价。

ePBS：购买时间，并移除关键路径上的信任中介

目前，区块提议者通常通过协议外基础设施，把执行 payload 的构建外包给专业构建者。提议者先签署盲化区块，中继软件则帮助完成“构建者 payload 换取付款”的交换。这一市场对以太坊经济十分重要，但它把受信任中间件放进关键路径，也让验证者只能在数秒内完成共识、执行与数据可用性检查。

EIP-7732 把这套市场机制纳入协议。提议者在初始信标区块中放入构建者签名的报价与承诺，而不是完整执行 payload；构建者随后揭示 payload；载荷及时性委员会（PTC）报告其是否按时到达、相关数据是否可用。构建者在信标状态中的资金使付款能够由协议强制执行，不再完全依赖中继保证公平交换。

真正具有扩容意义的是时间结构的变化。EIP 指出，普通验证者当前要在四秒投票截止前同时处理共识与执行。延迟验证后，下一名提议者约有六秒，其他验证者约有九秒检查执行 payload。Glamsterdam 官方说明则把传播窗口概括为从约两秒扩大至约九秒。两组数字描述 slot 的不同区段，但结论一致：重型执行工作被移出共识最敏感的热路径。

sequenceDiagram
    participant B as 质押构建者
    participant P as 区块提议者
    participant V as 验证者
    participant T as 及时性委员会
    B->>P: 签名报价与载荷承诺
    P->>V: 发布含承诺的信标区块
    V-->>V: 优先验证共识部分
    B->>V: 揭示执行载荷与数据
    T->>V: 证明载荷按时可用
    V-->>V: 在更长窗口内验证执行
    V->>V: 延长链或拒绝无效载荷

对机构用户而言，这不只是验证者性能优化。更宽裕的传播和验证预算，意味着网络可承载更大的 payload 与更多 blob，同时不必让地理位置或计算能力较弱的验证者以同样速度增加漏签。协议内付款也减少了一类中继信任。不过，ePBS 不会自动消除构建者集中。搜索算法、订单流、延迟和资本仍可能让大型构建者占优；将构建者写入协议改变的是市场规则，不必然改变市场结构。EIP-7732 还引入完整、跳过、空载荷等新的 slot 状态和委员会行为。正因为状态机变复杂，多客户端故障测试比一个醒目的吞吐量数字更重要。

BAL：把执行过程变成可观察的依赖图

以太坊不能因为服务器有多个 CPU 核心，就任意并行处理交易。两笔交易可能读写同一个账户或存储槽，顺序不同会导致结果不同。客户端只有先拿到可靠的依赖图，才能把互不冲突的工作安全地分配到不同线程。

EIP-7928 要求每个区块携带区块级访问列表，描述实际访问的地址和存储位置，连“读取但未修改”的状态也必须记录。于是，区块的工作集从隐性信息变为显式数据。官方路线图把 BAL 的用途概括为更快同步、并行磁盘读取和未来的并行执行。近期最现实的收益可能没有“完全并行 EVM”那么醒目，但仍很有价值：客户端可以预取状态，并在依赖允许时把交易分组并行处理。

这些信息并非没有成本。EIP 附带的一项实证分析抽取了 100 个历史主网区块；在包含读取项的情况下，压缩后 BAL 的中位数大小为 42.6 KB，第 95 百分位为 73.7 KB，存储读写合计占压缩体积的 85.3%。这只是有限历史样本，不能外推为 2 亿 gas 区块的预测，但它清楚展示了交换关系：网络多传一些字节，以换取对执行过程的明确认知。另一项 EIP-8146 提案还在探索把 BAL 放入 sidecar，避免其占用执行 payload 的关键传播路径。

三项能力呈乘法关系：增加验证时间，只有在执行工作可见、永久增长受约束时，才会转化为可持续容量。

BAL 同时扩大了共识表面：构建者必须生成正确列表，客户端必须验证，列表体积也必须有上限。EIP-7928 把记录项数量与区块 gas limit 绑定，而不是允许元数据无限增长。这体现了 Glamsterdam 反复采用的设计模式：先把隐藏资源显性化，再对其计量。

状态重定价：扩容方案的可持续性支柱

吞吐量与状态增长不是同一件事。一次兑换主要消耗当下的计算与带宽；一个新账户、存储槽或合约，却可能无限期增加每个节点的数据库负担。如果二者都挤在粗糙的单一 gas 价格表中，那么提高 gas limit 即使能加速瞬时执行，也可能让永久状态更快膨胀。

EIP-8037 提议设立统一的“每状态字节成本”，并把状态创建单独计量。模型采用每状态字节 1,530 gas，基于 1.5 亿参考 gas limit，以及平均半满条件下每年 120 GiB 状态增长的设计目标推导。这个数字是模型输入，不是结果保证。在区块完全用满的极端假设下，EIP 给出的模型范围从 1 亿 gas limit 时每年 80 GiB，到 3 亿时每年 240 GiB。

成本分布的变化是有意为之。EIP 估计，新账户的状态 gas 部分将从 25,000 提至 183,600；新存储槽从 20,000 提至 97,920；部署 24 kB 合约则从约 495 万提至约 3,778 万，且还可能叠加执行 gas。这些仍是提案参数，上线前可能继续调整，但政策方向非常明确：给所有节点留下长期数据库足迹的用户，应承担更多相应成本。

这会改变应用经济模型。频繁创建存储、部署合约或通过新账户拉新的协议，若不做批处理、复用存储或迁往采用不同费率的 rollup，名义 gas 支出将明显上升。与此同时，降低固有 gas 的提案可让既有账户间的简单转账更便宜。Glamsterdam 实际上在用价格信号鼓励“复用状态、减少扩张”，这既是费用调整，也是架构导向。

证据能够证明什么，又不能证明什么

当前最有力的证据是实现进度。以太坊基金会 2026 年 5 月协议更新称，多客户端 devnet 已经在几乎所有客户端上跑通外部构建者流程；团队还就 Glamsterdam 后可信的 2 亿 gas limit 下限达成一致，并完成重定价参数。8 月 6 日更新的官网页面则把目标时间明确为第四季度，并列出多项正在 devnet 测试的 EIP。Forkcast 决策追踪器仍是跟踪全体核心开发者会议决定与规格变动的最佳公开索引之一。

但这些材料不能证明主网会在某个确定日期激活，也不能证明验证者会立即把 gas limit 投票提高到 2 亿，更不能证明交易吞吐量会线性增长。以太坊升级需要客户端发布、测试网验证、规格冻结与节点运营者准备。gas limit 本身也是验证者参与调整的参数，而非硬分叉单方面写死的常量。机构规划应区分四个里程碑：EIP 正式纳入、通过多客户端互操作、主网激活，以及激活后验证者逐步采用更高上限。

flowchart TD
    A[EIP 范围与规格确定] --> B[多客户端开发网]
    B --> C{故障与负载下是否稳定}
    C -- 否 --> B
    C -- 是 --> D[测试网激活]
    D --> E[确定主网分叉计划]
    E --> F[主网激活]
    F --> G{验证者是否提高 gas limit}
    G -- 逐步提高 --> H[观察真实容量与费用效果]
    G -- 暂不提高 --> I[架构已启用但容量不变]

对机构与生态的含义

对资产管理机构而言，Glamsterdam 强化了这样一种叙事：以太坊正在追求 L1 扩容，但没有放弃普通硬件运行节点的约束。这一点具有战略意义，因为区块空间增加会分别影响费用收入、ETH 销毁、质押经济与 rollup 结算需求。更多 L1 供给可能降低单笔交易的拥堵租金，却也可能提高全网结算量；仅凭容量无法推导净货币效应。

对验证者与质押服务商而言，运营准备是近期重点。ePBS 引入构建者注册、payload 时序以及新的分叉选择行为；即便协议留出更多验证时间，更大区块依旧会增加带宽与执行压力。评估不能只看平均负载，而要看恶劣网络条件下的尾部延迟、少数客户端表现与故障恢复。

对应用团队而言，新价格梯度可能比总 gas limit 更重要。状态密集型设计需要重新建模；复用既有状态的支付和应用则可能同时受益于更低固有 gas 与更大容量。更长验证窗口也可能支持更高 blob 预算，使 rollup 受益，但 Glamsterdam 并不是 L2 扩容的替代品。它改善的是 rollup 所依赖的结算层。

对区块构建者和 MEV 基础设施而言，协议内置会改变接口与结算保证，减少中继信任并统一准入方式；但优质订单流与优化算法带来的竞争优势依然存在。升级后持续监测构建者份额，才能判断协议开放是否真的带来更可竞争的市场。

风险、反方观点与观察指标

第一项反方观点是：复杂性本身就是去中心化成本。ePBS 加入质押构建者、及时性证明与异步 payload；BAL 增加数据与验证；多维状态计量增加估算难度。一个理论上更安全的高容量设计，如果最终只有少数团队能够可靠实现、运营或审计，仍可能偏离去中心化目标。

第二，重定价可能把活动赶走，而不是促使其提高效率。常见状态创建操作的状态 gas 提升五至八倍，会冲击链上游戏、账户工厂或不可避免产生状态的协议。低 base fee 或许能缓冲法币成本，但低费率并无保证。钱包与 RPC 服务必须更新估算逻辑；EIP 还特别提示，某些依赖预签名确定性部署交易的新网络需要处理兼容问题。

第三，显式依赖不等于立即实现并行执行。BAL 的生成、传输与验证都有开销；实际客户端提速取决于工作负载与具体实现。机构应关注接近生产环境区块的基准测试，包括极端 BAL 大小与重组条件下的行为。

最后，“2 亿”很容易成为误导性焦点。它是基金会工程团队报告的升级后可信下限，不是主网激活当天承诺的容量。更可靠的领先指标包括：devnet 上的客户端多样性、故障注入结果、测试网稳定性、家用节点资源占用、构建者集中度、漏签率，以及重定价后的实际状态增长。

结论

Glamsterdam 的真正重要性，在于它构建了一套相互制约的扩容架构：ePBS 创造时间，BAL 创造可见性，状态重定价则为持久性建立预算。任何一项单独存在都不够。只有更长窗口而没有依赖信息，执行仍然串行；只有并行化而没有状态纪律，数据库会更快膨胀；只有重定价而没有容量改善，则只是单纯提高成本。

截至 2026 年 8 月 21 日，项目已经越过纯纸面设计阶段：核心功能运行在多客户端环境中，公开目标指向第四季度，工程团队也提出通往升级后 2 亿 gas limit 下限的可信路径。但“可信”并不等于“必然”。机构级结论必须附带条件：如果多客户端测试证明三项控制机制在对抗性负载下能够协同工作，Glamsterdam 可能成为以太坊转向权益证明以来最重要的 L1 扩容升级；如果其中任何一项因复杂性或协调问题延迟，那么推迟容量提升，远比把更大区块本身当作成功更审慎。

直接资料来源

• Ethereum.org：Glamsterdam 概览，2026 年 8 月 6 日更新

• 以太坊基金会：2026 年 5 月协议集群进展

• 以太坊基金会：Soldøgn 互操作活动回顾

• EIP-7732：协议内置提议者—构建者分离

• EIP-7928：区块级访问列表

• EIP-7928：BAL 大小实证分析

• EIP-8037：状态创建 gas 成本提升

• Forkcast：核心开发者关键决策追踪