Feature/glamsterdam existing eip updates

[Marchhill]

Fixes Closes Resolves #

Please choose one of the keywords above to refer to the issue this PR solves followed by the issue number (e.g. Fixes #000). If no issue number, remove the line. Also, remove everything marked optional that is not applicable. Remove this note after reading.

Changes

• List the changes

Types of changes

What types of changes does your code introduce?

• Bugfix (a non-breaking change that fixes an issue)
• New feature (a non-breaking change that adds functionality)
• Breaking change (a change that causes existing functionality not to work as expected)
• Optimization
• Refactoring
• Documentation update
• Build-related changes
• Other: Description

Testing

Requires testing

• Yes
• No

If yes, did you write tests?

• Yes
• No

Notes on testing

Optional. Remove if not applicable.

Documentation

Requires documentation update

• Yes
• No

If yes, link the PR to the docs update or the issue with the details labeled docs. Remove if not applicable.

Requires explanation in Release Notes

• Yes
• No

If yes, fill in the details here. Remove if not applicable.

Remarks

Optional. Remove if not applicable.

[claude]

Claude finished @Marchhill's task in 7m 8s —— View job

---

Review: Feature/glamsterdam existing eip updates

• Load tools and gather PR diff
• Read changed files
• Read relevant rules files
• Analyze changes for correctness, performance, and style
• Post inline comments and summary

---

Summary

This PR aligns the Nethermind implementation to glamsterdam devnet-6: final EIP-8038 repricing (COLD_ACCOUNT_ACCESS 2600→3000, COLD_STORAGE_ACCESS 2100→3000, STORAGE_WRITE replaces SSetRegular/SReset, StorageClearRefund formula), EIP-2780 intrinsic gas simplified to match EELS calculate_intrinsic_cost, EIP-7954 max code size corrected to 64 KiB, and EIP-8246 activated alongside EIP-8038 in Amsterdam.

The arithmetic checks out: StorageClearRefund = (10000 + 3000) * 4800 / 5000 = 12480, CallValue = 8000 + 2300 = 10300, CreateAccess = 8000 + 3000 = 11000. The SSTORE reversal refund (StorageWrite = 10000) and the zero-original state-gas credit path are correctly guarded. The net-metered SSTORE charge being set to Free under EIP-8038 and the warm-access charge being folded into ConsumeStorageAccessGas are consistent.

---

Findings

Severity	Count
Critical	0
High	0
Medium	2
Low	2

Medium

1. Dead worldState parameter — EthereumGasPolicy.cs line 562 (inline comment posted)

Eip2780ExtraGas no longer reads worldState anywhere in its body, yet both the private method and the public CalculateIntrinsicGas overload (line 482) still carry it. Callers who pass non-null worldState expecting it to affect gas (as it did pre-PR for account-existence checks) now silently get a different result. The XML doc acknowledges it ("no worldState lookup"), but the parameter should be removed or annotated [Obsolete].

2. Pre-EIP-8038 EIP-2780 standalone behavior changed — EthereumGasPolicy.cs lines 574–576 (inline comment posted)

The old Eip2780ExtraGas charged five distinct costs when EIP-2780 was active but EIP-8038 was not: access-list warm discount (100), no-code cold discount (500 vs 2600), new-account surcharge (25 000), state-update for value transfers (1 000), and EIP-7702 delegation-target touch. All are gone. Since Amsterdam co-activates EIP-2780 and EIP-8038 together, the standalone path is effectively dead code — but the code structure still permits it. A brief comment confirming EIP-2780 is always co-activated with EIP-8038 would prevent future regressions, and the missing new-account surcharge / 7702 charge should be explicitly acknowledged if standalone is intentionally dropped.

Low

3. regularWriteCost computed but not used in early-return path — EthereumGasPolicy.cs lines 309–311 (inline comment posted)

regularWriteCost is computed before the !TIsSlotCreation.IsActive early-return, but the early-return re-evaluates spec.IsEip8038Enabled ? … : spec.GasCosts.SStoreResetCost independently. The values are numerically identical today (pre-8038: both 2900; post-8038: both 10000) but the divergence is a latent hazard if the two constants ever diverge.

4. EIP-8246 re-enabled without explanation — 25_Amsterdam.cs line 26 (inline comment posted)

The prior comment explicitly blocked EIP-8246 because it wasn't in EEST for_amsterdam fixtures. Re-enabling it in the same commit as EIP-8038 activation without any note makes it unclear whether the conformance tests now include EIP-8246 or whether the exclusion was intentionally lifted.

---

Not mergeable as-is: Medium findings 1 and 2 should be addressed or explicitly acknowledged with rationale before merge.

[claude]

Medium — dead worldState parameter

worldState is no longer read anywhere in this method body (the old RecipientTouchCost/IsDeadAccount calls are gone). It also makes CalculateIntrinsicGas's optional worldState = null silently a no-op for EIP-2780 paths.

The XML doc acknowledges it ("no worldState lookup"), but callers who pass a non-null worldState now get different gas figures than they did pre-PR, with no compile-time warning. Consider removing the parameter from both this private method and the public overload to make the API honest, or at the minimum add a [Obsolete] annotation on the public overload.

Fix this →

[claude]

Low — regularWriteCost is not used in the early-return path

regularWriteCost is computed on line 309 but the !TIsSlotCreation.IsActive branch on line 311 independently re-evaluates spec.IsEip8038Enabled ? Eip8038Constants.StorageWrite : spec.GasCosts.SStoreResetCost rather than using it. The values are numerically identical (pre-8038: SSetRegular == SStoreResetCost == 2900; post-8038: both StorageWrite), so this is not a correctness bug, but it would be cleaner to use regularWriteCost in the early return to make the intent self-evident:

Suggested change

	long regularWriteCost = spec.IsEip8038Enabled ? Eip8038Constants.StorageWrite : GasCostOf.SSetRegular;
	if (!TIsSlotCreation.IsActive)
	return UpdateGas(ref gas, spec.IsEip8038Enabled ? Eip8038Constants.StorageWrite : spec.GasCosts.SStoreResetCost);
	long regularWriteCost = spec.IsEip8038Enabled ? Eip8038Constants.StorageWrite : GasCostOf.SSetRegular;
	if (!TIsSlotCreation.IsActive)
	return UpdateGas(ref gas, spec.IsEip8038Enabled ? Eip8038Constants.StorageWrite : spec.GasCosts.SStoreResetCost);

Actually — since SStoreResetCost and SSetRegular happen to be equal today, the cleaner fix is just to use regularWriteCost for both branches:

Suggested change

	long regularWriteCost = spec.IsEip8038Enabled ? Eip8038Constants.StorageWrite : GasCostOf.SSetRegular;
	if (!TIsSlotCreation.IsActive)
	return UpdateGas(ref gas, spec.IsEip8038Enabled ? Eip8038Constants.StorageWrite : spec.GasCosts.SStoreResetCost);
	long regularWriteCost = spec.IsEip8038Enabled ? Eip8038Constants.StorageWrite : GasCostOf.SSetRegular;
	if (!TIsSlotCreation.IsActive)
	return UpdateGas(ref gas, regularWriteCost);

Note this is a semantic equivalence assumption: if SStoreResetCost and SSetRegular ever diverge in a future fork, the two branches would need different constants again.

[claude]

Medium — pre-EIP-8038 EIP-2780 behavior is significantly changed

When IsEip2780Enabled && !IsEip8038Enabled (a configuration that the flag structure still allows), this code now charges a flat GasCostOf.ColdAccountAccess for the recipient touch. The prior implementation charged:

• GasCostOf.WarmStateRead (100) if the recipient was in the access list
• GasCostOf.ColdAccountAccessNoCodeEip2780 (500) for code-less accounts
• GasCostOf.ColdAccountAccess (2600) for code-bearing accounts
• An additional GasCostOf.NewAccount (25 000) for value transfers to non-existent, non-precompile recipients
• An additional GasCostOf.StateUpdateEip2780 (1 000) for value transfers to existing accounts
• An additional EIP-7702 delegation-target touch when applicable

All five charges are now absent for standalone-EIP-2780 configurations, not just the EIP-8038 path.

If EIP-2780 is intentionally always co-activated with EIP-8038 (as in Amsterdam), the standalone path is dead code and the simplification is harmless. In that case, please add a brief comment here — e.g. // EIP-2780 is always co-activated with EIP-8038 (Amsterdam); the pre-8038 branch is kept only for defensive completeness. — so future readers don't reintroduce the old multi-tier logic. If standalone-EIP-2780 is a supported configuration, the missing new-account surcharge and EIP-7702 delegation charge need to be verified against the EELS spec.

[claude]

Low — EIP-8246 re-enabled without visible implementation in this diff

The previous comment said EIP-8246 "is implemented but stays off here" due to it being a Draft not in the EEST for_amsterdam fixtures. This commit silently enables it alongside EIP-8038 with no explanation. Please confirm:

1. EIP-8246 is now included in the EEST for_amsterdam fixtures (or the conformance test exclusion is intentional).
2. No separate implementation PRs are needed — the existing implementation is complete and correct for devnet-6.

If this is just a "devnet-6 enables it" change and the implementation was already merged, a one-line comment here noting the devnet reference would help future auditors.