EIP Complexity Assessment — Checklist Revision 2

[marioevz]

Five new anchors, one removed, Cross-EIP interactions uncapped, and the checklist versioned. 24 anchors become 28; nominal range 0–72 becomes 0–84.

Driven by the Amsterdam calibration, which compared each Amsterdam EIP's score against the testing work it actually produced in ethereum/execution-specs. Every mature EIP landed within ±3 of the score its measured work implies — except EIP-7928, short by 11 points with no rows left to score on. The five new rows are where that work should have been recorded.

New anchors

1. State-access ordering within opcode execution

Changes where inside an opcode's execution state is accessed, or where gas is charged relative to that access. Because a state access is recorded in the block-level access list only if execution had enough gas to reach it, this ordering is consensus-critical: moving it changes the BAL at every gas boundary of every affected opcode.

2. State gas accounting changes

New state gas accounting rules. State gas is the cost of writing state, as opposed to accessing or executing it: StateGasCosts, COST_PER_STATE_BYTE, the block-level state gas budget, and the spill path into execution gas.

3. New invariant on pre-existing tests

Tests that are not about this EIP must nonetheless assert something this EIP produces. Their logic does not change; they gain a new thing to check. E.g. EIP-7928 added block-level access lists, which could add an assertion to every previous test (not the case but possible).

4. New test-framework primitives

Requires new abstractions in the test framework itself — expectation types, modifiers, helpers — beyond writing test functions with what already exists. E.g. EIP-7928 added BlockAccessListExpectation, which had to be designed and then applied to tests.

5. Unspecified behavior requiring cross-client consensus

The EIP text does not determine the answer for cases a test can construct. Clients must agree on a previously unspecified detail before tests can be baselined. The cost here is coordination and re-baselining, not test writing.

Cross-EIP interactions — uncapped

Now the only anchor without a ceiling. EIP-7928's rationale names 12 interacting EIPs, EIP-8038 names 6, every other Amsterdam EIP names 0 — and all scored the same 3. +1 for every 3 additional interacting EIPs beyond the first 3 (each of which requires its own coordinated test cases).

Removed: Engine API encoding changes

Described a wire-format change at the Engine API layer (JSON → RLP/SSZ), but those migrations are coordinated outside the EIP process.

Versioning

The template carries the revision version, now at number 2, and Revision Notes is split into per-revision subsections.

Scores are not comparable across revisions — re-score rather than compare. The 28 existing assessments stay on revision 1 and are not re-scored here.

Worth pushing back on

• Are the new rows scoreable at CFI time? Rows 2–5 look assessable a priori. Row 1 is the risky one — spotting that an EIP moves an observable execution detail is exactly the insight EIP-7928's original evaluation missed.
• The +1 per 3 Cross-EIP increment and the 12/23 tier thresholds are judgement, not measurement.
• The calibration fits 9 EIPs on one fork, and all proposed scores were assigned in hindsight. Caveats are listed in full in the calibration README.