EIP-7928 Block-Level Access Lists: How Ethereum Enables Parallel Execution

Readers who want a broader map of protocol-level Ethereum changes can start with the TokenToolHub Blockchain Advanced Guides. This article focuses narrowly on why Ethereum state access has been difficult to parallelize, what a BAL actually contains, how clients can use it, and what developers should expect when BAL-aware infrastructure becomes part of normal execution-layer operation.

Why Ethereum execution has a state-access bottleneck

The EVM is a deterministic virtual machine, but deterministic does not automatically mean easy to parallelize. A block contains an ordered list of transactions. Each transaction can read accounts, call contracts, inspect bytecode, read storage, write storage, change balances, increment nonces, create contracts, or trigger nested calls that touch additional state. The difficulty is that many of those addresses and storage slots are discovered only as execution follows the program's control flow.

Consider a swap transaction. The externally visible transaction may target one router, but the router can call a pool, the pool can read token balances, the tokens can execute transfer logic, hooks can call other contracts, and proxy contracts can delegate execution to implementations whose storage access depends on calldata and current state. Before the EVM executes those paths, the client may not know the complete set of state that will be needed.

That uncertainty couples computation to database access. The client executes a step, discovers that it needs an account or storage slot, loads the state, continues execution, discovers another dependency, and repeats. Modern execution clients already use caches, snapshots, tries, flat state, prefetching, asynchronous I/O, and many implementation-specific optimizations, but the protocol does not traditionally provide a complete block-wide declaration of actual state access before validation begins.

The consequence is not that every operation literally runs on one CPU core. Clients already parallelize many peripheral tasks. The deeper limitation is that stateful transaction execution has ordering dependencies. Transaction B can read a storage slot that transaction A changed earlier in the same block. Transaction C can depend on the nonce or balance produced by B. If a client schedules them naively at the same time, it can compute from the wrong pre-state.

Canonical order still matters

Ethereum blocks define transaction order, and that order determines outcomes when transactions conflict. EIP-7928 does not replace this ordered state machine with a race between transactions. Instead, it exposes enough information for a client to identify where the transactions are independent and where they are dependent. Independent work can be overlapped. Conflicting work can be serialized, staged, or validated against the correct intermediate state.

This is a critical distinction. Parallel Ethereum execution should not be interpreted as transactions producing results in any order. It means a client can internally parallelize work while still producing exactly the same state transition that canonical sequential semantics require.

State I/O can be more expensive than the EVM instruction itself

Many EVM instructions are cheap computationally but trigger state access. Reading a storage slot or external account can require lookups through client state structures, cache misses, database access, decoding, and trie-related work. When the touched state is unknown until execution reaches each opcode, I/O becomes demand-driven and difficult to schedule efficiently across the whole block.

A BAL changes the scheduling problem. If the client can inspect a trustworthy block-wide description of addresses and storage keys that will be needed, it can launch many reads before the EVM reaches them. The time profile moves closer to parallel I/O plus parallel EVM work rather than a long chain of execute, wait for state, execute, wait for state.

What EIP-7928 adds to an Ethereum block

EIP-7928 introduces a Block Access List that is cryptographically committed by the block header. The header receives a block_access_list_hash, defined as the Keccak-256 hash of the RLP-encoded BAL. The full list is not placed directly in the traditional block body. Execution-layer clients store BAL data separately and transmit it through the execution payload and Engine API path defined for the fork.

The important property is not merely that a list exists. The list is part of block validity. During validation, a client can execute the block while generating the accesses and changes it observes, encode that locally generated BAL deterministically, and compare it with the BAL committed by the block. If the declared BAL contains missing accesses or spurious accesses, the block is invalid.

The BAL records accounts that were accessed even if they did not change

An account can matter to execution without receiving a state change. A contract can inspect another account's balance, code size, code hash, or bytecode. It can call an address that reverts. A static call can read data but leave no writes. EIP-7928 requires these accessed addresses to be represented even when their change lists are empty. That completeness is what makes the BAL useful for I/O scheduling.

The specification covers transaction senders and recipients, relevant call targets, precompiles when accessed, withdrawal recipients, system-contract accesses, selfdestruct beneficiaries, contract-creation addresses once the address is actually accessed under the normative rules, and other cases defined by EVM state access.

Storage is separated into changes and read-only access

For storage, the BAL distinguishes slots that changed from slots that were only read. A storage write is recorded with the post-transaction value and a block access index. A slot that is accessed through a read but not changed is recorded in the read set. A no-op write, where an SSTORE leaves the value unchanged, is treated as a read for BAL purposes because there is no post-state difference to apply.

This structure gives the client two kinds of information at once. The read set tells it what data can be prefetched for execution. The change set tells it what intermediate and final post-transaction values must exist at specific points in the ordered block.

Balances, nonces, and code changes are recorded by transaction index

The BAL also tracks post-transaction balance changes, nonce changes, and code changes. For example, a sender's balance after paying gas and transferring value can be recorded for that transaction index. A sender's nonce increment appears in the nonce change list. A newly deployed contract can record runtime bytecode in the code change list. These are state diffs, not just this address was touched flags.

BlockAccessIndex preserves ordered state transitions

EIP-7928 assigns a block access index to each change. Index 0 is reserved for pre-execution system-contract calls. Transactions use indices 1 through n in block order. Post-execution system calls and withdrawals use n + 1. This indexing is central to parallelism because two transactions can touch the same account or slot and still be represented with distinct ordered post-state values.

BlockAccessList
  AccountChanges
    address
    storage_changes
      storage_slot
        block_access_index
        post_value
    storage_reads
      storage_slot
    balance_changes
      block_access_index
      post_balance
    nonce_changes
      block_access_index
      post_nonce
    code_changes
      block_access_index
      post_code

Why the BAL must be deterministic

A consensus object cannot depend on client preference. Geth, Nethermind, Besu, Erigon, Reth, Nimbus, and other implementations must be able to derive the same BAL from the same valid block. EIP-7928 therefore defines ordering and uniqueness rules rather than allowing each client to serialize an equivalent set differently.

Accounts are sorted lexicographically by address. Storage-change slots and storage-read keys are sorted lexicographically. Changes inside a slot are ordered by block access index. Each address appears exactly once. A storage key cannot appear in both the read-only list and the changed-storage list for the same account. Change indices cannot be duplicated within a change list.

These details may look like encoding trivia, but they solve a consensus problem. If two clients observed the same accesses but serialized them in different orders, their RLP bytes would differ, the hash would differ, and block validity would become ambiguous. Deterministic ordering turns the BAL into one canonical commitment.

Gas validation happens before state access where required

The specification also tightens the boundary around what counts as an access. For state-accessing opcodes, gas costs that can be determined without reading state must be validated before the target is considered accessed. If execution fails the pre-state gas check, the target must not appear in the BAL because the EVM never actually accessed it.

This matters for exceptional halts and for opcodes whose total cost has state-dependent components. Without a precise rule, different clients could disagree about whether a target was touched before an out-of-gas condition. BAL consensus requires a single answer.

EIP-2930 transaction access lists versus EIP-7928 BALs

EIP-2930 and EIP-7928 share the phrase access list, but they solve different problems. EIP-2930 introduced an optional transaction type in which the transaction carries addresses and storage keys it expects to access. Those listed locations are warmed for gas accounting, and accesses outside the list remain valid, although they can be more expensive.

An EIP-2930 list is therefore a transaction-supplied declaration. It can contain entries that are not ultimately accessed. It does not need to describe every state location the transaction will touch. It does not carry post-execution balances, nonces, code, or storage values. Its correctness is not a consensus claim about actual execution.

EIP-7928 changes all of those properties. A BAL is block-wide, derived from actual execution, enforced, deterministic, and enriched with state diffs. The EIP explicitly says that entries from an EIP-2930 access list are not automatically copied into the BAL. Only addresses and slots that execution actually touches or changes are recorded.

Serial validation versus BAL-assisted validation

The most useful way to visualize EIP-7928 is not one core versus many cores. The important change is when the client learns state dependencies. Without a block-wide map, it discovers dependencies while execution is already in progress. With a BAL, the client can prepare the state working set up front, identify non-overlapping transactions or state regions, and schedule work around known conflicts.

How BALs enable parallel disk reads

Parallel disk reads are the most direct benefit because they require the least conceptual leap. If a client knows that a block will access 4,000 storage slots spread across hundreds of accounts, it does not need to wait for execution to ask for each slot one at a time. It can start fetching the working set concurrently, subject to its database engine, cache architecture, available memory, I/O queue, and internal scheduling strategy.

This is especially useful when the state is not already in memory. A hot account used by a major protocol may be cached, but long-tail addresses and storage keys can trigger slower lookups. A complete access map gives the client an opportunity to overlap those misses.

The BAL is useful even when the client cannot perfectly parallelize EVM execution. Prefetching alone can reduce stalls because the state is ready by the time a transaction needs it. That is why it is more precise to say BALs enable a family of client optimizations rather than claiming one universal percentage speedup.

Read-only accesses matter to prefetch

If the BAL only contained writes, the client would still discover many reads late. EIP-7928 therefore includes accessed accounts with no changes and read-only storage keys. A BALANCE opcode, EXTCODEHASH, STATICCALL, SLOAD, or another read path can create I/O even when the state remains unchanged. Recording those reads is what turns the BAL into a full I/O map.

Actual client gains depend on implementation

A client that already uses an efficient flat-state database and aggressive caching will experience a different benefit from a client with another storage architecture. NVMe latency, memory size, pruning mode, snapshot strategy, trie representation, and concurrency design all affect results. EIP-7928 standardizes the information available to the client, not the exact algorithm the client must use.

How BALs support parallel transaction validation

Once dependencies are visible, transactions can be grouped according to the state they touch. Two transactions that read and write completely disjoint accounts and slots can be candidates for parallel execution or validation. If they touch the same state, the block access indexes and ordered post-values describe the dependency chain that must be respected.

The specification's rationale cites historical analysis indicating that roughly 60 to 80 percent of transactions access disjoint storage slots, with the remaining 20 to 40 percent benefiting from post-transaction state diffs that help preserve ordered state dependencies. Those numbers are evidence from the EIP's analyzed data, not a guarantee for every future workload. A block dominated by one popular contract can have much more contention.

Parallel does not mean independent finalization

A client must still ensure each transaction is valid against the state Ethereum defines for that point in the block. Suppose Transaction 1 writes slot X from 5 to 6, and Transaction 3 later reads X. Transaction 3 cannot be validated as if X were still 5. The BAL's per-index changes provide the information needed to construct or validate the correct intermediate view.

Client teams have several possible implementation strategies. They can partition transactions into conflict-free groups, speculatively execute and detect conflicts, build dependency graphs, use multi-version state, or combine prefetch with mostly sequential EVM execution. EIP-7928 gives them a standard block-level artifact from which those strategies can be built.

Validation still regenerates execution evidence

The BAL is not a builder's permission slip to invent state. The state transition function requires the provided BAL to match actual state accesses. The reference approach described in the EIP is straightforward: execute the block, collect a virtual BAL, encode it, and compare it with the received list and header commitment. A client may optimize that verification, but it cannot accept a mismatching list.

How BALs help state-root computation

After transactions execute, Ethereum clients need to represent the resulting state and compute the commitment that identifies it. State-root work can involve updating many branches or pages in the client's state structure. Without an upfront view of changed accounts and storage, some of that work waits until execution reveals which keys changed.

A BAL includes the changed locations and post-transaction values. That means a client can identify the state-update workload earlier and can schedule independent branches or state regions concurrently. The EIP describes parallel post-state root calculation as one of the primary benefits.

The exact speedup depends on the state representation used by the client and on other protocol changes. BALs do not magically make all cryptographic commitment work constant-time. They remove uncertainty about the set of state changes, which is a prerequisite for more parallel and pipelined state-root processing.

Post-state values are more useful than write locations alone

A list saying slot X changed would still force a consumer to execute the transaction to learn the new value. EIP-7928 stores the post-transaction value with the access index. That turns the BAL from a simple dependency list into a state-diff artifact. For balance, nonce, code, and storage changes, the consumer can see the resulting value after a particular transaction boundary.

Executionless state updates and what the phrase really means

Executionless state updates is one of the most important and most easily misunderstood phrases around EIP-7928. The concept is that a client which has an authenticated BAL containing post-transaction state values can reconstruct or advance state by applying those state changes, rather than replaying every EVM instruction merely to rediscover the same output values.

This is valuable for synchronization. A syncing client may need to advance from an older state toward a recent state. If it can retrieve BALs for the intervening blocks, verify their commitments against canonical headers, and operate under the appropriate protocol and sync assumptions, it can apply state changes directly. The networking companion EIP-8159 defines peer-to-peer exchange of BALs for historical and synchronization use cases.

Why this can improve sync architecture

Traditional synchronization often combines state snapshot acquisition with execution or trie-healing work. BALs add a canonical record of the touched locations and resulting values for post-activation blocks. That can reduce the need to discover missing state reactively and can support more direct state healing and update strategies.

EIP-8159 exists because this benefit requires BAL availability beyond the live Engine API path. During normal block processing, consensus-layer and execution-layer components can exchange BAL information. Historical sync peers need a way to request older BALs from the network. The eth/71 proposal introduces dedicated request and response messages for that purpose.

A BAL-aware block validation flow

A practical mental model is to separate commitment, scheduling, execution, and verification. Different clients may pipeline these stages differently, but the security properties remain similar.

BAL size, bandwidth, and block propagation

Block access information is useful because it is detailed, but detail costs bytes. EIP-7928 therefore has to balance parallelization benefits against block propagation and storage overhead. The proposal's 60 million gas analysis reports an average compressed BAL size of about 72.4 KiB for the analyzed workload.

The largest components in that analysis are storage writes and storage reads. This makes intuitive sense. Contract-heavy Ethereum activity can touch many slots, and each changed slot needs enough information to identify the key, the transaction index, and the post-value. Account addresses and RLP overhead are meaningful but smaller portions.

The chart is normalized to the largest component so the proportions remain readable on mobile. The values come from the EIP's published analysis and should be treated as workload evidence, not as a fixed BAL size for every future block.

The list is gas-bounded

EIP-7928 does not define one fixed global maximum number of BAL items. Instead, it constrains the total number of storage keys plus unique addresses relative to the block gas limit. The normative relationship is bal_items ≤ block_gas_limit / 2000. The item cost is deliberately set below the cheapest ordinary state-access path expected under the associated gas changes, leaving room for system-level accesses and withdrawal recipients that can add entries without consuming transaction gas in the same way.

This bound is important for denial-of-service resistance. Without a protocol relationship between list growth and the economic limits of the block, a proposer could attempt to attach a huge state map that forces peers to download and parse excessive data.

Why the BAL is not simply stuffed into the block body

The specification commits to the BAL in the header and transports the full list through execution-layer interfaces. The networking companion also uses dedicated messages for peer exchange. Keeping BAL retrieval separable gives clients more flexibility for pruning, historical sync, and protocols that do not need every BAL bundled into every body transfer.

Malicious BALs, phantom reads, and early rejection

A malicious proposer could try to abuse the prefetch advantage by declaring state that execution never touches. If clients eagerly fetch every declared storage key, a phantom-heavy BAL could create wasted I/O and bandwidth. The consensus rule eventually rejects the block because spurious accesses are invalid, but late rejection still consumes resources.

EIP-7928 specifically discusses this problem for storage reads because read-only storage entries are not mapped to individual transaction indices. A client may not be able to prove that a particular declared read is phantom until it has executed enough of the block to know the slot never appears.

Gas-budget feasibility provides an early bound

The EIP recommends a periodic feasibility check. Let R_remaining be the number of declared storage reads not yet observed, and G_remaining be the remaining block gas. The client checks whether there is enough remaining gas for those reads to occur at all.

If the remaining gas cannot possibly pay for the still-declared reads, the block is impossible under the BAL rules and can be rejected before finishing execution. The EIP suggests performing the check periodically, for example every eight transactions, to improve early rejection without forcing a serial check after every transaction.

Structural checks should happen before expensive execution

Clients can also reject malformed lists cheaply. Invalid ordering, duplicate account entries, impossible block access indexes, a storage key appearing in both read and change sets, or a list exceeding the gas-based item bound are all candidates for early failure. These checks reduce the attacker's ability to convert one invalid block into maximum I/O and CPU work.

Validation overhead is real, but it buys enforceability

A BAL-aware client has extra work. It must parse the list, hash it, verify structure, prefetch responsibly, track actual accesses during execution, build a deterministic local representation, and compare the result. It may also maintain more temporary metadata to support concurrent execution.

That overhead is not an accidental implementation cost. It is the mechanism that prevents the BAL from becoming an untrusted hint. If a node used the list only to accelerate reads but never checked it against execution, a proposer could mislead the scheduler or state updater. Consensus enforcement is what makes downstream optimizations safe to build on the artifact.

The engineering target is therefore not zero BAL overhead. The target is for list validation to be cheaper than the execution and I/O time saved, especially as block gas limits and state workloads grow. The EIP explicitly describes BAL verification as something that can occur alongside parallel I/O and EVM work rather than as a serial stage that must finish before all execution.

What changes for smart contract developers

For most Solidity developers, EIP-7928 is primarily an execution-client and infrastructure change. A contract still executes according to EVM semantics. SLOAD still reads storage. SSTORE still writes storage. CALL still invokes another account. Reverts still roll back state changes according to existing transaction semantics. Transaction order still matters.

You do not manually author a BAL in your contract

Application developers do not add a new Solidity object containing every slot their contract may touch. The BAL is produced at the block level from actual execution. It is not a replacement for an ABI, storage layout, transaction access list, or application-level dependency declaration.

Dynamic control flow remains valid

Contracts can continue to compute addresses dynamically, access mappings based on user input, call through proxies, create contracts, use nested calls, and branch on state. The BAL captures what actually happened for the included block. It does not require contracts to become statically analyzable.

Gas and related fork changes can still affect application economics

Although BAL semantics alone do not rewrite Solidity behavior, Glamsterdam includes other EIPs that can change gas costs and state economics. Developers should separate BAL makes execution scheduling more parallel from other fork EIPs reprice state creation or state access. Treating the whole network upgrade as one performance feature can hide application-level cost changes.

Tracing and observability can become richer

Developers, auditors, explorers, and analytics systems may gain a new block-level evidence source for which accounts and slots were accessed and what post-transaction values changed. That can improve debugging, synchronization, state-diff indexing, and historical analysis. It does not replace a full execution trace when you need opcode-level causality, call trees, revert reasons, or application semantics.

For transaction-level interpretation, the TokenToolHub Transaction Decoder remains the right layer for reading calldata, transfers, approvals, nested calls, and transaction consequences. A BAL can tell you which state was touched; it does not, by itself, explain what the user intended or why a contract changed that state.

What BALs do not solve for contract security

Knowing the state access set is not the same as proving a contract is safe. A malicious token can touch perfectly predictable storage and still implement a honeypot. An upgradeable proxy can have a clean BAL while an administrator retains dangerous upgrade power. A lending protocol can access disjoint state efficiently while containing a flawed price assumption.

Security review remains behavioral. You still need to examine authorization, upgradeability, external calls, storage layout, invariants, oracle dependencies, token accounting, signature validation, access control, and failure modes.

When an upgrade or deployment changes contract code, use the TokenToolHub Smart Contract Diff to compare verified implementations and isolate behavioral changes. BAL evidence can complement that analysis by showing which state locations a block accessed after the change, but code review explains what the new implementation is capable of doing.

What EIP-7928 means for rollups and L2 engineering

Rollups do not automatically inherit every L1 execution optimization in the same form, but Ethereum execution-layer throughput and node efficiency affect the environment in which rollups settle, post data, verify proofs, operate bridges, and run infrastructure. BAL-aware clients can make L1 validation and synchronization more efficient as Ethereum scales capacity.

Rollup teams may also study the design pattern independently: authenticated access maps and state diffs are useful wherever execution systems need to parallelize state I/O or reconstruct state efficiently. Whether a specific L2 adopts an analogous mechanism depends on its VM, state model, sequencer architecture, proof system, and data-availability design.

If you are evaluating the broader tradeoffs between rollup stacks, settlement, proof systems, data availability, sequencer design, and operational requirements, the Rollups Buyer's Guide provides the architecture context that BALs alone cannot supply.

What changes for node operators and infrastructure teams

Node operators will feel EIP-7928 more directly than most application developers because clients need to store, exchange, validate, and potentially prune BAL data. Hardware planning must account for CPU concurrency, memory pressure from prefetching, database queue behavior, network bandwidth, and additional block-adjacent data.

More concurrency can increase resource bursts

Parallel I/O reduces serialized latency, but it can increase instantaneous demand. A node that launches hundreds or thousands of reads concurrently can saturate storage queues or memory bandwidth. Good implementations need backpressure, batching, cache-aware scheduling, and limits that prevent a BAL from turning parallel into uncontrolled resource contention.

Storage mode and pruning strategy matter

Execution clients may keep BALs separately from traditional blocks and may define retention policies. Archive-oriented infrastructure, indexers, and historical analytics services may want longer BAL retention than ordinary validating nodes. Sync services may expose BAL retrieval through the eth/71 networking path or related APIs.

Measure end-to-end latency, not only EVM time

The performance objective is block processing. If EVM execution becomes faster but BAL parsing, database contention, state-root updates, or network transfer becomes the new bottleneck, the system still needs optimization. Operators should track payload arrival, BAL decode time, prefetch hit rate, execution duration, state-root duration, memory usage, disk queue depth, and total block validation time.

How to interpret BAL evidence after the fork

Once BALs become available in production data pipelines, they can be extremely useful for forensic and performance analysis, but they should be read at the correct evidence level.

This separation is especially important in post-fork investigations. A security analyst may see that a proxy administrator slot changed, but the BAL alone does not prove whether the change came from legitimate governance, compromised ownership, or a malicious delegatecall path. Pair the state evidence with transaction calldata, call traces, event logs, verified source, and contract-diff analysis.

Worked examples of BAL-assisted execution

Example one: two independent token transfers

Transaction 1 transfers Token A between Alice and Bob. Transaction 2 transfers Token B between Carol and Dave. Assume the two token contracts use completely separate storage and neither transaction touches a shared router, fee collector, oracle, or account.

The BAL shows disjoint contract addresses and storage slots. A client can prefetch both working sets concurrently. It can potentially execute or validate both transactions in parallel because Transaction 2 does not need any state produced by Transaction 1. Final state assembly still respects their canonical indexes, but there is no conflict to serialize.

Example two: two swaps against the same pool

Transaction 1 swaps through a liquidity pool and updates reserves. Transaction 2, later in the block, swaps against the same pool. Both transactions access the reserve slots.

The BAL reveals the overlap. A client cannot validate Transaction 2 using the pre-block reserve value because the first swap changes it. The storage-change list can contain separate post-values at the two transaction indexes. The dependency is explicit, so the client can serialize that state region or use a multi-version execution strategy while parallelizing unrelated work elsewhere.

Example three: read-only price oracle access

Several transactions read the same oracle contract but do not update it. The oracle account and relevant storage keys appear in read-only access information. The client can fetch the oracle state once and serve the data from cache to multiple concurrent execution tasks.

This demonstrates why read-only slots belong in the BAL. They may not affect the final state root, but they can dominate execution I/O.

Example four: contract deployment

A factory transaction deploys a contract. The resulting contract address is accessed during creation under the specification's rules. The BAL can record the new account's nonce and runtime code as post-transaction changes, as well as factory storage updates that record the deployment.

A sync-oriented consumer can use the code and nonce diffs to reconstruct the resulting state without re-running initcode solely to discover the final runtime bytecode, provided the BAL has been authenticated under its synchronization model.

Example five: a reverting nested call

A transaction calls Contract A, which calls Contract B. Contract B reads several accounts and storage slots, then reverts. The state changes inside the reverted frame are discarded, but the accessed addresses still matter to BAL completeness under the exceptional-halt and revert rules.

This distinction is important for prefetch and validation. The fact that a subcall reverts does not mean its state reads never occurred. Clients still need those reads to reproduce execution.

Example six: same slot written twice in one block

Transaction 2 writes a governance parameter from 10 to 12. Transaction 7 later writes the same slot from 12 to 15. The BAL stores the slot once under that account but can attach multiple ordered storage changes, one at each block access index.

This makes the intermediate value visible. A consumer updating state sequentially can apply 12 at index 2 and 15 at index 7. A parallel execution engine knows Transaction 7 depends on the version produced by Transaction 2 if its logic reads the slot.

A realistic performance model for BALs

It is tempting to convert 60 to 80 percent disjoint storage access into Ethereum becomes 4x faster, but that is not a valid inference. Block processing time includes network propagation, signature checks, transaction decoding, state reads, EVM computation, hashing, state commitment work, receipts, consensus interaction, database writes, and client-specific overhead.

BALs primarily attack uncertainty and serialized state access. The best-case benefit appears when a workload has many independent state accesses, storage is not fully cached, the client can issue concurrent reads efficiently, and there is enough CPU headroom for parallel EVM work. The benefit is smaller when a block is dominated by one hot contract, the state is already in memory, or another stage is the bottleneck.

The right benchmark therefore measures full block validation under realistic hardware and state size. It should compare the same blocks, same client, same database state, same pruning mode, and controlled cache conditions. Protocol claims should be separated from one client's optimization results.

A practical developer workflow after BAL activation

Application teams do not need to redesign every contract around BALs, but they can use the new data source to improve debugging and performance analysis.

Security and implementation risks to watch

EIP-7928 improves information availability for execution clients, but it also creates new consensus-critical parsing and accounting paths. Any data structure that influences block validity, prefetch behavior, and state reconstruction must be implemented defensively.

Incorrect inclusion semantics

If one client includes an account that another client excludes for a corner-case halt, CREATE failure, delegation path, precompile call, withdrawal, or system-contract interaction, they can disagree on the BAL hash. That is why the EIP contains detailed normative rules for when an access has actually occurred.

Incorrect no-op write handling

A storage write that leaves the slot unchanged should not be represented as a state change. Implementations must compare against the correct immediately preceding value, including changes from earlier transactions in the same block. A naive comparison against only the pre-block state could misclassify a later write.

Concurrency bugs

Parallel execution introduces implementation risk even if the protocol semantics are unchanged. Shared caches, multi-version state, write buffers, dependency graphs, and concurrent trie updates can contain race conditions. Client diversity and extensive cross-client testing are essential because one optimization bug must not become a consensus split.

Prefetch amplification

A client should not issue unlimited storage requests simply because a BAL lists them. Rate limiting, feasibility checks, bounded queues, and cancellation after early invalidity are part of secure performance engineering.

Historical BAL availability

Executionless synchronization benefits depend on obtaining the required BALs. Peers may legitimately prune them according to retention policy. EIP-8159 therefore requires clients to handle unavailable entries gracefully. Infrastructure operators should not assume every peer keeps complete BAL history forever.

Parser and RLP edge cases

The BAL is consensus-critical encoded data. Clients must reject malformed lengths, duplicate fields, invalid indexes, unsorted lists, non-canonical values, and other representation errors consistently. Fuzzing and shared execution tests are especially important because equivalent loose parsing is dangerous in consensus code.

What EIP-7928 does not change

The proposal is easier to understand when its boundaries are explicit.

• It does not remove canonical transaction ordering.
• It does not make two conflicting transactions independent.
• It does not let a validator accept state diffs without validating their relationship to execution.
• It does not require Solidity developers to predeclare storage keys.
• It does not replace EVM call traces, transaction receipts, event logs, or ABIs.
• It does not prove that a contract interaction is safe merely because its state access is predictable.
• It does not eliminate database or state-root work. It makes the workload more visible and schedulable.
• It does not guarantee one fixed percentage speedup across clients and hardware.
• It does not turn every block into perfectly parallel work. Hot contracts can still create substantial contention.
• It does not automatically change rollup execution architecture, even though L2 teams can learn from the design.

Why BALs matter in the Glamsterdam scaling strategy

Glamsterdam is not only about making one block execute faster. Its broader direction is to raise Ethereum's sustainable capacity while keeping validation feasible for a diverse set of node operators. That requires attacking several bottlenecks together: execution timing, state access costs, state growth, networking, block construction, and validator duties.

BALs fit that strategy because higher gas limits increase the amount of state work a block can demand. If clients continue discovering state strictly on demand, larger blocks can amplify serialized I/O and validation latency. A block-level access map lets client software prepare and parallelize more of that work, giving protocol designers more room to scale without simply assuming faster hardware will solve the problem.

The connection to sustainable scaling is therefore structural. BALs do not directly lower the gas price a user pays. They improve the execution-layer efficiency that can support higher capacity safely. Other upgrade components may affect user fees more directly.

Questions infrastructure teams should answer before production use

When client releases begin exposing BAL-aware functionality, teams should validate behavior rather than assuming all implementations expose identical operational interfaces.

Conclusion: EIP-7928 turns hidden state dependencies into a consensus artifact

Ethereum's execution bottleneck is not simply that transactions are written in an ordered list. The harder problem is that the state each transaction needs is often discovered only while execution is happening. That makes database access reactive and makes safe parallel scheduling difficult because dependencies are hidden until the EVM reaches them.

EIP-7928 changes the information model. A block commits to a deterministic Block Access List containing the accounts and storage locations actually accessed, plus the ordered post-transaction values for state that changed. That list gives execution clients a block-wide working-set map before they finish replaying the block.

With that map, clients can prefetch state in parallel, identify disjoint transaction work, maintain ordered versions for conflicting state, schedule state-root updates earlier, and support state reconstruction workflows that do not need to execute every historical instruction solely to learn final values. The gain is not one single parallel-execution algorithm. It is a protocol-level data primitive that enables many client optimizations.

The security requirement is equally important: the map must be true. Missing or spurious accesses invalidate the block. Clients need deterministic ordering, exact edge-case semantics, gas-bounded size limits, early rejection of impossible phantom reads, and concurrency-safe implementations. BALs increase the amount of structured evidence in a block, but they also increase the consensus surface that clients must implement identically.

For smart contract developers, most EVM semantics remain familiar. You do not manually build a BAL, and dynamic contract behavior remains valid. The main practical opportunity is better infrastructure, richer state-access evidence, and faster node processing. When investigating a post-fork transaction, use BAL data to establish what state was touched, the Transaction Decoder to interpret transaction behavior, and the Smart Contract Diff when code or implementation changes need to be isolated.

For broader protocol study, continue through the Blockchain Advanced Guides. EIP-7928 is a strong example of Ethereum scaling by exposing better execution information, not by weakening deterministic state semantics.

FAQs

References and further reading

The following primary Ethereum specifications provide the protocol definitions and current network-upgrade context used in this guide.

• EIP-7928: Block-Level Access Lists
• EIP-7773: Hardfork Meta, Glamsterdam
• EIP-2930: Optional Access Lists
• EIP-8159: eth/71 Block Access List Exchange
• Ethereum.org: Glamsterdam Roadmap

This TokenToolHub guide is technical research and educational material. Protocol specifications can change before network activation. Client implementations, test vectors, interfaces, gas parameters, and fork schedules should be verified against current Ethereum specifications and release announcements before production deployment.