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