Update EIP-8141: clarify floor repricing, signature validation, and frame.value gas

[AnkushinDaniil]

I'm implementing EIP-8141 in Nethermind and cross-testing against ethrex on a devnet. Three places in the current text can be read in more than one way, and we already hit real divergences from two of them. This PR proposes minimal wording to pin each one. It is a clarification request from an implementer, not a design change - Stavros, as the author, please confirm if these readings match the intent. Happy to switch any of them to the other reading if not.

1. Which calldata floor applies to frame and signature data

calldata_floor_gas charges TOTAL_COST_FLOOR_PER_TOKEN * calldata_tokens, but the constant is not defined in this EIP. The header requires EIP-7623 (value 10), and the sentence "as defined in EIP-7623" was removed in #11969 during the settlement restructure. EIP-7976 (scheduled for Glamsterdam) redefines that same constant to 16 and the floor token weighting to 4 tokens per byte, i.e. 64 gas per byte flat. Frame transactions exist only from a later fork (CFI for Hegota in EIP-8081), so both EIPs are active wherever a frame tx is valid, and the text supports three different results:

• 10/40: pin the constant to EIP-7623's table via the requires chain. Nethermind's integration branch implements this.
• 16/64: re-resolve the named constant to 16 but keep this EIP's inline token weighting. Probably nobody wants this, but it is the most literal composition of the two texts.
• 64/64: apply the floor model in force at the fork. ethrex main implements this (see feat(levm): apply the EIP-7623 calldata floor to frame transactions lambdaclass/ethrex#7049).

So the two clients disagree today, and our cross-client devnet converged on floor = 10 only because we forced the same value into both integration branches - a shared value that cross-client testing cannot check against the spec. The proposed wording makes the floor fork-relative (64/64 wherever EIP-7976 is active), since the floor's purpose is a uniform per-byte bound across transaction types. If the intent is to pin 10/40 permanently, restoring the removed sentence is the right fix instead; either way the text should say which.

2. Signature validation vs EIP-7928 block access lists

validate_signature evaluates P256VERIFY (and ecrecover) as functions, outside EVM execution. EIP-7928 includes precompiles "when accessed", and neither EIP says whether protocol-level evaluation counts as accessing the 0x100 account. This produced a real split on our devnet: Nethermind recorded a read-only BAL entry for 0x...0100, ethrex did not, and block 137 failed cross-validation (blockAccessListHash mismatch, 10 account entries vs 9). Both clients now agree on "no entry" only because we aligned them. The proposed sentence pins the reading that matches existing precedent: transaction sender recovery and EIP-7702 authority recovery never record the ecrecover precompile, and blob KZG verification never records the point evaluation precompile.

3. Gas of frame.value transfers

#11969 also removed "The gas cost of sending frame.value is the same as for any CALL instruction", so the cost of the top-level value transfer is now unspecified. With EIP-8037 the difference is large: an ordinary CALL that creates the recipient pays STATE_BYTES_PER_NEW_ACCOUNT x CPSB = 183,600 state gas, while a frame's top-level transfer currently creates the recipient account for no charge in both implementations (and always emits the EIP-7708 transfer log, where the regular path performs no transfer and emits no log when the creation charge cannot be paid). The proposed wording restores the removed sentence and makes the account-creation and transfer-log consequences explicit. If the intent is that the top-level frame transfer is deliberately unmetered, the text should state that instead.

[eth-bot]

File EIPS/eip-8141.md

Requires 1 more review from Authors: @derekchiang, @drortirosh, @fjl, @forshtat, @lightclient, @nerolation, @shahafn, @svlachakis, @vbuterin, @yoavw