Retrospective LLM-Based Complexity Evaluations

EIP complexity assessment

EIP-7709: Read BLOCKHASH from Storage and Update Cost

Assessed in Hegotá. The score describes the EIP text available at the snapshot, not the EIP as it stands today.

ProspectiveHegotáSnapshot 2026-10-07EIP-8081: CFILayers: execution
LLM Completescore 14
Human Available in open PRscore 17 · Checklist revision 2· ethspecs/pm #120
Other checklist versions (1)
LLM · Checklist revision 32026-10-08 · Opus 5.5 · snapshot · 14Human · Checklist revision 2Available in open PR · 17CompareHuman vs LLM · shared criteria

Evaluated on: · Spec revision: 2026-10-07 · 6dac5e7491 · EIP-8081 list: CFI

Scope at the cutoff. EIP-7709 changes how BLOCKHASH (0x40) resolves in-window lookups. From the fork block onward, a lookup for one of the last 256 ancestors is treated as an SLOAD of slot `arg % 8191` at the EIP-2935 HISTORY_STORAGE_ADDRESS. The opcode then charges the cold or warm SLOAD cost on top of the BLOCKHASH base cost, warms the slot, and applies any state-access recording the active fork requires. Out-of-window and future arguments still return 0 with no extra effects, and the return-value semantics are declared unchanged. Clients may resolve the value by direct SLOAD, by a non-system `get` call (whose execution gas is not charged) or from memory. The EIP assumes EIP-2935 was active at least 256 blocks earlier, or at genesis.

14MediumMedium
Evaluator
LLMChecklist v3
Confidence
Medium
Under-specified at assessment cutoff
Yes — 5 criteria affected
Plausible range
13–20 (Medium)
Snapshot
2026-10-07 · EIP revision 6dac5e7491 (2026-10-07)
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

  1. Modified system contracts2
  2. Patterns affecting pre-existing tests2
  3. Edge/boundary conditions2
  4. Cross-EIP interactions2

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 EIP says BLOCKHASH applies the full SLOAD effects but leaves several points open: whether the HISTORY_STORAGE_ADDRESS account (not just the slot) is warmed or recorded; the out-of-gas ordering between base and SLOAD charges and whether the access is recorded on failure; and which result is canonical when client-chosen resolution methods diverge because history storage is incomplete or the contract is absent.

Plausible total

13–20
recorded score 14 · plausible tiers Medium

Unresolved questions at the cutoff (4)
  • Does in-window BLOCKHASH warm or record the HISTORY_STORAGE_ADDRESS account address, changing the cold-account cost of a later CALL/BALANCE to it?
  • If the frame lacks gas for the SLOAD component, is the slot still recorded in the fork's state-access record?
  • When history storage disagrees with actual chain hashes (late EIP-2935 activation or missing contract), must clients return the storage value per the pseudocode, or the true hash?
  • How should arguments wider than uint64 be handled, given the pseudocode's uint64 typing?
Notable ambiguities noted by the assessor (3)
  • The 'MAY serve from memory' option is only equivalent to the normative pseudocode if history storage is complete and consistent; test fixtures (especially state tests with explicit environment block hashes) must keep these aligned.
  • Activation spacing: the text acknowledges a breaking change if fewer than 256 blocks pass between EIP-2935 and this EIP, but gives no rule for that case.
  • The base BLOCKHASH cost is not restated; the EIP only says the SLOAD cost is added to it.

Criterion breakdown

EIP-7709 Hegotá: LLM criterion scores and rationale
CriterionScoreWhy this scoreEvidence / uncertainty
Modified system contractsUnder-specified2The contract's code and rules are unchanged. However, opcode semantics now depend on its storage (a new state assumption), and BLOCKHASH warming changes the gas outcomes of later direct calls (an interaction). This goes beyond one local convention, so this is level 2.
  • eip.md · Reading from the System contract BLOCKHASH reads EIP-2935 storage without running contract code; a direct call still follows normal execution.
  • supporting/eip-2935.md · Gas costs — "first call to the contract will pay for warming up the account and storage slots" The baseline warm/cold assumptions for direct contract calls change once BLOCKHASH can warm slots.
  • eip.md · Backwards Compatibility — "system contract would not have saved the required history" BLOCKHASH correctness now depends on the state of the contract's storage.
Confidence: Medium
Uncertainty: Whether the contract account itself is warmed is unspecified.
Patterns affecting pre-existing tests2Ordinary cases throughout the BLOCKHASH family need new gas expectations and new access-recording expectations. Localized cases in other families also need rework: EIP-2935 direct-call tests that combine with BLOCKHASH (warm slot) and state tests whose environment block hashes must match history storage. There is no common rewrite across distinct families, so this is level 2.
  • eip.md · Backwards Compatibility — "significant increase in the cost of in-window BLOCKHASH queries" Baseline BLOCKHASH gas expectations change for all in-window lookups.
  • eip.md · Specification — "return state.load_slot(HISTORY_STORAGE_ADDRESS, arg % HISTORY_SERVE_WINDOW)" Returned values now come from history-contract storage, so test pre-states and environment block hashes must be consistent with that storage. Access-list expectations gain entries.
Confidence: Medium
Uncertainty: How many baseline fixtures use BLOCKHASH incidentally with tight gas or access-list expectations is not measurable without the supplied suite.
Edge/boundary conditions2Several boundary-sensitive mechanisms are involved: the window boundary that gates the new charge and access (combined with cold/warm), the activation-distance boundary relative to EIP-2935, and slot mapping across the 8191 ring-buffer wrap. Their dimensions can largely be tested independently, so there is no elevated matrix and this is level 2.
  • eip.md · Specification — "if arg >= block.number or (arg + BLOCKHASH_SERVE_WINDOW) < block.number: return 0" The window boundary now determines whether SLOAD gas and access effects apply.
  • eip.md · Activation Correctness depends on EIP-2935 being active at least 256 blocks earlier, or at genesis.
  • eip.md · Gas costs — "HISTORY_SERVE_WINDOW and BLOCKHASH_SERVE_WINDOW are different" The slot is computed modulo 8191 while the window is 256, which creates a ring-buffer wrap case.
Confidence: Medium
Uncertainty: Handling of arguments larger than uint64 (the pseudocode types arg as uint64) is an additional implicit edge.
Cross-EIP interactions2Coordinated cases with EIP-2935 are needed. These cover BLOCKHASH followed by a direct `get` call (and the reverse) for warm/cold slot and account gas, reverted-frame warming, consistency between the system call's set and BLOCKHASH reads, and activation spacing. The active fork's state-access recording is also involved. This is level 2.
  • eip.md · Test Cases — "If the EIP-2935 contract is called directly ..." Direct calls to the contract must keep normal semantics alongside BLOCKHASH effects.
  • supporting/eip-2935.md · Gas costs The first call to the contract pays for warming the account and slots, which interacts with slots BLOCKHASH has already warmed.
  • eip.md · Activation Activation spacing relative to EIP-2935 must be tested.
Confidence: Medium
Uncertainty: The access-recording and warm/cold EIPs are referenced only implicitly, not by number.
Interacting EIPs: EIP-2935
Unspecified behavior requiring cross-client consensus2Several localized details have competing plausible outcomes that clients must agree on before expected gas and access results can be fixed: account warming, out-of-gas ordering and recording, and inconsistent-storage resolution. This is level 2.
  • eip.md · Specification — "SLOAD after effects on the slot (warming the slot)" The text does not say whether the HISTORY_STORAGE_ADDRESS account is warmed or recorded, which affects later CALL/BALANCE costs on that address.
  • eip.md · Specification — "clients MAY choose to either" Allowed resolution methods give different values when storage is inconsistent with history (activation fewer than 256 blocks after EIP-2935, or the contract absent), and no canonical outcome is stated beyond the pseudocode.
  • eip.md · Specification — "def resolve_blockhash(block: Block, state: State, arg: uint64)" The out-of-gas ordering between the base charge and the SLOAD charge, and access recording on failure, are unspecified.
Confidence: Medium
Uncertainty: The active fork's SLOAD definition might resolve some of these by analogy, but that definition was not supplied.
EVM Gas rule changesUnder-specified1An existing opcode's gas rule changes from a constant cost to a cost that depends on access state. It reuses the existing cold/warm SLOAD accounting and adds no new accounting mechanism, so this is level 1.
  • eip.md · Gas costs In-window BLOCKHASH charges the corresponding SLOAD cold/warm cost for slot arg % HISTORY_SERVE_WINDOW in addition to the base cost.
  • eip.md · Reading from the System contract System-contract execution gas is not charged even if resolved via a call; only the SLOAD effect applies.
  • eip.md · Backwards Compatibility Significant increase in the cost of in-window BLOCKHASH queries.
Confidence: Medium
Uncertainty: Treating BLOCKHASH's move to access-dependent gas as a new charging site for an existing mechanism rather than a new mechanism is a judgement call. The warming of the account address is also unspecified.
State-access ordering within opcode executionUnder-specified1Exactly one existing opcode, BLOCKHASH, gains a storage access whose gas charge and access recording must be ordered (window check, then charge and access). No general rule for an opcode class changes, so this is level 1.
  • eip.md · Specification — "performs an sload on arg % HISTORY_SERVE_WINDOW including gas charges, warming effects as well as state-access recording" BLOCKHASH now performs a storage access with gas charging and state-access recording, but only after the window check.
  • eip.md · Test Cases — "returns 0 without applying additional storage access effects" Out-of-window calls must not record an access or warm the slot.
Confidence: Medium
Uncertainty: Two points are unstated: the order of base-gas and SLOAD-gas checks relative to recording on out-of-gas, and whether the history account itself is recorded or warmed. This could support level 2 if treated as a new state-accessing operation.
New test-framework primitives1Local extensions are needed: an access-dependent BLOCKHASH gas calculation in the fork gas model, and helpers to keep pre-state history storage aligned with environment block hashes. No new abstraction is required, so this is level 1.
  • eip.md · Specification — clients MAY do SLOAD, system call, or serve from memory Fixtures must keep history storage consistent with chain block hashes so that all resolution methods agree.
  • eip.md · Gas costs BLOCKHASH gas becomes cold/warm dependent.
Confidence: Medium
Uncertainty: This could be 0 if existing gas-calculation helpers already parameterize access state per opcode.
Security risksUnder-specified1The new condition is that the BLOCKHASH value and effects agree across resolution methods and match history storage. This can be checked locally, so this is level 1.
  • eip.md · Security Considerations No security considerations beyond those of EIP-2935 are stated.
  • eip.md · Specification — clients MAY choose resolution method Different resolution paths must yield identical values and effects, or a consensus split results.
Confidence: Medium
Uncertainty: Misconfigured networks where history storage diverges could make this a cross-component consensus issue (level 2).
Show 19 zero-score criteria
Zero-score criteria (Checklist revision 3)
CriterionScoreWhy this scoreEvidence / uncertainty
Added opcodes0No new opcode.
  • eip.md · Abstract Only the existing BLOCKHASH opcode is updated.
Modified opcodesUnder-specified0The changes are gas and access effects only, which the rubric excludes from this criterion.
  • eip.md · Specification — "The BLOCKHASH opcode semantics remains the same as before." Return values and stack behaviour are declared unchanged; only gas and access effects change.
  • eip.md · Backwards Compatibility — "does not change the return-value semantics" Explicitly confirms that return values are preserved.
Uncertainty: If storage diverges from chain history (activation fewer than 256 blocks after EIP-2935, or a missing contract), storage-based resolution would change return values. The text acknowledges this as a breaking case but declares semantics unchanged.
Added precompiles0None.
  • eip.md · Specification No precompile is added.
Modified precompiles0None.
  • eip.md · Specification No precompile changes.
Added system contracts0No new system contract.
  • eip.md · Specification — HISTORY_STORAGE_ADDRESS Reuses the existing EIP-2935 contract.
Blob gas accounting changes0No blob-gas rule changes.
  • eip.md · Specification Only BLOCKHASH resolution and gas are affected; blob gas is not mentioned.
State gas accounting changes0Cold/warm access charges belong under GAS. There are no state-write accounting changes.
  • eip.md · Gas costs Only SLOAD-style access charges are applied; no state writes or state-gas accounting.
New EVM gas refund0No new refund.
  • eip.md · Gas costs No refund mechanism is introduced.
New transaction types0None.
  • eip.md · Specification No transaction type is introduced.
New or modified transaction validity mechanisms0None.
  • eip.md · Specification Only opcode execution gas changes; no intrinsic gas or validity rule changes.
New block / header fields0None.
  • eip.md · Specification No header fields are added.
Encoding changes (RLP/SSZ)0None.
  • eip.md · Specification No serialized schema changes.
Block syncing changes0Only an execution rule changes.
  • eip.md · Specification No block decoding or structural validation changes.
New fork activation mechanism0The change is rule selection at the fork timestamp only, with no one-time state transition.
  • eip.md · Activation Assumes EIP-2935 was activated earlier; no migration or state installation at the fork.
Engine API changes0None.
  • eip.md · Specification No Engine API changes are mentioned.
Transition-tool interface changes0No interface field or mechanism change is required. Values come from pre-state storage that the tool already receives.
  • eip.md · Specification Resolution reads existing state; no new inputs or outputs are defined.
Uncertainty: Whether existing environment block-hash inputs must be reconciled with storage is a fixture-consistency issue, not an interface change. No tool evidence was supplied.
New invariant on pre-existing tests0No new output field or commitment is introduced. Additional access-recording entries are rework of existing expectations and are counted under PAT.
  • eip.md · Specification — "Any state-access recording required by the active fork" Recording uses the active fork's existing mechanism; extra entries are changed expected values, not a new output.
Performance risks0Gas rises to standard SLOAD pricing. This reduces the opcode's throughput and adds no workload under-priced relative to existing SLOAD assumptions, so no extra performance validation is established.
  • eip.md · Rationale — "updated gas cost matches the accessed resource" Pricing rises to match SLOAD, so the opcode's worst-case throughput falls.
Uncertainty: Clients that switch to trie-backed resolution may want a sanity benchmark, which could arguably justify level 1.
Cryptography0No cryptographic change.
  • eip.md · Specification No hashing or verification rule changes; block hashes are read from storage.
Assessment provenance
Assessed EIP revision
ethereum/EIPs@6dac5e7491 EIPS/eip-7709.md committed 2026-10-07 · information cutoff 2026-10-07T22:23:55Z
Current master · File history · blob 0c7c4c625e · sha256 ed806dda2e43
Rubric
Checklist revision 3 · ethspecs/pm@fe2f793b03
Evaluator
Opus 5.5 (claude-opus-5-5) at high effort, one tool-less call per EIP · isolation bubblewrap_claude_p_no_tools_v1
Source record
Frozen research record research/tasks/10-opus-v3-reassessment/prospective/outputs/assessments/hegota-2026-10-08/eip-7709.yaml · sha256 23ad03380a32
Supporting documents supplied with the EIP
supporting/eip-2935.md

Evaluated on: Not recorded

17MediumMedium
Evaluator
HumanChecklist v2
Confidence
Not recorded
Under-specified at assessment cutoff
Not recorded in the checklist
Checklist published
2026-08-24
Score bands · Checklist revision 2
  • 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 Human total. Hover or focus a segment for its score and rationale.

Top complexity drivers

  1. State-access ordering within opcode execution2
  2. Patterns affecting pre-existing tests2
  3. Edge/boundary conditions2
  4. Cross-EIP interactions2

Criterion breakdown

EIP-7709 Hegotá: Human criterion scores and rationale
CriterionScoreWhy this scoreNotes
State-access ordering within opcode execution2Only `BLOCKHASH` being impacted and now accounting for state access cost.—
Patterns affecting pre-existing tests2Most of the `BLOCKHASH` related tests need refactoring, but impact is limited (27 places under tests/ folder, excluding `tests/benchmark`)—
Edge/boundary conditions2Multiple interacting edge cases: (1) window boundary (`arg == block.number`, `> block.number`, `== 2**256-1`, `-1`, `-256 vs -257`), (2) young chain (`block.number < 256`, cold charge on unwritten slots), (3) modulus mismatch (`8191` vs `256`, `EIP-2935` slot warming), (4) cold/warm state (`EIP-2930` access lists, `SLOAD` collisions), (5) revert rollback and OOG at cold-charge boundary, (6) fork-transition window.—
Cross-EIP interactions24 interacting EIPs: EIP-2935 (hard dependency, ring-buffer state), EIP-2929 (cold/warm foundation), EIP-2930 (access list pre-warming), EIP-7928 (BAL recording). Test vectors need redesign.—
Unspecified behavior requiring cross-client consensus2(1) does the lookup add HISTORY_STORAGE_ADDRESS to accessed_addresses? (2) whether the account appears in the BAL account list when only a slot is read through the opcode, and whether the access is recorded when the opcode OOGs on the cold charge.—
Modified opcodes1BLOCKHASH now has state-access side effects: slot warming and state-access records, observable independently of gas. At activation, in-window lookups return 0 if < 256 blocks since EIP-2935 fork (vs pre-fork real hash).—
Modified system contracts1The history contract's code and state are not directly modified, but there's an indirect effect: `BLOCKHASH` warms the contract's storage slot, making subsequent `SLOAD` calls within `get()` warm. Conversely, `SLOAD` on that slot warms it for `BLOCKHASH`.—
EVM Gas rule changes1`BLOCKHASH` opcode gas costs now follow state access rules, accounting for cold/warm scenarios. This affects existing `BLOCKHASH` test cases but not other pre-existing scenarios. Given 1 point consider the impact should be limited.—
New invariant on pre-existing tests1Pre-existing tests that call `BLOCKHASH` for an in-window ancestor must now assert a storage-read entry for `HISTORY_STORAGE_ADDRESS` in the BAL and the post-call warmth of that slot—even though these tests aren't about access lists. This narrowly affects only tests that already touch `BLOCKHASH`—
New test-framework primitives1Add storage-access tracking to `BLOCKHASH`. Follow `Op.SLOAD(key_warm=...)` and integrate into fork gas map.—
Security risks1106x cost increase might break `BLOCKHASH` callers. Interacts with EIP-2929/BAL. "MAY" clause risks consensus divergence if warming/recording skipped. Needs targeted review and fuzz testing on state-access accounting.—
Performance risks1The new work reduces to an `SLOAD`, which is already benchmarked and already priced; the EIP strictly raises the cost of the operation, so worst-case throughput moves in the safe direction.—
Show 16 zero-score criteria
Zero-score criteria (Checklist revision 2)
CriterionScoreWhy this scoreNotes
Added opcodes0No opcode added—
Added precompiles0No added precompile—
Modified precompiles0No modified precompile—
Added system contracts0No system contracts added—
Blob gas accounting changes0No blob gas accounting changes.—
State gas accounting changes0No state gas accounting changes.—
New EVM gas refund0No new gas-refund mechanisms are introduced.—
New transaction types0No transaction types added—
New or modified transaction validity mechanisms0No changes to transaction validity mechanisms—
New block / header fields0No new block or header fields are introduced.—
Encoding changes (RLP/SSZ)0No encoding rules changes—
Block syncing changes0No block syncing changes—
New fork activation mechanism0No state modifications, internal variables or similar are modified at the fork activation block.—
Engine API changes0No engine API changes—
Transition-tool interface changes0No interface changes—
Cryptography0No cryptography mechanism added—
Assessment provenance
Rubric
Checklist revision 2 · ethspecs/pm@3d8c0128c5
Evaluator
STEEL team · ethspecs/pm complexity_assessments
Source record
Open pull request #120: Add EIP-7709 complexity assessment · checklist at e75fc8b75e · updated 2026-08-24
blob f9b1c0170d · sha256 5a2a2b3c9308
Research record
research/tasks/09-hegota-human-assessment-snapshot/outputs/assessments/eip-7709.yaml · sha256 3feafcaf1e70

The LLM applied checklist revision 3 and the human reviewers revision 2 to EIP-7709 in Hegotá. Revision 3 phrases the same criteria more precisely; differences cover the 28 criteria both revisions share, and each total keeps its own revision. Δ is LLM minus Human.

Using the latest scored LLM evaluation for this checklist: 2026-10-08 · spec 2026-10-07 · 6dac5e7491. The Human and LLM assessments may use different spec revisions.

LLM14Medium
Human17Medium
Δ total−3Same tier
Criteria23/28agree exactly · 5 differ by 1 · 0 differ by 2+

Complexity profiles side by side

LLM
Human

Largest disagreements: State-access ordering within opcode execution (−1), New invariant on pre-existing tests (−1), Modified system contracts (+1), Modified opcodes (−1), Performance risks (−1)

Per-criterion scores, Human versus LLM, ordered by the size of the difference
CriterionLLMHumanΔAgreementRationale from each source
Modified opcodes01−1Differ by 1
Show rationale

LLM The changes are gas and access effects only, which the rubric excludes from this criterion.

Human BLOCKHASH now has state-access side effects: slot warming and state-access records, observable independently of gas. At activation, in-window lookups return 0 if < 256 blocks since EIP-2935 fork (vs pre-fork real hash).

Modified system contracts21+1Differ by 1
Show rationale

LLM The contract's code and rules are unchanged. However, opcode semantics now depend on its storage (a new state assumption), and BLOCKHASH warming changes the gas outcomes of later direct calls (an interaction). This goes beyond one local convention, so this is level 2.

Human The history contract's code and state are not directly modified, but there's an indirect effect: `BLOCKHASH` warms the contract's storage slot, making subsequent `SLOAD` calls within `get()` warm. Conversely, `SLOAD` on that slot warms it for `BLOCKHASH`.

State-access ordering within opcode execution12−1Differ by 1
Show rationale

LLM Exactly one existing opcode, BLOCKHASH, gains a storage access whose gas charge and access recording must be ordered (window check, then charge and access). No general rule for an opcode class changes, so this is level 1.

Human Only `BLOCKHASH` being impacted and now accounting for state access cost.

New invariant on pre-existing tests01−1Differ by 1
Show rationale

LLM No new output field or commitment is introduced. Additional access-recording entries are rework of existing expectations and are counted under PAT.

Human Pre-existing tests that call `BLOCKHASH` for an in-window ancestor must now assert a storage-read entry for `HISTORY_STORAGE_ADDRESS` in the BAL and the post-call warmth of that slot—even though these tests aren't about access lists. This narrowly affects only tests that already touch `BLOCKHASH`

Performance risks01−1Differ by 1
Show rationale

LLM Gas rises to standard SLOAD pricing. This reduces the opcode's throughput and adds no workload under-priced relative to existing SLOAD assumptions, so no extra performance validation is established.

Human The new work reduces to an `SLOAD`, which is already benchmarked and already priced; the EIP strictly raises the cost of the operation, so worst-case throughput moves in the safe direction.

Added opcodes000Agree
Show rationale

LLM No new opcode.

Human No opcode added

Added precompiles000Agree
Show rationale

LLM None.

Human No added precompile

Modified precompiles000Agree
Show rationale

LLM None.

Human No modified precompile

Added system contracts000Agree
Show rationale

LLM No new system contract.

Human No system contracts added

EVM Gas rule changes110Agree
Show rationale

LLM An existing opcode's gas rule changes from a constant cost to a cost that depends on access state. It reuses the existing cold/warm SLOAD accounting and adds no new accounting mechanism, so this is level 1.

Human `BLOCKHASH` opcode gas costs now follow state access rules, accounting for cold/warm scenarios. This affects existing `BLOCKHASH` test cases but not other pre-existing scenarios. Given 1 point consider the impact should be limited.

Blob gas accounting changes000Agree
Show rationale

LLM No blob-gas rule changes.

Human No blob gas accounting changes.

State gas accounting changes000Agree
Show rationale

LLM Cold/warm access charges belong under GAS. There are no state-write accounting changes.

Human No state gas accounting changes.

New EVM gas refund000Agree
Show rationale

LLM No new refund.

Human No new gas-refund mechanisms are introduced.

New transaction types000Agree
Show rationale

LLM None.

Human No transaction types added

New or modified transaction validity mechanisms000Agree
Show rationale

LLM None.

Human No changes to transaction validity mechanisms

New block / header fields000Agree
Show rationale

LLM None.

Human No new block or header fields are introduced.

Encoding changes (RLP/SSZ)000Agree
Show rationale

LLM None.

Human No encoding rules changes

Block syncing changes000Agree
Show rationale

LLM Only an execution rule changes.

Human No block syncing changes

New fork activation mechanism000Agree
Show rationale

LLM The change is rule selection at the fork timestamp only, with no one-time state transition.

Human No state modifications, internal variables or similar are modified at the fork activation block.

Engine API changes000Agree
Show rationale

LLM None.

Human No engine API changes

Transition-tool interface changes000Agree
Show rationale

LLM No interface field or mechanism change is required. Values come from pre-state storage that the tool already receives.

Human No interface changes

Patterns affecting pre-existing tests220Agree
Show rationale

LLM Ordinary cases throughout the BLOCKHASH family need new gas expectations and new access-recording expectations. Localized cases in other families also need rework: EIP-2935 direct-call tests that combine with BLOCKHASH (warm slot) and state tests whose environment block hashes must match history storage. There is no common rewrite across distinct families, so this is level 2.

Human Most of the `BLOCKHASH` related tests need refactoring, but impact is limited (27 places under tests/ folder, excluding `tests/benchmark`)

New test-framework primitives110Agree
Show rationale

LLM Local extensions are needed: an access-dependent BLOCKHASH gas calculation in the fork gas model, and helpers to keep pre-state history storage aligned with environment block hashes. No new abstraction is required, so this is level 1.

Human Add storage-access tracking to `BLOCKHASH`. Follow `Op.SLOAD(key_warm=...)` and integrate into fork gas map.

Security risks110Agree
Show rationale

LLM The new condition is that the BLOCKHASH value and effects agree across resolution methods and match history storage. This can be checked locally, so this is level 1.

Human 106x cost increase might break `BLOCKHASH` callers. Interacts with EIP-2929/BAL. "MAY" clause risks consensus divergence if warming/recording skipped. Needs targeted review and fuzz testing on state-access accounting.

Edge/boundary conditions220Agree
Show rationale

LLM Several boundary-sensitive mechanisms are involved: the window boundary that gates the new charge and access (combined with cold/warm), the activation-distance boundary relative to EIP-2935, and slot mapping across the 8191 ring-buffer wrap. Their dimensions can largely be tested independently, so there is no elevated matrix and this is level 2.

Human Multiple interacting edge cases: (1) window boundary (`arg == block.number`, `> block.number`, `== 2**256-1`, `-1`, `-256 vs -257`), (2) young chain (`block.number < 256`, cold charge on unwritten slots), (3) modulus mismatch (`8191` vs `256`, `EIP-2935` slot warming), (4) cold/warm state (`EIP-2930` access lists, `SLOAD` collisions), (5) revert rollback and OOG at cold-charge boundary, (6) fork-transition window.

Cryptography000Agree
Show rationale

LLM No cryptographic change.

Human No cryptography mechanism added

Cross-EIP interactions220Agree
Show rationale

LLM Coordinated cases with EIP-2935 are needed. These cover BLOCKHASH followed by a direct `get` call (and the reverse) for warm/cold slot and account gas, reverted-frame warming, consistency between the system call's set and BLOCKHASH reads, and activation spacing. The active fork's state-access recording is also involved. This is level 2.

Human 4 interacting EIPs: EIP-2935 (hard dependency, ring-buffer state), EIP-2929 (cold/warm foundation), EIP-2930 (access list pre-warming), EIP-7928 (BAL recording). Test vectors need redesign.

Unspecified behavior requiring cross-client consensus220Agree
Show rationale

LLM Several localized details have competing plausible outcomes that clients must agree on before expected gas and access results can be fixed: account warming, out-of-gas ordering and recording, and inconsistent-storage resolution. This is level 2.

Human (1) does the lookup add HISTORY_STORAGE_ADDRESS to accessed_addresses? (2) whether the account appears in the BAL account list when only a slot is read through the opcode, and whether the access is recorded when the opcode OOGs on the cold charge.

Compare EIP-7709 with other assessmentsAll Hegotá assessments
Criterion legend and glossary

Every stacked bar, comparison matrix, and criterion table on this site uses the same criterion colours, abbreviations, and order. Colour marks the criterion group; the abbreviation and name identify the criterion. Scores are 0–3 per criterion (4 is exceptional; cross-EIP interactions is uncapped).

EVM surface

Opcodes, precompiles, and system contracts that are added or modified.

  • Added opcodes
    Introduces new opcodes
    Score anchors
    0
    No new opcodes are introduced.
    1
    A new simple opcode is introduced (no data portion, no complex stack mechanics, and a constant gas cost).
    2
    Multiple new simple opcodes are introduced, or a single new complex opcode is introduced (has data portion, or complex stack mechanics, or a dynamic gas cost).
    3
    Multiple new opcodes are introduced, and at least one of them is complex (has data portion, or complex stack mechanics, or a dynamic gas cost).
    • Cryptography opcodes are not considered complex by default. Refer to the "Cryptography" section for a separate assessment.
  • Modified opcodes
    Modifies pre-existing opcodes
    Score anchors
    0
    No pre-existing opcode modifications are introduced.
    3
    At least one pre-existing opcode's behavior is modified (not including gas changes) or a pre-existing opcode is deprecated.
  • Added precompiles
    Introduces new precompiles
    Score anchors
    0
    No new precompiles are introduced.
    1
    A new simple precompile is introduced (constant input length, constant gas cost).
    2
    Multiple new simple precompiles are introduced, or a single new complex precompile is introduced (dynamic input length or dynamic gas cost).
    3
    Multiple new precompiles are introduced, and at least one of them is complex (dynamic input length or dynamic gas cost).
    • Cryptography precompiles are not considered complex by default. Refer to the "Cryptography" for a separate assessment.
  • Modified precompiles
    Modifies pre-existing precompiles logic or gas-accounting
    Score anchors
    0
    No pre-existing precompiles are modified.
    1
    At least one pre-existing precompile has its gas schedule modified.
    2
    Multiple pre-existing precompiles have their gas schedule modified, or a single pre-existing precompile has its behavior modified.
    3
    The behavior of multiple pre-existing precompiles, or a single complex pre-existing precompile modified.
  • Added system contracts
    Introduces new system contract, stateful or not
    Score anchors
    0
    No new system contracts are introduced.
    1
    A new system contract is introduced that is not stateful nor does it trigger a new system action (e.g. requests to the consensus layer).
    2
    Multiple new system contracts are introduced or a single new system contract that is either stateful or triggers a new system action (e.g. requests to the consensus layer).
    3
    Multiple new system contracts are introduced and at least one of them is either stateful or triggers a new system action (e.g. requests to the consensus layer).
  • Modified system contracts
    Modifies pre-existing system contracts
    Score anchors
    0
    No modifications to pre-existing system contracts are introduced, directly or indirectly.
    1
    Does not directly modify any system contract, but its behavior has minor indirect effects on one or more system contracts.
    2
    Does not directly modify any system contract, but its behavior has major indirect effects on one or more system contracts.
    3
    At least one pre-existing system contract code or state is modified, which would involve irregular state transition or a similarly complex transition methodology.

Gas and accounting

Execution, blob, and state gas rules, refunds, and where charges happen inside opcodes.

  • EVM Gas rule changes
    New EVM gas accounting rules
    Score anchors
    0
    No gas accounting changes.
    1
    Existing gas accounting mechanism is updated.
    2
    A new gas accounting mechanism is introduced but it does not affect existing mechanisms nor does it affect existing tests.
    3
    A new gas accounting mechanism is introduced and affects existing mechanisms which in turn affect existing tests.
  • State-access ordering within opcode execution · not in checklist revision 1
    Changes *where inside an opcode's execution* state is accessed, or where gas is charged relative to that access. Because a state access is recorded in the block-level access list only if execution had enough gas to reach it, this ordering is consensus-critical: moving it changes the BAL at every gas boundary of every affected opcode.
    Score anchors
    0
    No change to where state is accessed, or to where gas is charged relative to a state access, within any opcode.
    1
    A single opcode's state-access or gas-charge ordering changes.
    2
    Multiple opcodes' ordering changes, or a new state-accessing operation is introduced whose position in the order must be settled.
    3
    The ordering rule changes for a whole class of state-accessing opcodes at once, or what counts as a recordable state access is redefined — requiring existing BAL vectors to be re-derived across opcodes and forks.
    • Distinct from "Modified opcodes", which asks whether an opcode's **result** changed. This row asks about the **path to the result**, which is observable even when the result is identical. An EIP can be 0 on that row and 3 on this one.
    • Score changes **to** the ordering. Do not score the fact that state accesses are observable — they always are.
    • Each boundary must be re-tested against every other dimension that can change the answer (cold/warm, static/non-static, delegated/direct, revert/success), so the case count grows multiplicatively rather than additively. Note this explicitly under Special Considerations.
  • Blob gas accounting changes
    New Blob gas accounting rules which potentially affect pre-existing tests
    Score anchors
    0
    No blob gas accounting changes.
    1
    Existing blob gas accounting mechanism is updated.
    2
    A new blob gas accounting mechanism is introduced but it does not affect existing mechanisms nor does it affect existing tests.
    3
    A new blob gas accounting mechanism is introduced and affects existing mechanisms which in turn affect existing tests.
  • State gas accounting changes · not in checklist revision 1
    New state gas accounting rules. State gas is the cost of *writing* state, as opposed to accessing or executing it: `StateGasCosts`, `COST_PER_STATE_BYTE`, the block-level state gas budget, and the spill path into execution gas.
    Score anchors
    0
    No state gas accounting changes.
    1
    An existing state gas cost or `STATE_BYTES_PER_*` rate is adjusted.
    2
    A new state-gas-charging site is introduced, or the block-level state gas budget or reservoir allocation is modified.
    3
    A new state gas charging mechanism is introduced, or the spill interaction between state gas and execution gas is modified, affecting existing gas tests.
    • Harder to test than blob gas: the spill path means state gas cannot be metered independently of execution gas, and some costs (e.g. `NEW_ACCOUNT`) are state-dependent.
  • New EVM gas refund
    New gas-refund mechanism
    Score anchors
    0
    No new gas-refund mechanisms are introduced.
    1
    A new simple gas-refund mechanism is introduced that does not affect either existing tests or existing gas-refund mechanisms.
    2
    A new complex gas-refund mechanism is introduced or a simple mechanism that affects existing tests or existing gas-refund mechanisms.
    3
    A new complex gas-refund mechanism is introduced that affects existing tests or existing gas-refund mechanisms.

Blocks, transactions, and encoding

Transaction types and validity, block and header fields, encodings, syncing, and activation-time changes.

  • New transaction types
    Introduces a new transaction type
    Score anchors
    0
    No new transaction types are introduced.
    3
    A new transaction type is introduced.
  • New or modified transaction validity mechanisms
    Creates new or modifies pre-existing transaction types' validation mechanisms
    Score anchors
    0
    No changes are introduced to the validity rules of existing transaction types or to their intrinsic gas cost calculation.
    1
    Minor adjustments are introduced to validity rules or intrinsic gas cost calculation, but they do not significantly affect existing tests.
    2
    Changes to validity rules or intrinsic gas cost calculation affect existing tests, but require only limited updates to test cases and no redesign of the testing infrastructure.
    3
    Changes to validity rules or intrinsic gas cost calculation require extensive rework or redesign of the tests or testing infrastructure.
  • New block / header fields
    Introduces new block or block header fields
    Score anchors
    0
    No new block or header fields are introduced.
    3
    A new block or header field is introduced.
  • Encoding changes (RLP/SSZ)
    Introduces encoding changes at the transaction/block/interfaces level
    Score anchors
    0
    No encoding changes are introduced at the transaction, block, or interfaces levels.
    3
    An encoding change is introduced at transaction, block or interfaces level (e.g. RLP -> SSZ).
    • "Interfaces level" includes the Engine API. Score an Engine API encoding change (e.g. JSON -> SSZ) here.
  • Block syncing changes
    Modifies block RLP validation mechanisms that require test client syncing.
    Score anchors
    0
    No new RLP validation mechanism is introduced.
    1
    A single simple RLP validation mechanism is introduced.
    2
    Multiple simple RLP validation mechanisms are introduced or a single complex one.
    3
    Multiple RLP validation mechanisms are introduced and at least one of them is deemed complex.
  • New fork activation mechanism
    Modifies state, internal variables, or similar, at the fork activation block
    Score anchors
    0
    No state modifications, internal variables or similar are modified at the fork activation block.
    3
    Either a state modification or internal variables are modified at the fork activation block.
    • Initialization of new internal variable is not considered a modification.

Client interfaces

Engine API and transition-tool interface changes.

  • Engine API changes
    Introduces new fields to the Engine API directives
    Score anchors
    0
    No new fields or communication mechanisms are introduced to the Engine API.
    1
    A single new field is introduced in one of the Engine API endpoints.
    2
    Multiple fields are introduced to one or multiple Engine API end points, or a new Engine API end-point is introduced.
    3
    Multiple fields are introduced to one or multiple Engine API end points and a new Engine API end-point is introduced.
  • Engine API encoding changes · Checklist revision 1 only
    Engine API encoding changes (the revision-1 template defines no anchor text for this row).
  • Transition-tool interface changes
    Modifies or adds new fields to the transition tool interface.
    Score anchors
    0
    No modifications to the transition tool interface are required.
    1
    A single new field needs to be introduced to the transition tool interface.
    2
    Multiple new fields or a new mechanism has to be introduced to the transition tool interface.
    3
    Multiple new fields and a new mechanism has to be introduced to the transition tool interface.
    • Special consideration must be paid to this section if the EIP introduces a mechanism that requires the state transition tool to be aware whether the block it is processing is the fork-activation block.

Testing impact

Rework, new invariants, and new primitives required in the test framework.

  • Patterns affecting pre-existing tests
    Implements a new validation mechanism or rule that translates in reworking pre-existing tests
    Score anchors
    0
    No pre-existing tests are affected by this change.
    1
    Minor subset of existing tests are affected by this change.
    2
    Considerable subset of existing tests are affected by this change but involves only a contrived category of tests.
    3
    Major subset of existing tests are affected, including diverse category of tests (benchmarks, static, multiple forks, etc.).
  • New invariant on pre-existing tests · not in checklist revision 1
    Tests that are **not about this EIP** must nonetheless assert something this EIP produces. Their logic does not change; they gain a new thing to check.
    Score anchors
    0
    Pre-existing tests assert nothing new.
    1
    A narrow, contrived category of pre-existing tests gains a new assertion.
    2
    A broad category gains a new assertion, applied mechanically.
    3
    Every test in the fork gains the assertion regardless of what it tests, and pre-fork vectors must be re-derived to satisfy it.
    • Paired with the row above, and easy to confuse with it. "Patterns affecting pre-existing tests" asks whether existing tests must be **reworked**; this row asks whether they must **additionally assert something new**. Score both — an EIP can be low on one and high on the other.
  • New test-framework primitives · not in checklist revision 1
    Requires new abstractions in the test framework itself — expectation types, modifiers, helpers — beyond writing test functions with what already exists.
    Score anchors
    0
    Existing test primitives suffice.
    1
    Existing primitives need minor extension.
    2
    New expectation or modifier primitives are required, reusable within this EIP's own test suite.
    3
    New framework-level primitives are required that become a permanent part of the framework and are used by other EIPs' tests.

Risk and validation

Security, performance, boundary conditions, and cryptography that need validation.

  • Security risks
    Introduces or modifies mechanisms that could compromise the security of the chain, users, validators, or other stakeholders, if not implemented properly.
    Score anchors
    0
    No new mechanisms are introduced that could pose a security risk.
    1
    The introduced mechanisms are self-contained, can be validated in isolation, and do not alter existing invariants that could pose a security risk for any stakeholders.
    2
    The introduced mechanisms interact with a limited number of existing components, slightly altering their security assumptions and requiring a targeted security review or fuzzing.
    3
    The introduced mechanisms interact with multiple existing components, including critical ones, substantially altering their security assumptions and requiring an extensive security review and fuzzing.
  • Performance risks
    Introduces or modifies mechanisms and requires performance validation.
    Score anchors
    0
    No new mechanisms are introduced that require performance validation.
    1
    The introduced mechanisms can be benchmarked in isolation and do not affect existing performance behavior.
    2
    The introduced mechanisms cannot be fully benchmarked in isolation, but they only have a limited impact on the existing performance benchmarks.
    3
    The introduced mechanisms cannot be benchmarked in isolation and have a substantial impact on existing performance benchmarks or have complex interactions with existing mechanisms.
  • Edge/boundary conditions
    Feature contains edge/boundary conditions.
    Score anchors
    0
    No discernible edge cases or boundary conditions are introduced.
    1
    A single edge-case or boundary-condition prone mechanism is introduced.
    2
    Multiple edge-case or boundary-condition prone mechanisms are introduced, but none of them requires an elevated number of cases to test.
    3
    Multiple edge-case or boundary-condition prone mechanisms are introduced and at least one of them requires an elevated number of cases to test.
  • Cryptography
    Introduces new cryptography mechanisms or modifies existing functionality that involves cryptography
    Score anchors
    0
    No cryptography mechanisms are introduced.
    1
    A new cryptography mechanism is introduced but it is a well known mechanism that is known to have vast resources to aid on its testing.
    2
    Multiple new cryptography mechanisms are introduced that are well-known or a single but novel mechanism is introduced that is either untested or has limited resources.
    3
    Multiple new cryptography mechanisms are introduced and at least one of them is a novel mechanism.

Coordination

Cross-EIP interactions and behavior that clients must agree on before tests exist.

  • Cross-EIP interactions
    Introduces or modifies mechanisms that affect other EIPs in either the same or past forks.
    Score anchors
    0
    Fully self-contained EIP that does not depend on, modify, or conflict with any other EIP.
    1
    The EIP interacts with one or more other EIPs in a non-critical and limited way but can be tested independently for the most part.
    2
    The EIP depends on or modifies one or more other EIPs such that coordinated testing and consideration is required, but interactions are limited in scope and not complex.
    3
    The EIP has strong interdependencies with multiple EIPs, requiring extensive coordinated cross-EIP testing as well as potential re-design of existing test vectors.
    • +1 for every 3 additional interacting EIPs beyond the first 3, each of which requires its own coordinated test cases. List the EIPs in the rationale.
    • This row is intentionally uncapped, unlike every other anchor: each interacting EIP is another axis of the test matrix, so a ceiling would make a 12-EIP product indistinguishable from a 3-EIP one.
  • Unspecified behavior requiring cross-client consensus · not in checklist revision 1
    The EIP text does not determine the answer for cases a test can construct. Clients must agree on a previously unspecified detail before tests can be baselined. The cost here is coordination and re-baselining, not test writing.
    Score anchors
    0
    The EIP text determines the answer for every case a test could construct.
    1
    A few details are unspecified but have an obvious intended reading.
    2
    Details require client agreement before tests can be written, but they are localized.
    3
    A previously unspecified *and previously unobservable* behavior becomes consensus-critical; expect tests to be re-baselined on each round of EIP amendment.
    • Score this from the EIP's state at assessment time: whether it has client implementations, whether it has been through a devnet, and how many open questions remain on its discussion thread.