Evaluated on: · Spec revision: 2025-07-31 · 59be937534
Scope at the cutoff. At this revision, EIP-7928 adds a mandatory Block-Level Access List (BAL). The BAL is an SSZ structure carried in the block body and committed to by a new `bal_hash` header field. It records every address accessed during block execution, sorted, along with storage writes (slot → [tx_index → new value]), read-only storage keys, and post-transaction balance, nonce and code values, each indexed by transaction. It also covers changes made by withdrawals and by system contracts (EIP-2935, EIP-4788, EIP-7002, EIP-7251). Block validation re-executes the block, builds the BAL from the gathered accesses (with reference to EIP-2929 accessed sets), and requires its hash to equal `bal_hash`. Any missing or extra entry makes the block invalid. Gas, opcode and transaction semantics are not changed.
- Evaluator
- LLMChecklist v3
- Confidence
- Medium
- Under-specified at assessment cutoff
- Yes — 8 criteria affected
- Plausible range
- 35–45 (High)
- Assessment cutoff
- 2025-07-31 · EIP revision
59be937534(2025-07-31)
Score bands · Checklist revision 3
- Low <12
- Medium 12–22
- High ≥23
28 criteria scored 0–3 (4 in exceptional cases; cross-EIP interactions is uncapped); nominal maximum 84.
Complexity profile
Each segment is one criterion's contribution to the LLM total. Hover or focus a segment for its score and rationale.
Top complexity drivers
- Cross-EIP interactions4
- State-access ordering within opcode execution3
- New block / header fields3
- Encoding changes (RLP/SSZ)3
Under-specified at assessment cutoff: Yes
The EIP text available at the assessment cutoff left material behavior unresolved. The affected criteria and the plausible total range record that uncertainty.
Why: The revision contradicts itself on the transaction index for system-contract and withdrawal changes, and records pre-transaction system calls with the post-transaction index (twice). It does not say whether reverted-frame accesses, precompiles pre-warmed by EIP-2929, or unused EIP-2930 entries are included. The hash function, header field position and Engine API carriage are undefined. Several storage-read and code-change rules are vague or cannot express multiple changes. The worked example is internally inconsistent.
Plausible total
35–45
recorded score 41 · plausible tiers High
Unresolved questions at the cutoff (10)
- Is the system-contract and withdrawal transaction index transaction_count or transaction_count + 1, and how are pre-transaction system calls (EIP-2935, EIP-4788) distinguished from post-transaction ones (EIP-7002, EIP-7251)?
- Does process_system_contracts being called twice produce duplicate StorageChange entries?
- Are accesses in reverted or out-of-gas frames included in the BAL, given that EIP-2929 sets revert with scope?
- Are precompiles, tx.sender/tx.to and EIP-2930 access-list entries that are never actually touched included?
- What is compute_bal_hash (keccak of the SSZ bytes vs hash_tree_root), and where in the header does bal_hash sit?
- How are multiple code changes to one account in a block encoded when MAX_CODE_CHANGES = 1?
- What does 'Slots in pre-state but not written' mean for storage_reads?
- Is a balance that changes and then returns to its pre-transaction value within a transaction recorded? Is a zero-tip coinbase recorded?
- Are the MAX_TXS / MAX_SLOTS / MAX_ACCOUNTS bounds enforced as block-validity rules?
- How is the BAL carried over the Engine API?
Notable ambiguities noted by the assessor (6)
- The Edge Cases text says the system-contract index is transaction_count + 1, but process_system_contracts passes len(block.transactions) and comments 'tx_index = transaction_count'.
- The EIP-2935 address is given as 0x…0001 with slot (number-1) % 8191, and the EIP-4788 slots use % 8192. These cannot be checked against the prerequisite EIPs, which are not supplied.
- The EIP-7702 hyperlink points to eip-7792.md (Verifiable logs). EIP-7792 is not treated as a scheduled interaction.
- build_bal_from_accesses sorts storage_reads with key=lambda x: x.slot although the elements are raw keys. The example's storage_reads is bytes, not a list, and the example balance hex values do not match the stated ETH amounts.
- Nonce changes are listed for 'contracts that performed a successful CREATE', so failed CREATEs that still bump the nonce are ambiguous.
- 'Clients MAY invalidate immediately if any transaction exceeds declared state' is optional behaviour whose observable effect on the final validity outcome is unclear.
Criterion breakdown
| Criterion | Score | Why this score | Evidence / uncertainty |
|---|---|---|---|
| Cross-EIP interactionsExceptional | 4 | The BAL's expected contents depend jointly on EIP-2929/EIP-2930 access semantics, four system-contract EIPs and EIP-7702 delegation. Shared block vectors need coordinated scenarios that combine these, so level 3. |
Confidence: Medium Uncertainty: EIP-7792 is linked only via an apparent mislink for EIP-7702 and is not counted. Interacting EIPs: EIP-2929, EIP-2930, EIP-2935, EIP-4788, EIP-7002, EIP-7251, EIP-7702 |
| State-access ordering within opcode executionUnder-specified | 3 | The rubric counts which accesses enter the block-level access list. This EIP creates a block-wide definition of a recordable access that applies to every state-accessing opcode class: SLOAD/SSTORE, BALANCE/EXT*, CALL-family, CREATE/CREATE2 and SELFDESTRUCT. Each needs cases for cold/warm, reverted vs successful frames, out-of-gas before or after access, and static vs non-static calls. That is a definition change across operations, so level 3. |
Confidence: Medium Uncertainty: Gas-charge ordering itself does not change. A reading that the EIP only reuses EIP-2929 sets would support level 2. |
| New block / header fields | 3 | New execution-header member (bal_hash) and new block-body element, so level 3. |
Confidence: High |
| Encoding changes (RLP/SSZ) | 3 | The header schema, block body schema and a new SSZ BAL schema are all introduced, so level 3. |
Confidence: High |
| Block syncing changes | 3 | There are multiple new decode and validation rules: header field, body BAL decoding, SSZ list bounds and ordering. At least one, bal_hash equality with the execution-derived BAL, is complex, so level 3. |
Confidence: High |
| New test-framework primitivesUnder-specified | 3 | The framework's shared block model must include an SSZ BAL body element and the bal_hash header field. That changes how every blockchain-test family builds blocks, and invalid-BAL modifiers and BAL expectation abstractions are also needed. This is a shared representation that changes construction across families, so level 3. |
Confidence: Medium Uncertainty: If the BAL is produced purely by the client or t8n and checked only in BAL-specific tests, level 2 would suffice. |
| Security risksUnder-specified | 3 | A shared validation and trust invariant (BAL correctness) is consumed by block validation, parallel prefetch and execution, and executionless sync. Malicious BALs (missing, spurious, mis-ordered or with wrong values) need coordinated adversarial scenarios across these components, so level 3. |
Confidence: Medium Uncertainty: If clients only validate the BAL after full sequential execution, the risk narrows to level 2. |
| Performance risks | 3 | The change couples execution tracking (per-transaction diffs, including up to 24 KB code entries), SSZ encoding and hashing, block size and propagation, and parallel IO scheduling. Adversarial blocks that maximize accounts, slots or balance changes per gas need integrated stress testing across execution, networking and validation subsystems. Level 3. |
Confidence: Medium Uncertainty: The supplied size figures come from historical analysis. Worst-case adversarial composition is not quantified. |
| Edge/boundary conditions | 3 | Several boundary-sensitive mechanisms are introduced: list and size limits, MAX_CODE_CHANGES = 1, and the zero-value balance rule. Storage classification is an elevated matrix: whether the slot is read, whether the written value equals the original, zero vs non-zero, reverted vs committed frames, and multiple transactions touching the same slot all interact to decide between storage_changes, storage_reads and absence. Level 3. |
Confidence: Medium Uncertainty: Several of these outcomes are also under-specified (see UNSP). |
| Unspecified behavior requiring cross-client consensus | 3 | Which addresses and slots were accessed — including reverted frames, out-of-gas paths and pre-warmed sets — was previously unobservable and now becomes consensus-visible. The supplied rules give competing interpretations and outright contradictions (system/withdrawal transaction index, duplicate recording, hash function), so agreement on shared rules and re-baselining across opcode, system-call and withdrawal families are needed. Level 3. |
Confidence: High Uncertainty: Some apparent conflicts with EIP-2935/EIP-4788 addresses cannot be verified because those EIPs are not supplied. |
| Engine API changesUnder-specified | 2 | A new body element and header commitment would need to be carried in the execution payload exchanged with the CL, probably as multiple fields (BAL, bal_hash). Given the evidence gap, level 2 is the best-supported estimate. |
Confidence: Low Uncertainty: The supplied revision is silent on the Engine API. The actual change could range from one field to a new versioned endpoint plus fields (1–3). |
| Transition-tool interface changesUnder-specified | 2 | t8n must compute and output the block access list, and possibly its hash. That needs a new mechanism: block-wide access tracking across system calls, transactions and withdrawals. Treating the BAL and its hash as one semantic output gives level 2: a new mechanism with at most one field. |
Confidence: Medium Uncertainty: No t8n specification is supplied. If the BAL, bal_hash and a BAL input for validation count as separate fields, the score would be 3. |
| Patterns affecting pre-existing testsUnder-specified | 2 | Gas and execution results of baseline tests are unchanged. Tests that hand-construct block RLP or headers need reworked inputs: header-validation, RLP block-structure and invalid-block families, plus any fixtures with fixed block hashes. That is localized rework in several families without a common behavioral rewrite, so level 2. Adding the BAL assertion to ordinary tests is scored under INV. |
Confidence: Medium Uncertainty: Without a supplied test suite, the breadth of hand-crafted block fixtures is estimated. |
| New invariant on pre-existing tests | 2 | Every baseline blockchain test in the target fork must additionally produce and check a correct BAL/bal_hash. The rubric caps a universal assertion at level 2 unless pre-fork vectors must also be re-derived, and nothing supplied shows that. |
Confidence: High |
| Modified system contracts | 1 | Contract rules are unchanged. Only an indirect output convention changes: system-call diffs must be recorded in the BAL under a special index. Level 1. |
Confidence: Medium Uncertainty: The listed addresses and slots for EIP-2935 (0x…01, %8191) and EIP-4788 may conflict with those EIPs, which are not supplied. That is treated as an evidence gap or ambiguity, not as a modification. |
| New or modified transaction validity mechanismsUnder-specified | 1 | Transaction eligibility rules and intrinsic gas are unchanged. The only effect is an implicit bound from the BAL list limits on the transactions or state a block can hold, which is a local bound, so level 1. |
Confidence: Low Uncertainty: The text does not say whether the MAX_* limits are enforced as block validity rules. Plausible range 0–2. |
Show 12 zero-score criteria
| Criterion | Score | Why this score | Evidence / uncertainty |
|---|---|---|---|
| Added opcodes | 0 | Level 0. |
|
| Modified opcodes | 0 | Access recording alone does not count as a semantic change, so level 0. |
|
| Added precompiles | 0 | Level 0. |
|
| Modified precompiles | 0 | Level 0. |
Uncertainty: Whether precompile accesses appear in the BAL is an UNSP issue, not a precompile change. |
| Added system contracts | 0 | No new system contract, so level 0. |
|
| EVM Gas rule changes | 0 | No execution-gas accounting rule changes, so level 0. |
|
| Blob gas accounting changes | 0 | No blob-gas changes, so level 0. |
|
| State gas accounting changes | 0 | No state-gas accounting changes, so level 0. |
|
| New EVM gas refund | 0 | No new refund mechanism, so level 0. |
|
| New transaction types | 0 | Level 0. |
|
| New fork activation mechanism | 0 | No activation-specific state transition, so level 0. |
|
| CryptographyUnder-specified | 0 | Only a commitment to a new structure is added, presumably with an existing hash primitive. Changed hashed bytes belong under encoding, so level 0. |
Uncertainty: The hash function is unspecified. If SSZ hash_tree_root is required, which the EL baseline does not use, the score could be 1. |
Assessment provenance
- Assessed EIP revision
ethereum/EIPs@59be937534EIPS/eip-7928.md committed 2025-07-31 · information cutoff 2025-07-31T16:00:14Z- Rubric
- Checklist revision 3 ·
ethspecs/pm@fe2f793b03 - Evaluator
- Opus 5.5 (
claude-opus-5-5) at high effort, one tool-less call per EIP · isolationbubblewrap_claude_p_no_tools_v1 - Source record
- Frozen research record
research/tasks/10-opus-v3-reassessment/retrospective/outputs/assessments/amsterdam/eip-7928.yaml· sha25670712dc1ad41 - Supporting documents supplied with the EIP
supporting/eip-2929.md,supporting/eip-2930.md,supporting/eip-7792.md