Evaluated on: · Spec revision: 2026-08-25 · ac450a4ab2 · Inclusion status at snapshot: PFI
Scope at the cutoff. Execution-layer assessment of the Draft EIP-8304 snapshot. The proposal derives SSZ/SHA2-256 index-table roots from every block's transactions, receipts, logs, and delayed parent block hash; periodically merges those tables across five levels; and writes the roots through a new stateful system contract. No consensus-layer behavior is scored.
- Evaluator
- LLMChecklist v2
- Confidence
- Medium
- Under-specified at assessment cutoff
- Yes — 8 criteria affected
- Plausible range
- 27–33 (High)
- 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
- New fork activation mechanism3
- Patterns affecting pre-existing tests3
- Performance risks3
- Edge/boundary conditions3
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: Material consensus parameters are absent. The SSZ List limit/fixed tree depth needed to derive roots is not stated; the index-contract address and most fields of its synthetic deployment are TBD; and the transition/testing interface and bounded asynchronous merge obligations are not specified. These are recorded once here rather than being multiplied across otherwise unrelated zero-score anchors.
Plausible total
27–33
recorded score 30 · plausible tiers High
Unresolved questions at the cutoff (5)
- What fixed binary-tree depth or SSZ List limit applies to table roots, and what exact root is expected for an empty table?
- What are INDEX_CONTRACT_ADDRESS, the synthetic transaction's v/r/s/hash and sender, and the exact fork-activation deployment procedure, including genesis activation?
- What historical blocks or prior table artifacts must a one-block transition tool accept and return so delayed higher-level roots are reproducible?
- What deterministic resource/deadline requirements govern asynchronous merges, reorg recovery, and the first post-sync block at every table-level boundary?
- How does the gas-exempt root-update operation interact with any separate state-gas accounting applied to its storage creation and overwrites?
Notable ambiguities noted by the assessor (3)
- `List[Hash32, entry_count]` uses the actual entry count where an SSZ list limit/root- defining constant is expected, while the prose separately says the tree has fixed depth.
- Clients may directly write storage instead of executing the system call, but the equivalence requirements are stated only as a preference, not as explicit observable invariants.
- The proposal says higher tables can be merged asynchronously while also making their roots mandatory at precise later blocks, without bounding intermediate work or retained artifacts.
Criterion breakdown
| Criterion | Score | Why this score | Evidence / uncertainty |
|---|---|---|---|
| New fork activation mechanismUnder-specified | 3 | Activation installs code and initializes an account nonce, an explicit irregular state modification at the fork boundary, and begins table scheduling from that boundary. |
Confidence: High Uncertainty: The exact address and signed deployment fields are TBD, so activation vectors cannot yet be finalized even though the required state modification is clear. |
| Patterns affecting pre-existing tests | 3 | Existing post-fork block tests across transactions, empty blocks, logs, state roots, block hashes, and periodic boundaries must incorporate the mandatory index transition. This is a major, diverse regression surface. |
Confidence: High Uncertainty: The package does not expose the existing test corpus, so the exact count of reworked vectors is unknown; the mandatory behavior itself spans diverse test categories. |
| Performance risksUnder-specified | 3 | Work scales with transaction and log content, interacts with receipt production, periodic multi-level merging, block deadlines, storage updates, and sync recovery. End-to-end and adversarial-content performance cannot be established by one isolated microbenchmark and can substantially affect validation behavior. |
Confidence: High Uncertainty: The EIP asserts low single-block cost and asynchronous larger merges but gives no processing bounds, benchmark results, or maximum entry/tree size. |
| Edge/boundary conditionsUnder-specified | 3 | Genesis, activation, empty tables, level alignment, delayed availability, five table sizes, and 1,024-slot wraparound create multiple interacting boundary mechanisms. The schedule-by-level and overwrite combinations require an elevated case count. |
Confidence: High Uncertainty: The missing SSZ depth/list limit prevents the exact empty and maximum-table boundary vectors from being baselined. |
| Cross-EIP interactions | 3 | Coordinated vectors are required for EIPs 161, 1559, and 4788 around deployment and system-call semantics, and for EIPs 7708 and 8141 around newly generated logs and frame-receipt indexing. These span multiple strong interactions, but five identified EIPs do not trigger the rubric's first three-additional-EIP bonus. |
Confidence: High Uncertainty: The precise fork combination is outside the package; the score uses only the explicit and supporting-document interactions sealed here. Interacting EIPs: EIP-161, EIP-1559, EIP-4788, EIP-7708, EIP-8141 |
| Unspecified behavior requiring cross-client consensusUnder-specified | 3 | Previously uncommitted transaction/log indexing becomes consensus-visible through contract storage and the block state root, yet root-defining SSZ parameters and activation deployment values are absent. Constructible blocks therefore lack a unique expected state until clients agree and the draft is amended. |
Confidence: High Uncertainty: No package evidence establishes implementations, devnet baselines, or resolutions for these gaps; prohibited external history was not consulted. |
| Added system contractsUnder-specified | 2 | Exactly one new system contract is added, and it is stateful because mandatory block processing repeatedly writes its storage. |
Confidence: High Uncertainty: INDEX_CONTRACT_ADDRESS and the signed synthetic deployment transaction remain TBD, but the addition and statefulness are unambiguous. |
| Transition-tool interface changesUnder-specified | 2 | A single-block transition interface needs a new mechanism to supply or retain recent blocks and prior table material so it can derive periodic roots. That is more than one isolated scalar field, but the EIP does not prescribe the exact interface. |
Confidence: Medium Uncertainty: No transition-tool schema is included, so whether implementations use one history object, several fields, or externally prepared tables remains open. |
| New invariant on pre-existing tests | 2 | A broad category of post-fork tests gains a mechanically derived index-root and system-state expectation even when indexing is not the test's subject. The rule does not apply before activation, so the score stops below the every-vector anchor. |
Confidence: High Uncertainty: Test harnesses may assert this indirectly through the state root rather than as a dedicated field, but the new expected state is still mandatory. |
| New test-framework primitivesUnder-specified | 2 | Reusable index-table construction, merge, and delayed-schedule expectations are new primitives needed throughout this EIP's tests, rather than ordinary test functions using only scalar expectations. |
Confidence: Medium Uncertainty: The sealed package contains no test-framework inventory, so permanence or reuse outside this EIP cannot be established. |
| Security risksUnder-specified | 2 | Root correctness and update availability affect trustless proofs and consensus state, while hot storage creates a targeted resource-attack surface. The interactions are concentrated in index derivation and its system contract, so targeted review and fuzzing fit better than the broadest security anchor. |
Confidence: Medium Uncertainty: Missing commitment parameters and deployment constants prevent complete proof- soundness and adversarial-storage analysis at this snapshot. |
| EVM Gas rule changes | 1 | The proposal applies the existing gas-exempt system-operation convention to a new mandatory call, updating an existing accounting path without changing opcode prices or introducing a new metering mechanism. |
Confidence: Medium Uncertainty: The text is explicit about the system call and unchanged LOG costs, but does not separately classify this convention as an EVM gas-rule change. |
| Cryptography | 1 | The proposal introduces one commitment construction composed of established SHA2-256 hashing and SSZ Merkleization; it is well known rather than novel. |
Confidence: High Uncertainty: The construction's missing fixed depth/list limit is a consensus-specification gap, but does not make the underlying cryptography novel. |
Show 15 zero-score criteria
| Criterion | Score | Why this score | Evidence / uncertainty |
|---|---|---|---|
| Added opcodes | 0 | No new opcode is defined. |
Uncertainty: Contract bytecode is new code, not a new opcode. |
| Modified opcodes | 0 | No existing opcode result or non-gas behavior is modified or deprecated. |
Uncertainty: The index observes logs after execution but does not alter LOG semantics. |
| Added precompiles | 0 | No precompile is introduced. |
Uncertainty: The system contract must not be classified as a precompile. |
| Modified precompiles | 0 | No precompile logic or gas schedule is modified. |
Uncertainty: The proposal contains no precompile behavior. |
| Modified system contracts | 0 | Reusing SYSTEM_ADDRESS and the system-call convention does not modify the code, state, or behavior of the pre-existing beacon-roots system contract. |
Uncertainty: No indirect behavioral change to a pre-existing system contract is specified. |
| State-access ordering within opcode execution | 0 | The new work is a block-level post-transaction operation; no opcode's internal state-access point or gas-charge ordering is changed. |
Uncertainty: No opcode-internal ordering change is specified. |
| Blob gas accounting changes | 0 | No blob gas rule, charge, budget, or field is introduced or modified. |
Uncertainty: The proposal contains no blob-gas behavior. |
| State gas accounting changes | 0 | The stateful contract adds storage writes but defines no new state-gas rate, charging site, budget, reservoir, or execution-gas spill rule. |
Uncertainty: The draft does not state how its gas-exempt system operation relates to a separate state-gas regime; that omission is recorded as under-specification, not scored as an introduced mechanism. |
| New EVM gas refund | 0 | No gas-refund mechanism is added or changed. |
Uncertainty: The proposal contains no refund behavior. |
| New transaction types | 0 | Indexing transactions does not introduce a transaction envelope or type. |
Uncertainty: The proposal applies uniformly to transactions already present in blocks. |
| New or modified transaction validity mechanisms | 0 | No existing transaction's validity rules or intrinsic gas calculation changes; the proposal derives a post-execution commitment from already processed transactions. |
Uncertainty: Incorrect index processing can invalidate a block, but not an individual transaction. |
| New block / header fields | 0 | No block or header field is added; the new commitment is part of execution state. |
Uncertainty: The block state root changes indirectly, but its header field and encoding do not. |
| Encoding changes (RLP/SSZ) | 0 | The proposal defines a new internal index-table encoding but does not change transaction, block, header, or Engine-interface encoding. The anchor's enumerated protocol encoding surfaces therefore remain unchanged. |
Uncertainty: SSZ is newly used for table roots, but those tables are not transaction, block, or interface payloads under the rubric's stated scope. |
| Block syncing changes | 0 | Regeneration adds local post-sync work, but no block-RLP validation mechanism or sync-protocol encoding is introduced, which is the scope of this anchor. |
Uncertainty: The 319-block retention/download requirement is a performance and initialization concern, not a scored RLP syncing change. |
| Engine API changes | 0 | No Engine API field, endpoint, or communication mechanism is specified. |
Uncertainty: The package does not prescribe any Engine API exposure for the generated roots. |
Assessment provenance
- Assessed EIP revision
ethereum/EIPs@ac450a4ab2EIPS/eip-8304.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-8304.yaml· sha256b84aa652b0ed - Supporting documents in the sealed package
supporting/eip-161.md,supporting/eip-1559.md,supporting/eip-4788.md,supporting/eip-7708.md,supporting/eip-8141.md