Skip to content

test(amsterdam): stipend+1 SSTORE BAL boundary, refresh test_cases.md - #15

Closed
nerolation wants to merge 8 commits into
gurukamath:eip-7928/frontload-access-check-sstorefrom
nerolation:sstore-access-check-additions
Closed

nerolation wants to merge 8 commits into
gurukamath:eip-7928/frontload-access-check-sstorefrom
nerolation:sstore-access-check-additions

Conversation

@nerolation

Copy link
Copy Markdown

Add a stipend+1 boundary case to test_bal_sstore_and_oog, pinning that clearing the EIP-2200 sentry alone no longer records the slot in the BAL, and refresh the stale test_cases.md row.

danceratopz and others added 8 commits June 19, 2026 00:34
…thereum#2972)

Co-authored-by: Sam Wilson <57262657+SamWilsn@users.noreply.github.com>
Co-authored-by: Mario Vega <11726710+marioevz@users.noreply.github.com>
)

Co-authored-by: danceratopz <danceratopz@gmail.com>
Co-authored-by: marioevz <marioevz@gmail.com>
…thereum#3044)

EIP-8246 removes the `SELFDESTRUCT` balance burn, which changes the
same-transaction self-destruct-to-self outcome. Gate the affected
expectations in `test_selfdestruct_gas.py` on `fork.is_eip_enabled(8246)`
so the test holds on forks with and without EIP-8246:

- Pre-EIP-8246: The originator balance is burnt (a `Burn` log) and the
  same-transaction-created account is deleted.
- EIP-8246 onwards: The burn is removed, so the self-send is a no-op; the
  balance stays in the (emptied) originator and no log is emitted.

`burn_log` is imported lazily in the pre-EIP-8246 branch because EIP-8246
deletes the helper from the EIP-7708 spec. The charged gas is unchanged,
so `cumulative_gas_used` is asserted identically on both sides.
…zero balance precompile (ethereum#3048)

* fix(amsterdam): charge NEW_ACCOUNT for value transfer to empty precompile

EIP-2780 charges the NEW_ACCOUNT state cost when a transaction
transfers value to a recipient that is empty per EIP-161. The
top-frame charge previously carved out precompile recipients, but
neither EIP-2780 nor EIP-161 authorizes that exemption:

- EIP-2780 does not mention precompiles; its rule keys solely on
  "empty per EIP-161 and tx.value > 0".
- EIP-161 defines empty structurally (no code, zero nonce, zero
  balance) with no precompile exception, so an unfunded precompile
  is empty and is created by the value transfer like any other
  account.

Remove the `recipient_is_precompile` carve-out from the top-frame
charge so an empty precompile receiving value pays NEW_ACCOUNT,
drop the matching special-case from the testing framework's
`transaction_top_frame_state_gas`, and rewrite
`test_value_move_to_precompiles` to assert the charge fires for the
not-funded precompile while a pre-funded (alive) precompile remains
exempt by virtue of being non-empty.

Co-authored-by: danceratopz <danceratopz@gmail.com>
… read

Post EIP-8038 the cold storage access cost (3000) exceeds the EIP-2200 call stipend (2300), so clearing the stipend sentry no longer guarantees the access cost is affordable. The implicit storage read in SSTORE records the slot into the EIP-7928 Block Access List, and that record survives frame rollback. With gas_left in (stipend, access_cost), the old ordering recorded a phantom read for an SSTORE that then ran out of gas on the access cost itself.

Compute the access cost first and check it (alongside the stipend sentry) before the read, warming the slot only once the access is affordable -- mirroring the CALL opcode and matching SLOAD, which already charges access before reading.

Pivot test_bal_sstore_and_oog OOG boundaries on the access cost instead of the stipend, and refresh the test_sstore_stipend_check_excludes_reservoir docstring.
@nerolation

Copy link
Copy Markdown
Author

This is to add to ethereum#3064

@gurukamath
gurukamath force-pushed the eip-7928/frontload-access-check-sstore branch 2 times, most recently from 1768ac2 to 4d0bec2 Compare July 6, 2026 15:01
@gurukamath

Copy link
Copy Markdown
Owner

The PR had to be re-based and resulted in this having conflicts as well. I have cherry-picked the changes onto the original branch and will close this.

@gurukamath gurukamath closed this Jul 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants