BAL(EIP-7928)在 Glamsterdam 讨论中常被称作“并行执行前置条件”,含义并不是立刻让所有事务并行,而是先把状态访问关系从隐式假设变成可验证的显式约束。只有约束清晰,调度才有稳定基础。
这一约束层与 Glamsterdam 升级全景 中的升级目标直接相关,并与 ePBS(EIP-7732)机制 形成互补:ePBS 处理出块协作边界,BAL 处理执行约束边界。Glamsterdam 对 DApp 的影响 进一步说明约束层变化如何传导至应用性能预期与发布节奏。
BAL 对应区块级访问列表(Block-Level Access Lists),用于记录某区块执行过程中访问的账户与存储位置,并可包含执行后的状态结果信息。其设计目标不是替代执行引擎,而是给执行引擎提供更早、更明确的冲突判断与数据准备输入。
传统串行执行的优势在于一致性简单,但在高负载下效率上限明显。要走向并行执行,首先要回答“哪些事务会互相冲突”。BAL 的价值在于把冲突识别从执行中发现,前移到可规划的前置判断。据 Ethereum.org 路线图 与 EIP-7928,BAL 被列为 Glamsterdam 阶段关键提案之一。
当区块内容越来越复杂,状态读写关系如果只在运行时动态揭示,客户端很难提前规划执行路径。这样即便硬件资源充足,也可能因为冲突回退和重复调度导致实际效率不稳。
block-level access lists 的意义是降低“执行时才知道冲突”的概率。执行前有了更明确约束,客户端可进行数据准备、任务拆分与冲突隔离,减少随机抖动。对索引服务、归档节点等重度状态读取角色,访问关系前置也有助于优化 I/O 规划。
| 执行阶段 | 无前置约束 | 有 BAL 约束 |
|---|---|---|
| 冲突发现时机 | 执行中回退 | 执行前预判 |
| 数据准备 | 临场加载 | 可提前分组 |
| 调度策略 | 经验驱动 | 规则驱动 |
上表说明 BAL 改变的是“信息可得性”,而非单独决定最终吞吐数字。
客户端可依据访问列表做两类决策:一类是“可并行集合”划分,另一类是“必须串行路径”保留。这样即便不能全面并行,也能先把低冲突部分提效,逐步扩大可并行范围。
从工程落地看,BAL 带来的不是单次峰值突破,而是执行行为可预测性提升。对节点运维团队而言,可预测性往往比短期峰值更有价值,因为它直接影响 SLA 与异常响应。测试网数据中的冲突率、回退率变化,是评估 BAL 效果的重要参考。
| 调度阶段 | 无前置约束时 | 有 BAL 约束时 |
|---|---|---|
| 执行前准备 | 依赖经验估计 | 可按访问关系预分组 |
| 冲突处理 | 运行时频繁回退 | 冲突可提前隔离 |
| 结果稳定性 | 波动较大 | 预期更可管理 |
| 运维监控 | 难定义阈值 | 可建立结构化指标 |
图 1. BAL 机制示意:区块级访问列表如何支持冲突识别与并行执行调度。
BAL 不是并行执行的“替身”,而是并行执行的“前提层”。并行执行还需要客户端实现、调度策略、状态管理等多个环节协同。没有前提约束,强行并行通常会放大不确定性。
更准确的表述是:BAL 让并行执行从概念讨论变成可工程化推进的任务。它回答的是“先决条件是否具备”,而不是“最终性能已经达成”。后续若引入更激进的并行策略,BAL 提供的访问约束仍是冲突治理的基础输入。
开发者需要更关注状态访问模式。高频写入同一状态、跨合约复杂依赖、批量事务耦合等设计,可能在新约束下表现出不同执行特征。应用上线前应补充执行路径测试,而不是只看功能正确性。
产品团队也应调整性能沟通口径。升级后用户体验改善不一定线性发生,尤其在生态尚未充分适配时。更稳妥的做法是使用分阶段指标:确认稳定性、失败率、延迟分位数,而不是只宣传平均值;指标重设与灰度发布仍应与应用适配框架保持一致。
第一类挑战是跨客户端实现一致性。不同执行客户端对访问列表解析与调度策略可能存在细节差异,需要通过测试网对比与跨客户端回归持续收敛,并保留带时间戳的指标快照。
第二类挑战是生态理解成本。开发团队若忽视状态访问结构,可能在升级后出现性能偏差;历史合约也未必按访问友好模式编写,迁移与适配需要工具与周期。
第三类挑战是监控体系更新。运维团队需要新增与访问约束相关的观察指标,才能判断问题属于数据准备、调度冲突还是执行引擎瓶颈。没有监控升级,机制价值难以完全释放。对 节点升级准备清单 而言,BAL 相关日志与冲突回退率应纳入验收项;在 Glamsterdam 与 Dencun/Fusaka 对比 的框架下,这类挑战属于结构层变更特有风险,不宜用容量升级经验简单套用。
BAL(EIP-7928)解决的是执行秩序问题:把状态访问关系前置、把冲突识别结构化、把调度决策从临场反应推进到可验证规划。它不会单独定义升级成败,但会决定并行执行能否稳定落地,是 Glamsterdam 执行层的核心约束机制之一。
不是。BAL 是并行执行的前置约束层,提供冲突识别基础。并行执行还依赖客户端实现与调度策略等配套能力。
因为它把状态访问关系提前显式化,客户端能更早做数据准备与任务分组,减少运行时冲突回退,从而提升执行稳定性。
ePBS 关注出块协作边界,BAL 关注执行约束边界。两者分别作用于不同层,在 Glamsterdam 中形成互补。
优先审查状态访问模式与高频交易路径,补充升级前后执行行为测试,并更新性能监控与告警阈值,避免沿用旧执行假设。
不能。BAL 提供冲突识别与调度输入,但高冲突交易仍须串行。并行范围取决于访问模式、客户端实现与网络负载特征。





