BAL (EIP-7928) is frequently described as the "precondition for parallel execution" in Glamsterdam discussions. This term does not imply that all transactions will be executed in parallel immediately; rather, it means that state access relationships are shifted from implicit assumptions to verifiable, explicit constraints. Only when these constraints are clearly defined can stable scheduling be achieved.
This constraint layer is directly tied to the upgrade objectives described in the Glamsterdam Upgrade Overview and complements the ePBS (EIP-7732) mechanism: ePBS addresses the boundaries for block production collaboration, while BAL defines the boundaries for execution constraints. Glamsterdam's Impact on DApps further illustrates how changes at the constraint layer influence both application performance expectations and release cadence.
What Is BAL (EIP-7928)?
BAL stands for Block-Level Access Lists, which record the accounts and storage slots accessed during block execution and may also include post-execution state results. The goal is not to replace the execution engine, but to provide it with earlier, clearer conflict detection and data preparation inputs.
Traditional serial execution offers simple consistency but quickly hits efficiency limits under heavy load. Achieving parallel execution first requires answering the question: "Which transactions conflict with each other?" BAL’s value lies in moving conflict detection from runtime into a plannable, pre-execution phase. According to the Ethereum.org roadmap and EIP-7928, BAL is a key proposal for the Glamsterdam upgrade.
Why Does Ethereum Need Block-Level Access Lists?
As blocks become more complex, if state read/write relationships are only revealed dynamically at runtime, clients struggle to plan execution paths in advance. Even with ample hardware, efficiency can suffer due to rollback conflicts and repeated scheduling.
Block-level access lists reduce the likelihood of "discovering conflicts only at execution time." With clearer constraints up front, clients can prepare data, split tasks, and isolate conflicts, minimizing random performance fluctuations. For roles like indexing services and archive nodes that perform heavy state reads, advance knowledge of access relationships also helps optimize I/O planning.
| Execution Stage |
Without Pre-Constraints |
With BAL Constraints |
| Conflict Detection Timing |
Rollback during execution |
Pre-execution prediction |
| Data Preparation |
On-the-fly loading |
Pre-grouping possible |
| Scheduling Strategy |
Experience-driven |
Rule-driven |
This table demonstrates that BAL changes the "availability of information" rather than solely dictating final throughput.
How Does BAL Help Clients Identify Conflicts and Optimize Scheduling?
Clients can use the access list to make two key decisions: dividing transactions into "parallelizable sets" and retaining "must-be-serial paths." Even if full parallelism isn't possible, low-conflict segments can be optimized first, gradually expanding the parallelizable scope.
From an engineering perspective, BAL doesn’t deliver a one-off performance spike but improves the predictability of execution behavior. For node operations teams, predictability is often more valuable than short-term peaks, as it directly impacts SLAs and incident response. Shifts in conflict and rollback rates on testnets are key metrics for evaluating BAL’s effectiveness.
| Scheduling Stage |
Without Pre-Constraints |
With BAL Constraints |
| Pre-execution Prep |
Relies on estimates |
Pre-grouping by access list |
| Conflict Handling |
Frequent runtime rollbacks |
Early conflict isolation |
| Result Stability |
Highly variable |
More predictable outcomes |
| Operations Monitoring |
Hard to define thresholds |
Structured metrics possible |
Figure 1. BAL mechanism illustration: How block-level access lists support conflict detection and parallel execution scheduling.
What Is the Relationship Between BAL and Parallel Execution?
BAL is not a "substitute" for parallel execution, but rather its "prerequisite layer." Achieving parallel execution also requires client implementation, scheduling strategies, and state management to work in concert. Without foundational constraints, forced parallelism often increases uncertainty.
Put simply, BAL transforms parallel execution from a theoretical concept into an engineerable objective. It answers "are the prerequisites in place?"—not "has peak performance been achieved?" Even as more aggressive parallel strategies are introduced, BAL’s access constraints remain essential for conflict management.
What Does BAL Mean for Developers and Application Teams?
Developers must pay closer attention to state access patterns. Designs involving high-frequency writes to the same state, complex cross-contract dependencies, or batch transaction coupling may exhibit new execution behaviors under these constraints. Applications should undergo execution path testing before launch, not just functional checks.
Product teams should also recalibrate performance communications. Post-upgrade user experience improvements may not be linear, especially as the ecosystem adapts. The prudent approach is to use phased metrics: confirm stability, failure rates, and latency percentiles—not just averages. Metric resets and staged releases should be aligned with the application adaptation framework.
What Are the Implementation Boundaries and Potential Challenges of BAL?
The first challenge is achieving cross-client consistency. Different execution clients may interpret access lists and scheduling strategies differently, requiring ongoing convergence through testnet comparisons and cross-client regression, with timestamped metric snapshots.
The second challenge is ecosystem learning costs. If development teams overlook state access structures, performance deviations may occur post-upgrade; legacy contracts may not have been written with access-friendly patterns, requiring tools and time for migration.
The third challenge is updating monitoring systems. Operations teams need new metrics related to access constraints to pinpoint whether issues stem from data preparation, scheduling conflicts, or execution engine bottlenecks. Without upgraded monitoring, the mechanism’s value cannot be fully realized. For the Node Upgrade Preparation Checklist, BAL-related logs and conflict rollback rates should be included in the acceptance criteria. In the context of Glamsterdam vs. Dencun/Fusaka Comparison, these challenges are unique risks of structural changes and cannot be addressed with capacity upgrade experience alone.
Summary
BAL (EIP-7928) addresses execution order by making state access relationships explicit, structuring conflict detection, and moving scheduling from reactive to verifiable planning. While it does not solely determine upgrade success, it is crucial for stable parallel execution and serves as a core constraint mechanism in the Glamsterdam execution layer.
FAQ
Is BAL (EIP-7928) Parallel Execution Itself?
No. BAL is the prerequisite constraint layer for parallel execution, providing the foundation for conflict detection. Parallel execution also depends on client implementation and scheduling strategies.
Why Does BAL Affect Actual Performance?
By making state access relationships explicit in advance, clients can prepare data and group tasks earlier, reducing runtime conflict rollbacks and improving execution stability.
What Is the Division of Responsibilities Between BAL and ePBS (EIP-7732)?
ePBS focuses on block production collaboration boundaries, while BAL focuses on execution constraint boundaries. Each operates at a different layer, and they are complementary in Glamsterdam.
How Should DApp Teams Respond to the Introduction of BAL?
Review state access patterns and high-frequency transaction paths, supplement execution behavior testing before and after the upgrade, and update performance monitoring and alert thresholds to avoid relying on outdated execution assumptions.
Can BAL Guarantee All Transactions Are Processed in Parallel?
No. BAL provides conflict detection and scheduling input, but high-conflict transactions must still be processed serially. The scope of parallelism depends on access patterns, client implementation, and network load characteristics.
