Glamsterdam 的真正考验:以太坊重写区块生产与状态定价

以太坊标志悬于 Glamsterdam 三阶段迁移路径之上

Platåberget 让以太坊下一次升级从路线图概念变成了现实的运营问题。编辑部原创插图。

执行摘要

以太坊 Platåberget 测试网已经运行,其意义远不止一次例行的分叉彩排。该网络于 2026 年 8 月 13 日启动,并计划在 8 月 20 日的 epoch 1,536 激活 Gloas 分叉;它是首个专门承载 Glamsterdam 组合升级、可公开加入且预期长期运行的测试环境。以太坊基金会公告称,Platåberget 将持续数月,让社区在升级进入 Sepolia、Hoodi,最终进入主网之前主动测试并“破坏”软件。截至本报告截稿时,官方网络页面将其标记为 Active。

Glamsterdam 的主要组成部分单独看都很重要:协议内置的提议者—构建者分离(ePBS)把构建者市场的承诺与支付逻辑纳入以太坊共识;区块级访问列表(BAL)记录一个区块读取和改写的状态位置,为并行处理创造条件;一整套 Gas 重定价以约 2 亿 Gas 的底线为目标;独立的“状态 Gas”机制专门为永久状态创建计费;合约与初始化代码的容量上限也将显著提高。

这些改动并不是彼此无关的功能集合,而是在贯彻同一项策略:提高吞吐量,同时承认计算、永久存储和共识关键路径上的通信并非同一种资源。区块构建与区块提议被拆开,共识验证与执行验证在时间上被拆开,状态增长与一般执行被分别定价,状态访问关系也从事后推导变为显式数据。

本报告的核心判断是:Glamsterdam 不是简单的“更多 Gas”,而是一次运营模型重置。它把部分原本依赖行业惯例和中间件的风险纳入协议规则,同时把新的集成风险推向钱包、估算器、索引器、构建者和验证者软件。因此,机构不应以单一吞吐量数字或某个客户端成功过叉来判断准备度,而应检验整条技术栈能否协同工作。

为什么 Platåberget 值得此刻关注

一般的以太坊开发网很少构成机构级新闻。Platåberget 不同之处在于,它明确覆盖完整的区块生产链:验证者集合开放,测试验证者和构建者可以存款,多种执行层与共识层客户端可以参与,而且网络计划持续到 Glamsterdam 主网上线。它更像一个提前运行的协作场,而不是用完即弃的工程沙盒。

时间顺序也必须准确理解。测试网已经越过公告中预定的 8 月 20 日激活点,但主网路径仍以稳定性为前提。基金会称,吸收反馈并修复客户端后,还将启动一个“不终局”开发网,用于测试病理性共识场景。只有开发网稳定后,长期测试网 Sepolia 和 Hoodi 才会升级;两者稳定之后才轮到主网。公告和 Glamsterdam 元 EIP都没有给出主网日期。把测试顺序误读为固定发布承诺,会制造虚假的确定性。

flowchart LR
    A[Platåberget 公共测试网<br/>2026 年 8 月运行] --> B[收集反馈与修复客户端]
    B --> C[不终局开发网<br/>测试病理场景]
    C --> D[Sepolia 与 Hoodi 分叉]
    D --> E{多客户端及下游工具<br/>是否稳定?}
    E -- 否 --> B
    E -- 是 --> F[以太坊主网 Glamsterdam]

这种分阶段安排不是形式主义。Glamsterdam 同时改变共识层、执行层及两者之间的边界。某个验证者可能按本地实现完全正确,却在载荷时序、构建者支付或分叉选择上无法与其他客户端协同。某个应用仍然兼容 EVM,却因坚持“普通 ETH 转账永远是 21,000 Gas”而错误报价。某个数据服务能够解析区块,却遗漏已经移出传统区块体的状态信息。Platåberget 的价值正是让这些不一致在没有真实经济损失的环境中暴露。

第一项结构性变化:区块构建成为协议事务

目前,大多数以太坊提议者通过外部中继市场,把执行载荷的构建交给专业构建者。该模式让验证者更容易获得有竞争力的区块价值,但公平交换依赖中间件和极为紧张的时序。EIP-7732(当前仍明确标记为 Review)拟把这段关系的核心机制放入协议。

在 ePBS 下,构建者先承诺一个执行载荷及对应付款,信标区块包含签名报价,而不是完整载荷。构建者随后揭示载荷。由验证者组成的“载荷及时性委员会”证明正确的载荷与 Blob 数据是否及时到达;信标链登记的构建者余额让支付可以由协议执行。执行验证则被延后:共识部分先走完时间最敏感的传播路径,多数验证者可利用时隙中更长的余量核验执行与数据可用性。

sequenceDiagram
    participant B as 已质押构建者
    participant P as 信标区块提议者
    participant C as 共识网络
    participant T as 及时性委员会
    participant V as 验证者
    B->>P: 签名载荷报价与付款承诺
    P->>C: 发布包含报价的信标区块
    B->>C: 揭示执行载荷与 Blob
    T->>C: 证明载荷是否存在并及时到达
    C->>P: 协议核算构建者付款
    V->>V: 在延后的时限内验证执行

这个设计同时缓解多个瓶颈。完整载荷不再位于信标区块内,可减少共识关键路径上的数据量;延迟执行验证缓解当前见证截止前过于压缩的工作窗口;协议记账则降低构建者与提议者公平交换对可信中间件的依赖。这些都是扩大区块容量的前置条件:如果验证者无法及时接收和验证更大区块,单纯提高 Gas 上限只会增加漏签或重组风险。

但“内置”不等于消除构建者集中。专业构建者仍可能在订单流、网络延迟和优化能力上占优。EIP-7732 本身也列出未完全消失的安全权衡:理性构建者可能在有利可图时扣留载荷,形成只有信标区块而没有执行载荷的“空”时隙;委员会双签采用了有意简化的处理;由于不同节点可能看到不同的载荷可用状态,分叉选择规则必须大幅调整。该提案仍处于同行评审,恰恰因为协议将接手过去位于边缘系统的责任。

对运营验证者的机构而言,责任边界扩大了。构建者存款、载荷可用性、新消息类型和延迟验证都进入日常保障范围。监控系统必须区分“整个时隙跳过”和“信标区块出现但承诺载荷未到达”。单一的“节点在线”指标已经不足以描述区块生产健康度。

协议化区块生产与执行经济学的双面板比较

Glamsterdam 把共识关键路径改革与更明确的执行、状态成本模型放在同一次升级中。编辑部原创插图。

第二项结构性变化:扩容,但不补贴状态膨胀

执行层方案很容易被过度简化。称以太坊“准备把 Gas 提到约 2 亿”,听起来像是把现有费率表同比放大;真实逻辑正相反:先对各类操作重新定价,使总 Gas 上限更接近安全资源消耗,再对永久状态施加专门保护。

EIP-8007是 Gas 重定价组合的协调文件,涵盖操作码、交易固有成本、状态访问、预编译、日志、Calldata、合约大小与状态创建等改动。“约 2 亿”是这一组合希望支撑的资源目标,不代表所有工作负载都能线性扩张,更不代表费用会同比下降。

对应用影响最直接的是 EIP-8037。它按固定的“每状态字节成本”,在运行时对创建永久状态的操作计费。创建账户、部署代码、首次写入存储槽都可能消耗状态 Gas。基金会特意强调了一个会打破旧认知的例子:按照拆分后的成本结构,向已经存在的账户转 ETH 仍是 21,000 Gas;向此前不存在的地址转账,则需要额外支付新账户状态费用。“转账等于 21,000”不再是普遍真理。

这一区分有重要的经济学基础。计算随交易结束,永久状态却必须由未来的节点持续存储、同步和读取。如果只提高总 Gas 上限而不改善状态定价,短期交易容量会变成长期硬件负担,进而推动节点集中化。Glamsterdam 的答案是同时承认两个事实:每个区块可以处理更多工作,但创建永久共享状态仍必须足够稀缺,才能维护普通参与者运行节点的可能性。

EIP-7928通过区块级访问列表补充这一模型。BAL 描述区块触及的账户、存储位置及执行后的变化,并与传统区块体分开交换。显式访问关系可以帮助客户端提前读取状态、并行访问磁盘并更好地理解交易依赖。不过,它也增加了一项共识关键数据:网络层、存储层、RPC 与索引系统都必须一致地传输和解释它。

EIP-7954把已部署合约上限从 24 KiB 提高到 64 KiB,把初始化代码上限从 48 KiB 提高到 128 KiB。这为复杂应用释放了可见空间,但不等于复杂性免费。更大的合约会增加代码状态体积,也会改变部署、验证与安全分析的工作量;只有放在整体重定价框架内,这一放宽才具备资源上的合理性。

改动

预期收益

新的运营问题

ePBS

降低构建者—提议者交换的信任要求,延长验证时间

构建者、验证者和监控系统能否就载荷可用性与付款状态达成一致?

区块级访问列表

为预取和并行执行创造条件

客户端与数据系统能否可靠传输、验证这项新数据?

Gas 重定价

让 Gas 上限更接近真实安全资源消耗

哪些应用与工具仍内置旧上限或旧操作码成本?

状态 Gas

显式约束永久状态增长

钱包和估算器能否识别创建新状态的转账或调用?

更大合约上限

为复杂应用增加空间

部署、验证和安全工具能否处理更大的对象?

下游影响范围

基金会使用了少见的直白措辞:任何依赖硬编码最大 Gas 上限的工具都会失效,并明确点名钱包、索引器与 Gas 估算器。风险并不限于提交超大交易的软件。固定上限还可能藏在输入校验、数据库字段、模拟超时、仪表盘、费用启发式规则、反欺诈控制和第三方 API 合同中。

新的状态维度使估算结果取决于执行前状态。两个界面上完全相同的转账,可能因为收款账户是否已经存在而需要不同资源;一次合约调用的成本,也可能取决于存储槽是否首次写入。估算器必须模拟相关前置状态,不能套用熟悉的常数。账户抽象打包器、托管策略引擎和批量付款系统尤其值得审查,因为低估成本可能导致整个交易包或运营批次失败。

索引器面对的是另一类问题。BAL 与区块体分开保存,并通过更新的执行层点对点协议传播。如果系统把传统区块体当成完整记录,它可能“在线”却在语义上不完整。数据供应商应明确说明产品是否提供访问列表和状态变化信息、延迟载荷验证时如何处理重组,以及共识视图和执行视图之间提供何种一致性保证。

验证者与构建者的测试也不能只覆盖成功区块,还应包括载荷晚到、载荷缺失、节点对载荷看法不一致、构建者余额耗尽、分叉边界附近重启客户端,以及访问列表数据丢失。基金会计划中的不终局开发网尤其关键,因为普通的可用性测试无法近似对抗性的分叉选择环境。

反方观点与尚未解决的风险

最有力的反对意见是复杂度。以太坊把新的区块生产制度、广泛的执行重定价和新数据结构放进同一阶段;每一项单独都可能合理,但相互作用扩大了测试面。更简单的分叉确实能降低协调风险。问题在于,扩容本身就带来耦合约束:更大区块压缩时序、增加状态压力,并放大专业构建者优势。只改 Gas 上限只是把这些问题推迟。

第二项质疑是 ePBS 可能固化当下的构建者市场。协议承认构建者这一角色,会强化专业化并提高未来重构成本。EIP-7732 允许提议者自行构建,但形式上的中立并不保证经济竞争力。因此,测试指标不应只有协议是否正常运行,还应观察构建者参与度和载荷集中度。

第三,显式状态定价可能给用户带来难以理解的波动。新收款地址比旧地址更贵,在资源层面合理,在产品层面却陌生。如果钱包不能解释或预留差额,正确的经济机制会转化成失败交易和客服事件。更好的协议记账不会自动带来更好的用户体验。

最后,所有重要规范仍可能变化。元 EIP 才是纳入范围的权威追踪文件,各组件 EIP 即使已有公开实现也可能继续处于 Review。Platåberget 证明这些代码路径可以公开运行,但并未证明经济安全性、消除客户端缺陷,也不保证某个日期一定进入主网。

对机构的含义

机构的正确反应不是预测某个手续费数字,而是重画保障边界。资管人与企业财资应询问托管商:交易模拟如何处理新账户和首次存储写入成本。交易所应分别测试向新旧地址批量提币。RPC 与数据采购方应要求供应商给出明确的 Glamsterdam 兼容声明。验证者运营方应在事故分类中加入构建者状态和载荷状态。智能合约团队则应重新检查部署、源码验证和 Gas 预算护栏。

风险委员会还应明确区分三个里程碑:规范入选、公共测试网互操作、生产就绪。某功能进入 Platåberget 是工程成熟度证据,但不是主网承诺。反过来,等主网日期公布才测试同样危险,因为当前分阶段路线的目的正是尽早发现下游假设。

结论

Platåberget 让以太坊的扩容策略变得异常清晰。Glamsterdam 并没有把 Gas 上限当作简单的音量旋钮,而是重构谁来承诺区块、何时验证执行、如何披露状态依赖,以及永久状态究竟应付出什么成本。如果成功,以太坊有望在改善共识关键路径与资源定价真实性的同时显著提高容量。

代价是“准备就绪”的定义扩大了。执行层和共识层客户端平稳过叉是必要条件,却远远不够:钱包必须正确估算状态敏感型交易,索引器必须摄取新数据,构建者与验证者必须在延迟载荷验证下协同,监控系统必须描述各种部分失败状态。把这看成一场系统迁移,并跨软件和组织边界测试的机构,会比只等待主网标题日期的机构更有准备。

直接来源

研究截点:2026 年 8 月 25 日 UTC。测试网状态与规范仍可能变化,任何生产决策前均应重新查阅所链接的官方追踪页面。