EIP-7928: Block-Level Access Lists

⌬LLM No new opcode is defined.

⚇Human No rationale recorded.

⌬LLM The EVM results, stack behavior, and state semantics of existing opcodes are not modified; BAL recording is block-validation instrumentation rather than opcode behavior under this anchor.

⚇Human Final EVM semantics (gas charged, state changes, reverts) are unchanged. Only the observation order for BAL inclusion is constrained, which is a spec-framework concern, not a behavior change in the anchor's sense.

⌬LLM No new precompile is introduced.

⚇Human No rationale recorded.

⌬LLM No pre-existing precompile logic or gas accounting is modified.

⚇Human No rationale recorded.

⌬LLM It integrates existing system operations into BAL generation but introduces no new system contract.

⚇Human No rationale recorded.

⌬LLM No blob gas accounting mechanism is introduced or modified.

⚇Human No rationale recorded.

⌬LLM Recording the post-refund balance does not create or alter an EVM gas-refund mechanism.

⚇Human No rationale recorded.

⌬LLM No new transaction type is introduced.

⚇Human No rationale recorded.

⌬LLM The new validity condition applies to the block's BAL commitment, not to the validity rules of existing transaction types or their intrinsic gas calculation.

⚇Human Transaction structure and intrinsic gas are unchanged.

⌬LLM The explicit new bal_hash header field satisfies the rubric's binary score-3 condition.

⚇Human New `block_access_list_hash` (Hash32) on the header; `blockAccessList` carried out-of-header via the Engine API.

⌬LLM This is a single but complex new block-encoding and validation mechanism that sync clients must ingest, decode, commit, and validate, matching score 2.

⚇Human A single complex RLP validation mechanism is introduced: the BAL itself, whose sub-rules include hash binding to the header, lexicographic address ordering, ascending `block_access_index` per change list, uniqueness per `(address, slot)`, mutual exclusion between `storage_changes` and `storage_reads`, `bal_items <= block_gas_limit // ITEM_COST`, and `SYSTEM_ADDRESS` exclusion unless touched. The three new block exceptions (`INVALID_BLOCK_ACCESS_LIST`, `INVALID_BAL_HASH`, `BLOCK_ACCESS_LIST_GAS_LIMIT_EXCEEDED`) all stem from this single validator.

⌬LLM A fork requirement alone is not a new activation mechanism, and initialization of the new tracking structure is excluded by the rubric's special note.

⚇Human No state mutation or pre-existing internal variable is modified at the activation block (the builder is initialized fresh per block).

⌬LLM Scored conservatively at zero from the row label and global scale because the proposal contains no explicit Engine API encoding change.

⚇Human Still RLP — no new wire encoding format introduced at the Engine API layer beyond what is captured under "Encoding changes (RLP/SSZ)".

⌬LLM The state-transition workflow needs a new BAL validation mechanism and access to new block data, which best fits the rubric's score-2 anchor even though a concrete tool schema is absent.

⚇Human A single new mechanism — the BAL builder/validator wired into the t8n (`block_access_lists.py`, `BlockAccessListBuilder`, `hash_block_access_list`, `validate_block_access_list_gas_limit`) — surfaces one new payload output (`blockAccessList` on `ExecutionPayloadV4`). The `block_access_list_hash` on the header is **not an independent field**: it is fully determined as `keccak256(rlp(BAL))` and carries no information not already present in the BAL itself. It is a Merkle/checksum binding, comparable to `transactionsRoot` vs. the transaction list — counting it as a second "new field" would double-count one piece of information. So in t8n terms this is "a new mechanism" (singular) producing one new output, not "multiple new fields **and** a new mechanism" (the 3 bucket). Per the anchor's footnote, the t8n must additionally be fork-aware (Amsterdam-only activation), which warrants special consideration regardless of score.

⌬LLM Incorrect access capture, canonicalization, hashing, or state-diff handling can affect consensus block acceptance and reconstructed state across execution, syncing, withdrawals, and system operations, warranting extensive review and fuzzing across critical components.

⚇Human The BAL elevates **every state-access check** — not just state writes — into consensus-critical territory. Whether an account or slot appears in the BAL depends on whether the caller had enough gas to *touch* it (cold/warm cache, account existence, 7702 delegation load, static-context check, value-transfer gas), and whether ambient artefacts like the coinbase or precompiles are deemed "touched" under fee-burning, empty-block, zero-tip, and selfdestruct-to-self scenarios. Any client that mis-orders a gas check vs. a state observation, mis-classifies a touch, or leaks cross-block precompile state diverges from the block-hash-bound BAL and breaks consensus. This is a substantial expansion of the consensus surface that interacts with multiple critical components (EVM gas accounting, EIP-2929 warm/cold tracking, EIP-6780 selfdestruct semantics, EIP-7702 delegation resolution, system-contract handling) and warrants extensive review and fuzzing.

⌬LLM Performance cannot be fully isolated because BAL construction, database access, execution scheduling, block propagation, and sync interact across the full block-processing path, with substantial effects on existing benchmarks.

⚇Human The BAL adds ~70 KiB/block of propagation overhead and is interwoven with execution — it cannot be benchmarked in isolation because validation requires re-deriving the BAL during the state transition. Builder behavior interacts with intra-tx coalescing, cross-frame shadowing, net-zero filtering, and the `R_remaining * 2000` gas-budget feasibility check. Benchmark suites under `tests/benchmark/stateful/eip7928_block_level_access_lists/` and `tests/benchmark/compute/eip7928_block_level_access_lists/` were added.

⌬LLM Several interacting boundary-prone mechanisms require elevated combinatorial testing, especially revert/exception behavior, read-versus-write classification, system-operation indexing, ordering, and maximum lengths.

⚇Human An elevated number of cases is required. Per `test_cases.md` the BAL implementation drove gas off-by-one boundary tests at every state-access opcode (cold vs warm × OOG-before-target-access / OOG-after-target-access / success-minus-1 / success). Add: net-zero storage filtering (intra-tx coalescing, cross-frame shadowing, nested DELEGATECALL net-zero), CREATE/CREATE2 collisions, same-tx create+SELFDESTRUCT, 7702 invalid-nonce/invalid-chain-id, static-context filtering across all call opcodes, empty-block coinbase, zero-tip coinbase, system-address surplus filtering, RIPEMD-160 cross-block state leak, lexicographic byte-ordering endian traps.

⌬LLM Serialization, commitment use, and proof compatibility alone do not introduce a new cryptography mechanism under this anchor.

⚇Human Keccak-256 over RLP only — already covered.

⌬LLM The proposal has strong dependencies on multiple past and same-era mechanisms whose accesses and state changes must be represented canonically, requiring extensive coordinated cross-EIP vectors.

⚇Human Strong interdependencies, with existing test vectors actively redesigned: EIP-2929 (warm/cold) drives the gas-boundary cliffs that gate BAL inclusion; EIP-2930 listed-but-untouched entries are explicitly excluded; EIP-1559 coinbase tipping vs. burned base fee determines coinbase inclusion; EIP-6780 changes selfdestruct persistence semantics that the BAL must mirror; EIP-7702 delegation creates a two-level access model (target vs. delegated target) with multiple OOG boundaries and authorization-failure cases; EIP-4895 withdrawals are credited at `index=n+1` with no EVM execution; EIP-2935, EIP-4788, EIP-7002, EIP-7251 each require system-contract storage diff and cross-index handling; EIP-1153 transient storage must be explicitly *excluded*; EIP-214 static-context restrictions must fire before BAL inclusion.