feat(spec, spec-specs): EIP-7997 by kclowes · Pull Request #2802 · ethereum/execution-specs

kclowes · 2026-05-04T20:32:34Z

🗒️ Description

EIP-7997 implementation and tests

🔗 Related Issues or PRs

#1988

✅ Checklist

All: Ran fast static checks to avoid unnecessary CI fails, see also Code Standards and Enabling Pre-commit Checks:
```
just static
```
All: PR title adheres to the repo standard - it will be used as the squash commit message and should start type(scope):.
All: Considered updating the online docs in the ./docs/ directory.
All: Set appropriate labels for the changes (only maintainers can apply labels).
Tests: Ran mkdocs serve locally and verified the auto-generated docs for new tests in the Test Case Reference are correctly formatted.
~~[ ] Tests: For PRs implementing a missed test case, update the post-mortem document to add an entry the list.~~
~~[ ] Ported Tests: All converted JSON/YML tests from ethereum/tests or tests/static have been assigned @ported_from marker.~~

Cute Animal Picture

codecov · 2026-05-04T21:06:39Z

Codecov Report

❌ Patch coverage is 50.00000% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.50%. Comparing base (6137bb3) to head (9f9e080).

Files with missing lines	Patch %	Lines
src/ethereum/forks/amsterdam/fork.py	50.00%	2 Missing ⚠️

Additional details and impacted files

@@                     Coverage Diff                     @@
##           eips/amsterdam/eip-7997    #2802      +/-   ##
===========================================================
- Coverage                    90.50%   90.50%   -0.01%     
===========================================================
  Files                          535      535              
  Lines                        32407    32411       +4     
  Branches                      3011     3011              
===========================================================
+ Hits                         29331    29333       +2     
- Misses                        2559     2561       +2     
  Partials                       517      517

Flag	Coverage Δ
unittests	`90.50% <50.00%> (-0.01%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

petertdavies · 2026-05-07T12:38:00Z

Deploying a system contract in the precompile range has the potential to cause weird bugs in clients that have longstanding hardcoded assumptions that the 0x01-0xff range is only precompiles. This isn't a precompile, it's just a regular contract. The level of testing required is higher than might superficially appear from the EIP.

The included tests look pretty good, but I could think of few more:

Test the interaction between 0x12 and access list prewarming. The EIP is silent on prewarming, as written this PR does not prewarm.
Try CALLCODEing it.
Give it a balance using SELFDESTRUCT.

kclowes · 2026-05-07T17:10:34Z

Thanks @petertdavies! I will add those! It is very strange that this is in the precompile range, but is not a precompile.

marioevz

Looks great so far, a few comments. Thanks!

marioevz · 2026-05-08T13:33:45Z

+        ref:ethereum.forks.amsterdam.fork.DETERMINISTIC_FACTORY_ADDRESS
+
    """
+    code_hash = store_code(old.state, DETERMINISTIC_FACTORY_CODE)


Interesting, I did not know we had this functionality!

I'm not sure though how do we signal from the tests that a block is the first block in the fork?

@marioevz I'm not sure what you mean by:

I'm not sure though how do we signal from the tests that a block is the first block in the fork?

Can you clarify? AFAIK, the tests don't call apply_fork, and AIUI, we'd have to test with a pre_alloc mutable as discussed below, for inherently not a great test. This is also highlighted in the codecov report since there is not a great way to test this method. Let me know if you see another way though! I'm happy to update.

marioevz · 2026-05-08T13:36:06Z

+REFERENCE_SPEC_GIT_PATH = ref_spec_7997.git_path
+REFERENCE_SPEC_VERSION = ref_spec_7997.version
+
+pytestmark = pytest.mark.valid_from("Amsterdam")


Suggested change

pytestmark = pytest.mark.valid_from("Amsterdam")

pytestmark = pytest.mark.valid_from("EIP7997")

We should test the transition to the fork where this EIP is enabled, but that circles back to my question on the first comment since I'm not really sure how we signal this in the t8n. Maybe @gurukamath has more insight.

I think that the best we can do is do a pre_alloc_mutable and do something like: pre[0x12] - Account(code=b"", nonce=0, balance=0, and assert that you can call the contract, and it returns success for the call, but it doesn't return anything else. It looks like we do a similar thing here. I'm not sure how much value that test really adds though.

I dont fully understand here, why couldnt we test this state transition like other eip? Using block 14,999 -> 15,000 -> 15,001. We could just do EXTCODEHASH, EXTCODESIZE, EXTCODECOPY to the contract and compare the result across these three blocks?

kclowes · 2026-05-11T17:44:27Z

@marioevz @petertdavies @LouisTsai-Csie - this is ready for another look when you get a chance. I added the tests @petertdavies suggested.

I'm not sure how to raise the question of whether this contract should be prewarmed - is that something that we'd generally put into the tests and see which clients fail or is it something we'd bring up in a sync call or comment on the EIP?

Edit to add: I don't think there is a way around the apply_fork coverage fail, but very happy to hear suggestions!

LouisTsai-Csie · 2026-05-19T05:12:37Z

Deploying a system contract in the precompile range has the potential to cause weird bugs in clients that have longstanding hardcoded assumptions that the 0x01-0xff range is only precompiles.

I agree with Peter, deploying a contract in the precompile range is confusing. Although i understand design choice, what about using 0xde ("deploy") instead of 0x12? If we add more precompiles later, we'd have a cleaner range without a system contract in the middle.

Could we PR to the eip?

LouisTsai-Csie

Nice work, some additional testing idea:

Account delegate to the 0x12
Constructor revert with large data (16KB+)
Oversized initcode revert
0xEF-prefix deployed code revert

Since this EIP isn't SFI, should we create eips/amsterdam/eip-7997 from forks/amsterdam and merge into that branch instead of directly into forks/amsterdam?

main
 └── forks/amsterdam              ← Integration branch for Amsterdam fork
      ├── eips/amsterdam/eip-7997 ← Sub-integration branch for individual EIP
      │    ├── feature-A          ← Your PR
      │    └── feature-B          ← Someone else's PR
      ├── eips/amsterdam/eip-XXXX
      └── ...

One more thing: should we update eth_config to include this system contract?

LouisTsai-Csie · 2026-05-19T05:25:38Z

+        tx=Transaction(
+            sender=pre.fund_eoa(),
+            to=caller,
+            gas_limit=200_000,


I would suggest we add metadata to the caller.

Op.SSTORE(0, Op.EXTCODESIZE(FACTORY), original_value=0, new_value=1) + Op.STOP

So that this hardcoded gas limit would not be affected by other repricing eip (e.g., eip-8038).

There are more instance below, what do you think? Maybe this is too much to change.

LouisTsai-Csie · 2026-05-19T06:00:31Z

+    expected_address = compute_create2_address(FACTORY, salt, initcode)
+    pre_balance = 0xBA1
+
+    pre[expected_address] = Account(balance=pre_balance)


I think we could fund it via CALL, this way we make the test compatible with execute mode.

LouisTsai-Csie · 2026-05-19T06:09:52Z

+    """EIP-7997 class."""
+
+    @classmethod
+    def deterministic_factory_predeploy_address(cls) -> Address | None:


This could be a problem for benchmarking tests. We've already deployed a large number of contracts using the original factory. After the fork activates in benchmark tests, our address calculations would change, leading to mismatch. But i have no good suggestion for now, let me think about it.

precompile range

…warming, CALLCODE, and giving it a balance via SELFDESTRUCT

jochem-brouwer · 2026-06-04T20:27:04Z

Cross-linking: #1988

spencer-tb · 2026-06-09T14:25:49Z

Cc-ing EIP update: ethereum/EIPs#11783

kclowes changed the title ~~Eips/amsterdam/eip 7997~~ feat(spec, spec-specs): EIP-7997 May 4, 2026

kclowes added A-spec-specs Area: Specification—The Ethereum specification itself (eg. `src/ethereum/*`) C-feat Category: an improvement or new feature A-test-specs Area: execution_testing.specs labels May 4, 2026

kclowes force-pushed the eips/amsterdam/eip-7997 branch from 4eb98bd to 2daf7a9 Compare May 6, 2026 20:22

LouisTsai-Csie self-requested a review May 7, 2026 06:10

marioevz reviewed May 8, 2026

View reviewed changes

kclowes marked this pull request as ready for review May 11, 2026 17:40

LouisTsai-Csie requested changes May 19, 2026

View reviewed changes

spencer-tb mentioned this pull request Jun 2, 2026

Test Release Tracker: glamsterdam-devnet@v7.0.0 #2915

Open

15 tasks

kclowes changed the base branch from forks/amsterdam to eips/amsterdam/eip-7997 June 4, 2026 19:54

kclowes added 4 commits June 4, 2026 14:25

feat(spec, specs): EIP-7997 - Spec and basic tests

1088841

feat(spec-specs): EIP 7997 - More tests

60579e4

bugfix(specs): Add logic to add 0x12 as a special contract outside the

f943020

precompile range

feat(tests): 7997 - add a check at the transition, adds tests for pre…

d36c5ff

…warming, CALLCODE, and giving it a balance via SELFDESTRUCT

kclowes force-pushed the eips/amsterdam/eip-7997 branch from 97a92d1 to d36c5ff Compare June 4, 2026 20:25

fix: address PR feedback

9f9e080

	pytestmark = pytest.mark.valid_from("Amsterdam")
	pytestmark = pytest.mark.valid_from("EIP7997")

Conversation

kclowes commented May 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🗒️ Description

🔗 Related Issues or PRs

✅ Checklist

Cute Animal Picture

Uh oh!

codecov Bot commented May 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

petertdavies commented May 7, 2026

Uh oh!

kclowes commented May 7, 2026

Uh oh!

marioevz left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kclowes commented May 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

LouisTsai-Csie commented May 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

LouisTsai-Csie left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jochem-brouwer commented Jun 4, 2026

Uh oh!

spencer-tb commented Jun 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

kclowes commented May 4, 2026 •

edited

Loading

codecov Bot commented May 4, 2026 •

edited

Loading

kclowes commented May 11, 2026 •

edited

Loading

LouisTsai-Csie commented May 19, 2026 •

edited

Loading

LouisTsai-Csie left a comment •

edited

Loading