Glamsterdam升级，以太坊的L1扩容方案

原创 | Odaily Planet Daily jk

即将推出的以太坊 Glamsterdam 升级被核心开发者视为自合并以来规模最大的协议级重构。其名称由两部分组成：执行层升级保留了“Amsterdam”，取自之前 Devconnect 活动的举办地；共识层升级则命名为“Gloas”，取自一颗恒星。继之前的 Fusaka 升级之后，Glamsterdam 通过重组网络处理交易和管理不断增长的数据库的方式，从根本上更新了以太坊创建和验证区块的方式，从而提升了 L1 的可扩展性。

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

• 加速处理（并行化）：重新组织网络记录数据依赖关系的方式，使其能够安全地同时处理大量事务，而不是缓慢地逐个处理。
• 可扩展性：将区块创建和验证的繁重工作负载分开，使网络有更多时间传播更大的数据量而不会减慢速度。
• 可持续性：调整网络费用，以准确反映存储新数据的长期硬件成本，清除未来提高 Gas 限制的障碍，同时避免硬件性能下降。

此次升级的两大主要提案分别集中在共识层和执行层：

有两个主要的 Headliner 提案。来源：以太坊

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

首先，我们来讨论共识层的重点提案，该提案将协议中的提议者和构建者分开，英文缩写为 ePBS (EIP-7732)。

以太坊每次生成区块实际上都包含两个步骤：一人负责“选择区块”（提议者），另一人负责“实际构建区块中的交易”（构建者）。目前，以太坊协议本身并未明确规定这种分工，而是依赖于一组链下“中介公司”（通常称为中继）来协助完成这一过程。这种链下关系也限制了区块验证的进程，迫使验证者在短短两秒内快速完成交易广播和执行，从而限制了网络能够处理的数据量。例如，这类似于一家餐厅，点餐和烹饪流程依赖于独立的外部联络人来协调菜肴的交付；如果这个联络人出现故障，厨房和前台就可能无法协调一致。

ePBS 的做法是将这种“下单-烹饪”的分工写入餐厅自身的运营手册，不再依赖外部联络人。因此，可信的链上区块交付和支付机制直接内置于协议本身，无需第三方中间件。然而，如果双方希望使用协议中尚未规定的复杂功能，他们仍然可以选择使用外部联络人。此外，为了防止“交付”阶段出现混乱，ePBS 设立了“菜品核查团队”，负责检查“谁下了单”以及“菜品是否按时完成”，从而将原本 2 秒的交付时间窗口延长至约 9 秒，使餐厅能够同时处理更多订单，这意味着以太坊可以容纳更多面向 Layer 2 的数据。

主打提案二：出发前准备“购物清单”

接下来，我们来讨论执行层的重点提案，即块级访问列表，简称 BAL（EIP-7928）。

目前，以太坊处理交易的方式有点像一个人闭着眼睛在超市购物：他必须先摸索商品，确认是什么，然后决定如何购买，这就迫使他一次只能处理一件商品。由于系统事先不知道交易会使用哪些数据（例如涉及哪些账户），因此必须严格按照顺序处理交易；否则，两笔交易可能会无意中尝试修改相同的数据（例如同一地址的余额），从而导致冲突。

BAL（访问列表）允许用户在出发前获取一份清晰列明“要去哪些货架以及要挑选哪些商品”的购物清单。有了这份清单，系统可以预先判断哪些交易不会相互冲突，从而将不相关的交易分组并行处理，而不是逐个排队。此外，这份清单还有一个额外的好处：当新节点加入网络时，它们可以直接复制清单中记录的最终结果，而无需重新计算所有复杂的历史交易，从而显著加快新节点的同步速度。为了方便这份清单在网络内流通，Glamsterdam 还打包了一个相应的传输协议升级，使节点能够共享这些访问列表，这现在已成为所有执行层客户端的强制性要求。

支持性提案：重新评估“空间占用”行动

除了这两项主要提案外，Glamsterdam 还提出了两项重新定价的支持性提案，可以理解为调整网络“存储费”和“查询费”的价格表。

• 第一项提案针对的是创建新账户和部署合约等会“永久占用”网络空间的操作。此前，收费与实际占用空间不成比例；现在，收费将基于“按占用空间单位收费”的方式重新计算，旨在将网络整体数据增长率控制在每年 120 GiB 的安全可预测水平，从而确保网络能够在普通硬件上持续运行。此外，这项存储费用将单独计算，不再与交易处理计算费用混在一起。只要开发者愿意支付略高的存储费用，他们仍然可以部署更大、更复杂的应用程序，而不会立即受到 Gas 总量的限制。
• 第二项提案针对的是查询和读取网络中现有数据等操作，这些操作此前定价过低，未能跟上数据量增长带来的实际查询成本。此次提案将提高这些操作代码的定价标准，使其更好地反映现代硬件的实际负载情况，同时防止个人利用低费率故意发送过多查询请求来阻塞网络。

主网上线日期：尚未确定

就时间线而言，Glamsterdam 目前正处于一个较为微妙的阶段。官方方面，执行层核心开发者（ACDE）最近一次可验证的会议是 7 月 16 日举行的第 241 次会议，主要议程包括 Glamsterdam 开发网阶段的最新进展以及为下一次升级 Hegota 选择核心提案。业内广泛引用的时间表显示，开发网阶段经历了从 0 到 7 的八个迭代，时间跨度从 2026 年 3 月 28 日到 7 月 8 日，之后是原定于 2026 年 8 月 3 日进行的 Sepolia 测试网分叉，以及原定于 2026 年 8 月 17 日进行的 Hoodi 测试网分叉，主网激活的目标日期定于 2026 年 9 月 16 日。

原计划于 2026 年上半年发布。来源：以太坊

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