[spencer-tb]

Status

Documentation/reference prototype for EIP-8272. This draft is not proposed for merge in its current form.

The implementation lives in the Amsterdam spec module and activates through the testing-side Bogota pseudo-fork. This is the user-confirmed EIP-8141 substrate exception: frame execution is required, so the target is spencer-tb/execution-specs:eips/amsterdam/eip-8141 at 748bbb89e122dafb421f47ec9ae6cb5a5ecd78ac.

Description

Implements EIP-8272 at the revision pinned by the tests: applications publish roots by source and slot, and ordinary EIP-8141 VERIFY frames check up to sixteen recent references.

• Spec: installs the recent-root contract at activation, preserves balance and higher nonce, and rejects pre-existing code or storage before changing either predeploy. A shared MPT storage-root query makes the storage precondition explicit.
• Candidate runtime: supplies readable assembly for both write and validation operations because the EIP leaves RECENT_ROOT_CODE undefined. The 426-byte candidate has keccak256 0x92581be6144206cc1ba9f655324d74f0a49f20661ff2d31975aefb2449884342; tests pin the assembly, spec constant, fixture code and reference vector.
• Framework: registers EIP-8272 on Bogota and extends activation code installs with a nonce floor. The EIP adds no transaction envelope, opcode, gas schedule, Engine API or transition-tool field.
• Tests: cover calldata and age boundaries, full-width slots, zero roots, stale ring entries, failure anywhere in a tuple batch, repeated and warm references, exact/one-short execution gas, frame classification versus block validity, publishing and overwrite behavior, CALL/DELEGATECALL/CALLCODE/EIP-7702 storage contexts, BAL reads/writes, and activation. Direct spec tests cover occupied-address rejection, which fixture installation bypasses.
• Existing tests: no parking or benchmark changes are needed.

Required EIP follow-up

Specification

1. Blocking for production: select and publish canonical RECENT_ROOT_CODE, ideally with maintained assembly and a pinned build/hash. Semantics alone do not determine the activation state root. This branch's code is a reviewable candidate, not an accepted protocol constant. The existing sys-asm proposal still implements the older write-only design and needs the validation path before it can supply this constant.

Gas and compatibility language

2. Blocking for production fixtures: baseline exact execution costs after canonical code selection, including target access, distinct versus repeated storage reads, and warm access inherited from earlier frames. This candidate costs 154 + 429*n internally, plus ordinary SLOAD costs and EIP-8141 frame entry; sixteen distinct cold references currently require 43,618 execution gas. Changing the runtime requires re-deriving the gas expectations.
3. Non-blocking clarification: describe a write in static context as an exceptional halt at SSTORE, with the normal gas consequence. This follows existing EVM rules; it is not a REVERT path.
4. Non-blocking clarification: retain an explicit separation between public-mempool recognition/prefix/budget rules and EIP-8141 block validity, as proposed by the pending scope amendment. Multiple matching frames, noncanonical position, payment flags and nonzero state budgets do not add new consensus rejection rules.

Known limitations

• The runtime and its exact gas profile remain provisional until the EIP defines canonical code. Cross-client validation of this two-operation candidate is outstanding.
• Public-mempool admission, direct-evaluation parity, MAX_VERIFY_GAS policy, dependency indexing, eviction and reorg revalidation are outside this execution-spec prototype.
• Bogota is a testing pseudo-fork sharing the Amsterdam module. The live transition cases exercise framework installation using pre-fork blocks whose operations agree on both sides. Occupied-address rejection is covered directly through apply_fork; generated transition fixtures cannot currently express that rejection. Activation-crossing reorgs are not covered here.
• The new storage query is exercised on the shared MPT state implementation. The legacy optimized backend has a storage-root operation, but backend parity was not independently validated in this review.
• This is an isolated EIP-8272 delta on the approved EIP-8141 base, not a combined post-Amsterdam implementation.

References

• EIP revision used by the tests (824cbc0b0e, file blob 274ce98c57ec285862f4d2ff48cd9f545c385f12): https://github.com/ethereum/EIPs/blob/824cbc0b0e459ea6b105d8b96420a5d46abf0806/EIPS/eip-8272.md
• Tracker: Execution Layer Testing Complexity Assessments For Hegota SFI'd & CFI'd & PFI'd EIPs ethspecs/pm#72 (EIP-8272 remains assigned to @marioevz; untouched).
• Complexity assessment: Add EIP-8272 complexity assessment ethspecs/pm#133 (existing evaluator draft, based on the older envelope/opcode design). A reassessment against this prototype is retained locally at the user's request.
• EIP discussion: https://ethereum-magicians.org/t/eip-8272-recent-roots-for-frame-transactions/28621