Evaluated on: · Spec revision: 2026-08-25 · ac450a4ab2 · Inclusion status at snapshot: PFI
Scope at the cutoff. Draft execution-layer assessment of EIP-8372 as sealed in the Hegotá PFI snapshot. The proposal modifies EIP-8037 by selecting a new cost per state byte, scaling the raw block state-gas limit, and normalizing raw state-gas usage before comparing it with execution-gas usage for the existing header gas_used value. Transaction formats, block-header fields, the transaction reservoir, transaction-level accounting, and receipt semantics remain unchanged.
- Evaluator
- LLMChecklist v2
- Confidence
- Medium
- Under-specified at assessment cutoff
- Yes — 4 criteria affected
- Plausible range
- 18–21 (Medium)
- Snapshot
- 2026-08-25 · EIP revision
ac450a4ab2(2026-08-25)
Score bands · Checklist revision 2
- Low <12
- Medium 12–22
- High ≥23
28 criteria scored 0–3 (4 in exceptional cases; cross-EIP interactions is uncapped); nominal maximum 84.
Complexity profile
Each segment is one criterion's contribution to the LLM total. Hover or focus a segment for its score and rationale.
Top complexity drivers
- Edge/boundary conditions3
- State gas accounting changes2
- New or modified transaction validity mechanisms2
- Patterns affecting pre-existing tests2
Under-specified at assessment cutoff: Yes
The EIP text available at the assessment cutoff left material behavior unresolved. The affected criteria and the plausible total range record that uncertainty.
Why: The state-gas price and raw-limit scale are both normative consensus inputs to every changed formula but remain TBD. The algorithms are specified, so the gap is localized, yet concrete validity vectors, rounding boundaries, workload magnitude, and calibration risk cannot be finalized. The rationale gives a proportional selection formula, but the normative parameter section requires only that both values be positive integers.
Plausible total
18–21
recorded score 19 · plausible tiers Medium
Unresolved questions at the cutoff (4)
- What final positive integer value is selected for CPSB?
- What final positive integer value is selected for STATE_GAS_LIMIT_SCALE?
- Are the selected constants normatively required to preserve the proportional CPSB-to-limit-scale relation described in the calibration rationale?
- What exact rounding-boundary vectors result from the final constants, and what mixed execution/state workloads are used to stress-test the calibration?
Notable ambiguities noted by the assessor (3)
- The normative parameter table leaves CPSB and STATE_GAS_LIMIT_SCALE TBD; a client cannot compute state_gas_available, normalized state gas, or gas_used for concrete post-activation blocks without them.
- The calibration rationale defines STATE_GAS_LIMIT_SCALE from CPSB and a baseline, but the normative specification states only that the two parameters are positive integers and does not state the proportional relation as a constraint.
- Integer division is fully specified, but the exact raw-limit and inverse- normalization rounding discontinuities depend on the missing scale.
Criterion breakdown
| Criterion | Score | Why this score | Evidence / uncertainty |
|---|---|---|---|
| Edge/boundary conditionsUnder-specified | 3 | Tests need multiple boundary families: floor-division remainders, exact-limit and one-over-limit raw state gas, exact normalized block limit, and the execution/state max crossover. Their interaction requires an elevated set of cases rather than isolated single boundaries. |
Confidence: High Uncertainty: Exact remainder locations cannot be instantiated until the two TBD constants are selected. |
| State gas accounting changes | 2 | The block-level state-gas budget is modified and a normalization is added. This is the rubric's score-2 case. The transaction reservoir and its spill path into execution gas are expressly retained, so score 3 is not warranted. |
Confidence: High Uncertainty: The exact numeric budget is unavailable because CPSB and STATE_GAS_LIMIT_SCALE are still TBD, but the kind of mechanism is clear. |
| New or modified transaction validity mechanisms | 2 | Existing transaction types receive a changed inclusion-validity check that affects existing state-gas cases. Updates are limited to expected arithmetic and boundary cases and require no transaction format or testing-infrastructure redesign, matching score 2. |
Confidence: High Uncertainty: This score treats the proposal's explicitly named pre-inclusion transaction validation as a validity mechanism; intrinsic gas itself is unchanged. |
| Patterns affecting pre-existing tests | 2 | A considerable but focused category of pre-existing EIP-8037 state-gas and block-validation tests must be reworked for the scaled budget and normalized gas_used. The impact is not a major, diverse rewrite across unrelated test categories. |
Confidence: Medium Uncertainty: The package contains no test inventory, so the breadth is inferred only from the specified consensus surfaces and backwards-compatibility statement. |
| Security risksUnder-specified | 2 | The mechanism touches a limited set of critical accounting and validation components and changes their invariants, requiring targeted review, boundary testing, and fuzzing. It does not introduce the broad multi-component security redesign required for score 3. |
Confidence: High Uncertainty: Risk magnitude cannot be fully assessed while both calibrated constants are TBD. |
| Performance risksUnder-specified | 2 | The arithmetic itself is isolated, but its workload impact depends on mixed block execution/state demand and therefore cannot be fully benchmarked in isolation. The existing benchmark impact is limited by proportional CPSB and state-limit scaling intended to preserve maximum byte capacity. |
Confidence: Medium Uncertainty: Missing parameter values prevent quantifying whether the selected calibration is contractionary or expansionary in raw state gas and realized mixed-block load. |
| Cross-EIP interactions | 2 | EIP-8372 depends on and modifies EIP-8037, so coordinated state-gas and block accounting tests are required. The interaction is deep but limited to one directly required EIP. EIPs 7999 and 8075 are contextual alternatives or analogues in the sealed text and are not counted as co-implemented interactions. |
Confidence: High Uncertainty: The assessment counts EIP-8037 as the direct interaction and does not separately multiply all of EIP-8037's inherited dependencies, whose rules EIP-8372 says remain unchanged. Interacting EIPs: EIP-8037 |
| Unspecified behavior requiring cross-client consensusUnder-specified | 2 | Clients cannot baseline concrete consensus vectors until the two localized parameters are agreed. The formulas otherwise determine behavior, so this is localized agreement rather than newly observable unspecified semantics requiring repeated broad re-baselining. |
Confidence: High Uncertainty: The package contains no final values or normative constraint tying the two selected constants beyond positivity; the proportional relation appears in rationale/calibration methodology. |
| Modified system contracts | 1 | No system contract code or state is changed, but the CPSB update indirectly changes the gas allowance/reservoir formula for existing system calls. This is a minor indirect effect. |
Confidence: Medium Uncertainty: The magnitude is unknown until CPSB is selected, and EIP-8372 does not separately discuss system-call calibration. |
| EVM Gas rule changes | 1 | An existing gas-accounting mechanism is updated at block level. The change does not introduce another EVM transaction gas pool or replace the inherited reservoir mechanism, so the score matches an update rather than a new general EVM gas mechanism. |
Confidence: High Uncertainty: This row treats the block-level gas_used rule as EVM gas accounting while leaving the state-specific budget and normalization impact to the dedicated state-gas row. |
Show 18 zero-score criteria
| Criterion | Score | Why this score | Evidence / uncertainty |
|---|---|---|---|
| Added opcodes | 0 | No opcode is introduced. |
Uncertainty: The proposal reuses state-gas production defined by EIP-8037. |
| Modified opcodes | 0 | No opcode result or non-gas behavior is changed. Any effect of the new CPSB on state-creating opcodes is a gas change, which this anchor explicitly excludes. |
Uncertainty: Opcode-level state-gas sites remain those inherited from EIP-8037. |
| Added precompiles | 0 | No precompile is introduced. |
Uncertainty: None within the sealed proposal scope. |
| Modified precompiles | 0 | No existing precompile logic or gas schedule is modified. |
Uncertainty: The general block gas accounting applies to transactions that may call precompiles, but it does not modify a precompile. |
| Added system contracts | 0 | No system contract is introduced. |
Uncertainty: Existing system-call implications of changing CPSB are considered under the modified-system-contract row. |
| State-access ordering within opcode execution | 0 | No opcode's state access, gas-charge position relative to access, or definition of a recordable access is changed. |
Uncertainty: The new pre-transaction state-gas availability arithmetic does not move an access or charge within opcode execution. |
| Blob gas accounting changes | 0 | No blob-gas counter, price, target, limit, or accounting rule is modified. |
Uncertainty: Blob accounting is outside the mechanisms specified by this proposal. |
| New EVM gas refund | 0 | The proposal adds no refund or refill mechanism and does not modify the inherited refund rules. |
Uncertainty: Normalization is applied to block state-gas usage after inherited transaction accounting; it is not a gas refund. |
| New transaction types | 0 | No transaction type is introduced. |
Uncertainty: All existing transaction types are processed under the inherited EIP-8037 transaction model. |
| New block / header fields | 0 | No block or header field is added. |
Uncertainty: Raw and normalized state-gas values remain internal accounting values. |
| Encoding changes (RLP/SSZ) | 0 | No transaction, block, header, receipt, or interface encoding is changed. |
Uncertainty: The meaning of existing header gas_used changes, not its encoding. |
| Block syncing changes | 0 | No new block RLP validation or encoding mechanism is introduced, so the rubric's syncing-specific anchor is not triggered. |
Uncertainty: Historical/block execution validation changes are scored elsewhere; they are not RLP changes. |
| New fork activation mechanism | 0 | Activation selects protocol constants and begins applying new rules; it does not modify state or an existing internal variable at the activation block. |
Uncertainty: The constants are still TBD, but initializing or selecting constants is not the modification scored by this anchor. |
| Engine API changes | 0 | No Engine API endpoint, field, or communication mechanism is added or modified. |
Uncertainty: Builder behavior must reflect the new validity rules, but no Engine API transport change is specified. |
| Transition-tool interface changes | 0 | The transition behavior changes, but the proposal specifies no new field or mechanism that must cross the transition-tool interface. |
Uncertainty: Fork configuration must carry the selected constants in an implementation, but the package does not specify that as a transition-tool interface field. |
| New invariant on pre-existing tests | 0 | Existing affected tests must change expected values and validity outcomes, rather than mechanically add an assertion for a newly produced artifact to otherwise unchanged tests. |
Uncertainty: Implementations may expose intermediate normalized values for convenience, but the sealed proposal does not require tests to assert such an output. |
| New test-framework primitives | 0 | Ordinary transaction, block, gas-used, and validity expectations suffice; no new expectation type, modifier, or reusable framework primitive is required by the text. |
Uncertainty: The package provides no framework implementation, so this conclusion is limited to the specified inputs and outputs. |
| Cryptography | 0 | No cryptographic primitive, algorithm, proof, signature, hash, or associated validation behavior is introduced or modified. |
Uncertainty: The calibration method is economic arithmetic, not cryptography. |
Assessment provenance
- Assessed EIP revision
ethereum/EIPs@ac450a4ab2EIPS/eip-8372.md committed 2026-08-25 · information cutoff 2026-08-25T11:56:58Z- Rubric
- Checklist revision 2 ·
ethspecs/pm@3d8c0128c5 - Evaluator
- gpt-5.6-sol at xhigh reasoning effort · isolation
bubblewrap_one_eip_capsule_v1 - Source record
- Frozen research record
research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-8372.yaml· sha25677b31821d04c - Supporting documents in the sealed package
supporting/eip-7999.md,supporting/eip-8037.md,supporting/eip-8075.md