Retrospective LLM-Based Complexity Evaluations

EIP complexity assessment

EIP-4788: Beacon block root in the EVM

Assessed in Cancun / Dencun. The score describes the EIP text available at the assessment cutoff, not the EIP as it stands today.

RetrospectiveCancun / DencunAssessment cutoff 2023-04-27Included by cutoffLayers: execution, consensus
LLM Completescore 38
Human Not available· Human complexity assessments were not produced for this fork; only the LLM assessment exists.

LLM assessment

Evaluated on: · Spec revision: 2023-04-13 · 5b909b76ac

Scope at the cutoff. At the assessment cutoff, EIP-4788 proposed appending the 32-byte parent beacon-block hash-tree root to every post-fork execution header. Before transactions, execution processing would write that root into a slot-keyed, modulo-8192 state ring buffer, and a new fixed-cost BEACON_ROOT opcode would expose reads from that storage. The document was still Draft and left its tests, reference implementation, security analysis, and several consensus-critical details unresolved.

38HighHigh
Evaluator
LLMChecklist v2
Confidence
Medium
Under-specified at assessment cutoff
Yes — 14 criteria affected
Plausible range
29–44 (High)
Assessment cutoff
2023-04-27 · EIP revision 5b909b76ac (2023-04-13)
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

  1. New block / header fields3
  2. Encoding changes (RLP/SSZ)3
  3. New fork activation mechanism3
  4. Patterns affecting pre-existing tests3

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 draft makes a new consensus-layer value observable to execution while leaving timestamp-to-slot conversion, the exact gas constant and charge ordering, the cross-layer payload/interface path, history-account initialization, and ring-buffer freshness behavior unresolved. Its tests, reference implementation, and security considerations are also TODO.

Plausible total

29–44
recorded score 38 · plausible tiers High

Unresolved questions at the cutoff (6)
  • How are execution timestamps converted to consensus slot numbers, including at the fork boundary?
  • Is the opcode cost G_beacon_root or the undefined G_beacon_state_root, and when is it charged relative to stack and storage access?
  • How is the parent beacon root delivered to and validated by the execution client and transition tooling?
  • How is the fixed-address history account initialized or protected if state already exists there?
  • Must a query for an overwritten modulo-8192 slot return the newer root, or zero as the absent-root prose suggests?
  • What timestamp or slot-gap bounds limit the pre-block write loop?
Notable ambiguities noted by the assessor (3)
  • The opcode gas identifier in prose does not match the constants table.
  • The modulo ring buffer stores no slot tag, so the stated absent-root behavior is ambiguous after overwrite.
  • The draft does not define convert_to_slot or the execution/consensus interface carrying the root.

Criterion breakdown

EIP-4788 Cancun / Dencun: LLM criterion scores and rationale
CriterionScoreWhy this scoreEvidence / uncertainty
New block / header fields3The proposal directly introduces a new block-header field, which is the score-3 anchor.
  • eip.md · Specification / Block structure and validity, lines 41-47 A mandatory 32-byte parent beacon-block root is appended to the execution block header after withdrawals_root.
Confidence: High
Encoding changes (RLP/SSZ)3Appending a consensus field changes block-header encoding at the block level, which directly triggers the binary score-3 anchor.
  • eip.md · Specification / Block structure and validity, lines 41-47 A 32-byte field is appended after withdrawals_root and the block-header size grows at the fork timestamp.
Confidence: High
Uncertainty: The exact RLP construction is implicit rather than written out.
New fork activation mechanism3The fork-activation block modifies execution state under the new rule, directly meeting the score-3 anchor even though the action continues on later blocks.
  • eip.md · Specification / Block structure and validity and Block processing, lines 41-53 At the timestamp boundary the header grows, and processing the activation block performs a new history-contract storage write before transactions.
Confidence: High
Uncertainty: FORK_TIMESTAMP is still TBD, but the activation condition itself is explicit.
Patterns affecting pre-existing testsUnder-specified3Existing post-fork block, state-transition, syncing, and fork-transition tests would need broad reworking to supply the new header value and account for the state write, reaching the diverse-test score-3 anchor.
  • eip.md · Specification / Block structure and validity and Block processing, lines 41-68 Every post-fork block gains a mandatory header field and a pre-transaction state mutation, including fork-aware behavior based on timestamp.
Confidence: Medium
Uncertainty: The Test Cases section is TODO, so the exact historical fixture categories and amount of rework are not documented.
Security risksUnder-specified3Incorrect cross-layer roots, slot association, ring-buffer state, or opcode reads could undermine critical contract assumptions across several components, warranting extensive cross-layer review and fuzzing under the score-3 anchor.
  • eip.md · Motivation, lines 19-21 Contracts such as staking pools and bridges are intended to rely on the exposed root for trust-minimized access to consensus state.
  • eip.md · Specification / Block structure and validity and EVM changes, lines 41-85 A consensus-derived value crosses into execution-header validity, protocol-managed state, and an EVM-visible opcode.
  • eip.md · Security Considerations, lines 119-121 The historical proposal leaves its security analysis as TODO.
Confidence: Medium
Uncertainty: The absence of security considerations and precise cross-layer validation responsibilities makes the exact threat surface uncertain.
Edge/boundary conditionsUnder-specified3Fork boundaries, zero or many elapsed slots, modulo wraparound, absent entries, key widths, and stale-slot queries create multiple interacting boundaries; slot-gap and wraparound coverage require an elevated case set.
  • eip.md · Specification / EVM changes, lines 53-85 Processing spans a start/end-slot range, converts keys to 32-byte big endian, wraps them modulo 8192, and returns zero when no root is stored.
  • eip.md · Specification / Background, lines 33-39 Missed slots and bounded ring-buffer storage are explicit design dimensions.
Confidence: High
Uncertainty: Several boundary outcomes are not fully determined because convert_to_slot and overwrite freshness semantics are unspecified.
Unspecified behavior requiring cross-client consensusUnder-specified3Previously EVM-unobservable consensus-root and slot-association details become consensus-critical through a header field, state writes, and an opcode, while several constructible outcomes are unresolved; this matches score 3.
  • eip.md · Specification constants and Block processing, lines 25-31 and 53-70 The fork time is TBD and the consensus-critical convert_to_slot operation is used without any definition.
  • eip.md · Specification / New opcode, lines 72-85 The opcode refers to an undefined gas-constant name and describes absent-slot behavior despite modulo-only storage that can contain an overwritten value.
  • eip.md · Test Cases, Reference Implementation, and Security Considerations, lines 111-121 Tests, an implementation, and the security analysis are all left TODO at this revision.
Confidence: High
Uncertainty: Material gaps include timestamp-to-slot conversion, gas naming and charge ordering, ring-buffer freshness, system-account initialization, and cross-layer validation/delivery.
Added system contractsUnder-specified2One new stateful system contract is introduced and receives a new protocol-level action every post-fork block, which matches score 2.
  • eip.md · Abstract and Specification / Background, lines 13-18 and 33-39 Roots are stored in a contract at a canonical execution-state address using an SSTORE-like update and a bounded ring buffer.
  • eip.md · Specification / Block processing, lines 51-70 Protocol block processing writes the parent root into the history contract's storage before transactions.
Confidence: High
Uncertainty: The account's code, initialization, and collision handling at the fixed address are not specified.
EVM Gas rule changesUnder-specified2A gas charge is introduced for a new operation without changing an existing opcode's accounting or refund behavior, matching the anchor for a new, isolated accounting mechanism.
  • eip.md · Specification constants and New opcode, lines 25-31 and 72-83 The proposal assigns the new BEACON_ROOT operation a gas constant and specifies a fixed-cost storage-reading opcode.
Confidence: Medium
Uncertainty: The constants table names G_beacon_root, while the opcode text names the undefined G_beacon_state_root.
State-access ordering within opcode executionUnder-specified2The EIP introduces a new state-accessing operation whose stack, gas-charge, and storage-access ordering must be made consensus-exact, which is the score-2 anchor.
  • eip.md · Specification / EVM changes / New opcode, lines 72-85 BEACON_ROOT pops a slot from the stack and then performs an SLOAD-like read from the history address.
Confidence: Medium
Uncertainty: The pseudocode orders the pop and read but does not say where gas is charged or how exceptional execution is ordered relative to the read.
New invariant on pre-existing testsUnder-specified2A broad class of otherwise unrelated post-fork block tests gains a mechanical assertion about the new field, while the text does not require all pre-fork vectors to be re-derived; this matches score 2 rather than 3.
  • eip.md · Specification / Block structure and validity, lines 41-47 All blocks at or after the fork timestamp must carry the parent beacon-block root in an appended 32-byte header field.
Confidence: Medium
Uncertainty: The proposal supplies no test cases showing whether state-root effects would also become a universal asserted invariant.
Performance risksUnder-specified2The write loop, state-trie interaction, and dependence on slot gaps require validation in full block processing and can affect existing block benchmarks, but the specified impact is bounded to this pre-block mechanism rather than clearly substantial across the system.
  • eip.md · Specification / Block processing, lines 53-68 Every post-fork block performs protocol state writes in a loop over the elapsed slot range before transaction execution.
  • eip.md · Rationale / Beacon block root instead of state root, lines 98-105 The design explicitly considers work under skipped-slot conditions and chooses the block root to limit added work relative to a state-root design.
Confidence: Medium
Uncertainty: Undefined slot conversion and no stated timestamp-gap bound prevent a firm worst-case iteration and database-write assessment.
Added opcodesUnder-specified1This is a single opcode with no data portion, straightforward stack mechanics, and constant gas, meeting the score-1 simple-opcode anchor.
  • eip.md · Specification / EVM changes / New opcode, lines 72-85 One BEACON_ROOT opcode is added; it pops one word, performs one modulo-indexed storage read, pushes one word, and has a fixed stated gas cost.
Confidence: Medium
Uncertainty: The gas constant name is inconsistent, and exceptional stack/gas ordering is not detailed.
Block syncing changesUnder-specified1Syncing clients gain a single, structurally simple fork-conditional header-field validation rule, matching score 1.
  • eip.md · Specification / Block structure and validity, lines 41-47 Post-fork execution headers append one mandatory 32-byte parent beacon-root field, changing header size and validity.
Confidence: Medium
Uncertainty: The proposal does not spell out the block RLP form or validation error conditions.
Engine API changesUnder-specified1The cross-layer value must be communicated with the execution payload, implying one new payload/header field and therefore the score-1 Engine API consequence.
  • eip.md · Specification / Block structure and validity, lines 43-47 Execution clients must place the consensus-derived parent beacon-block root into the execution header after the fork.
Confidence: Low
Uncertainty: The EIP never names an Engine API endpoint, field, version, encoding, or validation responsibility.
Transition-tool interface changesUnder-specified1A transition tool must receive the single new header value to perform the mandatory pre-transaction write, matching the one-field score-1 anchor.
  • eip.md · Specification / Block structure and validity and Block processing, lines 43-53 State transition after the fork requires one new 32-byte parent beacon-root value from the block header.
Confidence: Medium
Uncertainty: No transition-tool interface is specified, so whether auxiliary slot or fork-context inputs are also needed depends on resolving other gaps.
New test-framework primitivesUnder-specified1Existing fixture primitives require at least a minor extension to represent the appended field, but the package does not establish a new reusable expectation or modifier abstraction.
  • eip.md · Specification / Block structure and validity, lines 41-47; Test Cases, lines 111-113 The block-header schema gains a fork-conditional field, while the proposal provides no test design beyond a TODO.
Confidence: Low
Uncertainty: The TODO test section leaves open whether special primitives for pre-block system writes or beacon-root expectations would be necessary.
Cryptography1The proposal integrates one well-specified, established Merkle-root mechanism rather than introducing novel cryptography, matching score 1.
  • eip.md · Abstract and Specification / Block structure and validity, lines 13-17 and 41-47 The new header commitment is the 32-byte hash-tree root of the parent beacon block.
  • supporting/ethereum-consensus-specs--ssz-simple-serialize.md · Merkleization, lines 210-248 The packaged reference defines the established SSZ chunking, Merkleization, and hash_tree_root construction used by the commitment.
Confidence: High
Cross-EIP interactions1The proposal has a limited design-level interaction with EIP-2935's history-in-state pattern but uses its own address and opcode and remains independently testable, matching score 1.
  • eip.md · Specification / Background, lines 33-39 The root-exposure method is explicitly described as inspired by EIP-2935.
  • supporting/eip-2935.md · Simple Summary and Specification, lines 12-15 and 25-34 EIP-2935 uses protocol-written history-contract state and an opcode read path for historical execution block hashes.
Confidence: High
Uncertainty: The text calls EIP-2935 inspiration rather than a normative dependency.
Interacting EIPs: EIP-2935
Show 9 zero-score criteria
Zero-score criteria (Checklist revision 2)
CriterionScoreWhy this scoreEvidence / uncertainty
Modified opcodes0No pre-existing opcode behavior is changed or deprecated.
  • eip.md · Rationale / Why not repurpose BLOCKHASH?, lines 93-96 The proposal explicitly leaves BLOCKHASH unchanged and adds a separate opcode to avoid breaking existing contracts.
Added precompiles0The proposal adds no precompile.
  • eip.md · Abstract and Specification / New opcode, lines 13-18 and 72-85 EVM access is provided through a new opcode reading state at a history address; no precompile is defined.
Modified precompiles0No pre-existing precompile is modified.
  • eip.md · Specification / EVM changes, lines 49-85 The EVM changes consist of protocol storage writes and a new opcode, with no reference to existing precompile logic or gas schedules.
Modified system contracts0No pre-existing system contract code, state, or behavior is modified.
  • eip.md · Abstract and Specification constants, lines 13-18 and 25-31 The proposal introduces a contract at a newly designated history address rather than identifying or altering an existing system contract.
Blob gas accounting changes0Nothing in the proposal meters, allocates, or otherwise changes blob gas.
  • eip.md · Specification, lines 23-31 and 41-85 The specified changes concern a header root, a pre-transaction state write, and an EVM opcode; no blob-gas rule is introduced or changed.
State gas accounting changes0A state mutation is introduced, but no separate state-gas accounting mechanism covered by this anchor is added or modified.
  • eip.md · Specification / EVM changes / Block processing, lines 51-70 The proposal mandates protocol-level SSTORE-like writes before transactions but specifies no state-gas price, budget, reservoir, or spill rule.
New EVM gas refund0The proposal introduces no EVM gas-refund mechanism.
  • eip.md · Specification / EVM changes / New opcode, lines 72-85 The new operation has a stated gas cost and read result, with no refund-producing condition or refund-counter change.
New transaction types0No new transaction type is introduced.
  • eip.md · Abstract and Specification, lines 13-18 and 23-85 The change is to headers, block processing, state, and an opcode; it defines no transaction envelope or type identifier.
New or modified transaction validity mechanisms0Existing transaction types retain their validity and intrinsic gas rules.
  • eip.md · Specification / Block structure and validity and Block processing, lines 41-70 The validity and processing rules are attached to blocks and occur before transactions; no transaction validity or intrinsic-gas rule is stated.
Assessment provenance
Assessed EIP revision
ethereum/EIPs@5b909b76ac EIPS/eip-4788.md committed 2023-04-13 · information cutoff 2023-04-27
Current master · File history · blob a2553d4b78 · sha256 4df9dad7b1f5
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/05-retrospective-complexity-assignment/outputs/fork-eips/cancun/eip-4788.yaml · sha256 ed18b58392a9
Supporting documents in the sealed package
supporting/eip-2935.md, supporting/ethereum-consensus-specs--ssz-simple-serialize.md
Compare EIP-4788 with other assessmentsAll Cancun / Dencun assessments
Criterion legend and glossary

Every stacked bar, comparison matrix, and criterion table on this site uses the same criterion colours, abbreviations, and order. Colour marks the criterion group; the abbreviation and name identify the criterion. Scores are 0–3 per criterion (4 is exceptional; cross-EIP interactions is uncapped).

EVM surface

Opcodes, precompiles, and system contracts that are added or modified.

  • Added opcodes
    Introduces new opcodes
    Score anchors
    0
    No new opcodes are introduced.
    1
    A new simple opcode is introduced (no data portion, no complex stack mechanics, and a constant gas cost).
    2
    Multiple new simple opcodes are introduced, or a single new complex opcode is introduced (has data portion, or complex stack mechanics, or a dynamic gas cost).
    3
    Multiple new opcodes are introduced, and at least one of them is complex (has data portion, or complex stack mechanics, or a dynamic gas cost).
    • Cryptography opcodes are not considered complex by default. Refer to the "Cryptography" section for a separate assessment.
  • Modified opcodes
    Modifies pre-existing opcodes
    Score anchors
    0
    No pre-existing opcode modifications are introduced.
    3
    At least one pre-existing opcode's behavior is modified (not including gas changes) or a pre-existing opcode is deprecated.
  • Added precompiles
    Introduces new precompiles
    Score anchors
    0
    No new precompiles are introduced.
    1
    A new simple precompile is introduced (constant input length, constant gas cost).
    2
    Multiple new simple precompiles are introduced, or a single new complex precompile is introduced (dynamic input length or dynamic gas cost).
    3
    Multiple new precompiles are introduced, and at least one of them is complex (dynamic input length or dynamic gas cost).
    • Cryptography precompiles are not considered complex by default. Refer to the "Cryptography" for a separate assessment.
  • Modified precompiles
    Modifies pre-existing precompiles logic or gas-accounting
    Score anchors
    0
    No pre-existing precompiles are modified.
    1
    At least one pre-existing precompile has its gas schedule modified.
    2
    Multiple pre-existing precompiles have their gas schedule modified, or a single pre-existing precompile has its behavior modified.
    3
    The behavior of multiple pre-existing precompiles, or a single complex pre-existing precompile modified.
  • Added system contracts
    Introduces new system contract, stateful or not
    Score anchors
    0
    No new system contracts are introduced.
    1
    A new system contract is introduced that is not stateful nor does it trigger a new system action (e.g. requests to the consensus layer).
    2
    Multiple new system contracts are introduced or a single new system contract that is either stateful or triggers a new system action (e.g. requests to the consensus layer).
    3
    Multiple new system contracts are introduced and at least one of them is either stateful or triggers a new system action (e.g. requests to the consensus layer).
  • Modified system contracts
    Modifies pre-existing system contracts
    Score anchors
    0
    No modifications to pre-existing system contracts are introduced, directly or indirectly.
    1
    Does not directly modify any system contract, but its behavior has minor indirect effects on one or more system contracts.
    2
    Does not directly modify any system contract, but its behavior has major indirect effects on one or more system contracts.
    3
    At least one pre-existing system contract code or state is modified, which would involve irregular state transition or a similarly complex transition methodology.

Gas and accounting

Execution, blob, and state gas rules, refunds, and where charges happen inside opcodes.

  • EVM Gas rule changes
    New EVM gas accounting rules
    Score anchors
    0
    No gas accounting changes.
    1
    Existing gas accounting mechanism is updated.
    2
    A new gas accounting mechanism is introduced but it does not affect existing mechanisms nor does it affect existing tests.
    3
    A new gas accounting mechanism is introduced and affects existing mechanisms which in turn affect existing tests.
  • State-access ordering within opcode execution · Checklist revision 2 only
    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.
    Score anchors
    0
    No change to where state is accessed, or to where gas is charged relative to a state access, within any opcode.
    1
    A single opcode's state-access or gas-charge ordering changes.
    2
    Multiple opcodes' ordering changes, or a new state-accessing operation is introduced whose position in the order must be settled.
    3
    The ordering rule changes for a whole class of state-accessing opcodes at once, or what counts as a recordable state access is redefined — requiring existing BAL vectors to be re-derived across opcodes and forks.
    • Distinct from "Modified opcodes", which asks whether an opcode's **result** changed. This row asks about the **path to the result**, which is observable even when the result is identical. An EIP can be 0 on that row and 3 on this one.
    • Score changes **to** the ordering. Do not score the fact that state accesses are observable — they always are.
    • Each boundary must be re-tested against every other dimension that can change the answer (cold/warm, static/non-static, delegated/direct, revert/success), so the case count grows multiplicatively rather than additively. Note this explicitly under Special Considerations.
  • Blob gas accounting changes
    New Blob gas accounting rules which potentially affect pre-existing tests
    Score anchors
    0
    No blob gas accounting changes.
    1
    Existing blob gas accounting mechanism is updated.
    2
    A new blob gas accounting mechanism is introduced but it does not affect existing mechanisms nor does it affect existing tests.
    3
    A new blob gas accounting mechanism is introduced and affects existing mechanisms which in turn affect existing tests.
  • State gas accounting changes · Checklist revision 2 only
    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.
    Score anchors
    0
    No state gas accounting changes.
    1
    An existing state gas cost or `STATE_BYTES_PER_*` rate is adjusted.
    2
    A new state-gas-charging site is introduced, or the block-level state gas budget or reservoir allocation is modified.
    3
    A new state gas charging mechanism is introduced, or the spill interaction between state gas and execution gas is modified, affecting existing gas tests.
    • Harder to test than blob gas: the spill path means state gas cannot be metered independently of execution gas, and some costs (e.g. `NEW_ACCOUNT`) are state-dependent.
  • New EVM gas refund
    New gas-refund mechanism
    Score anchors
    0
    No new gas-refund mechanisms are introduced.
    1
    A new simple gas-refund mechanism is introduced that does not affect either existing tests or existing gas-refund mechanisms.
    2
    A new complex gas-refund mechanism is introduced or a simple mechanism that affects existing tests or existing gas-refund mechanisms.
    3
    A new complex gas-refund mechanism is introduced that affects existing tests or existing gas-refund mechanisms.

Blocks, transactions, and encoding

Transaction types and validity, block and header fields, encodings, syncing, and activation-time changes.

  • New transaction types
    Introduces a new transaction type
    Score anchors
    0
    No new transaction types are introduced.
    3
    A new transaction type is introduced.
  • New or modified transaction validity mechanisms
    Creates new or modifies pre-existing transaction types' validation mechanisms
    Score anchors
    0
    No changes are introduced to the validity rules of existing transaction types or to their intrinsic gas cost calculation.
    1
    Minor adjustments are introduced to validity rules or intrinsic gas cost calculation, but they do not significantly affect existing tests.
    2
    Changes to validity rules or intrinsic gas cost calculation affect existing tests, but require only limited updates to test cases and no redesign of the testing infrastructure.
    3
    Changes to validity rules or intrinsic gas cost calculation require extensive rework or redesign of the tests or testing infrastructure.
  • New block / header fields
    Introduces new block or block header fields
    Score anchors
    0
    No new block or header fields are introduced.
    3
    A new block or header field is introduced.
  • Encoding changes (RLP/SSZ)
    Introduces encoding changes at the transaction/block/interfaces level
    Score anchors
    0
    No encoding changes are introduced at the transaction, block, or interfaces levels.
    3
    An encoding change is introduced at transaction, block or interfaces level (e.g. RLP -> SSZ).
    • "Interfaces level" includes the Engine API. Score an Engine API encoding change (e.g. JSON -> SSZ) here.
  • Block syncing changes
    Modifies block RLP validation mechanisms that require test client syncing.
    Score anchors
    0
    No new RLP validation mechanism is introduced.
    1
    A single simple RLP validation mechanism is introduced.
    2
    Multiple simple RLP validation mechanisms are introduced or a single complex one.
    3
    Multiple RLP validation mechanisms are introduced and at least one of them is deemed complex.
  • New fork activation mechanism
    Modifies state, internal variables, or similar, at the fork activation block
    Score anchors
    0
    No state modifications, internal variables or similar are modified at the fork activation block.
    3
    Either a state modification or internal variables are modified at the fork activation block.
    • Initialization of new internal variable is not considered a modification.

Client interfaces

Engine API and transition-tool interface changes.

  • Engine API changes
    Introduces new fields to the Engine API directives
    Score anchors
    0
    No new fields or communication mechanisms are introduced to the Engine API.
    1
    A single new field is introduced in one of the Engine API endpoints.
    2
    Multiple fields are introduced to one or multiple Engine API end points, or a new Engine API end-point is introduced.
    3
    Multiple fields are introduced to one or multiple Engine API end points and a new Engine API end-point is introduced.
  • Engine API encoding changes · Checklist revision 1 only
    Engine API encoding changes (the revision-1 template defines no anchor text for this row).
  • Transition-tool interface changes
    Modifies or adds new fields to the transition tool interface.
    Score anchors
    0
    No modifications to the transition tool interface are required.
    1
    A single new field needs to be introduced to the transition tool interface.
    2
    Multiple new fields or a new mechanism has to be introduced to the transition tool interface.
    3
    Multiple new fields and a new mechanism has to be introduced to the transition tool interface.
    • Special consideration must be paid to this section if the EIP introduces a mechanism that requires the state transition tool to be aware whether the block it is processing is the fork-activation block.

Testing impact

Rework, new invariants, and new primitives required in the test framework.

  • Patterns affecting pre-existing tests
    Implements a new validation mechanism or rule that translates in reworking pre-existing tests
    Score anchors
    0
    No pre-existing tests are affected by this change.
    1
    Minor subset of existing tests are affected by this change.
    2
    Considerable subset of existing tests are affected by this change but involves only a contrived category of tests.
    3
    Major subset of existing tests are affected, including diverse category of tests (benchmarks, static, multiple forks, etc.).
  • New invariant on pre-existing tests · Checklist revision 2 only
    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.
    Score anchors
    0
    Pre-existing tests assert nothing new.
    1
    A narrow, contrived category of pre-existing tests gains a new assertion.
    2
    A broad category gains a new assertion, applied mechanically.
    3
    Every test in the fork gains the assertion regardless of what it tests, and pre-fork vectors must be re-derived to satisfy it.
    • Paired with the row above, and easy to confuse with it. "Patterns affecting pre-existing tests" asks whether existing tests must be **reworked**; this row asks whether they must **additionally assert something new**. Score both — an EIP can be low on one and high on the other.
  • New test-framework primitives · Checklist revision 2 only
    Requires new abstractions in the test framework itself — expectation types, modifiers, helpers — beyond writing test functions with what already exists.
    Score anchors
    0
    Existing test primitives suffice.
    1
    Existing primitives need minor extension.
    2
    New expectation or modifier primitives are required, reusable within this EIP's own test suite.
    3
    New framework-level primitives are required that become a permanent part of the framework and are used by other EIPs' tests.

Risk and validation

Security, performance, boundary conditions, and cryptography that need validation.

  • Security risks
    Introduces or modifies mechanisms that could compromise the security of the chain, users, validators, or other stakeholders, if not implemented properly.
    Score anchors
    0
    No new mechanisms are introduced that could pose a security risk.
    1
    The introduced mechanisms are self-contained, can be validated in isolation, and do not alter existing invariants that could pose a security risk for any stakeholders.
    2
    The introduced mechanisms interact with a limited number of existing components, slightly altering their security assumptions and requiring a targeted security review or fuzzing.
    3
    The introduced mechanisms interact with multiple existing components, including critical ones, substantially altering their security assumptions and requiring an extensive security review and fuzzing.
  • Performance risks
    Introduces or modifies mechanisms and requires performance validation.
    Score anchors
    0
    No new mechanisms are introduced that require performance validation.
    1
    The introduced mechanisms can be benchmarked in isolation and do not affect existing performance behavior.
    2
    The introduced mechanisms cannot be fully benchmarked in isolation, but they only have a limited impact on the existing performance benchmarks.
    3
    The introduced mechanisms cannot be benchmarked in isolation and have a substantial impact on existing performance benchmarks or have complex interactions with existing mechanisms.
  • Edge/boundary conditions
    Feature contains edge/boundary conditions.
    Score anchors
    0
    No discernible edge cases or boundary conditions are introduced.
    1
    A single edge-case or boundary-condition prone mechanism is introduced.
    2
    Multiple edge-case or boundary-condition prone mechanisms are introduced, but none of them requires an elevated number of cases to test.
    3
    Multiple edge-case or boundary-condition prone mechanisms are introduced and at least one of them requires an elevated number of cases to test.
  • Cryptography
    Introduces new cryptography mechanisms or modifies existing functionality that involves cryptography
    Score anchors
    0
    No cryptography mechanisms are introduced.
    1
    A new cryptography mechanism is introduced but it is a well known mechanism that is known to have vast resources to aid on its testing.
    2
    Multiple new cryptography mechanisms are introduced that are well-known or a single but novel mechanism is introduced that is either untested or has limited resources.
    3
    Multiple new cryptography mechanisms are introduced and at least one of them is a novel mechanism.

Coordination

Cross-EIP interactions and behavior that clients must agree on before tests exist.

  • Cross-EIP interactions
    Introduces or modifies mechanisms that affect other EIPs in either the same or past forks.
    Score anchors
    0
    Fully self-contained EIP that does not depend on, modify, or conflict with any other EIP.
    1
    The EIP interacts with one or more other EIPs in a non-critical and limited way but can be tested independently for the most part.
    2
    The EIP depends on or modifies one or more other EIPs such that coordinated testing and consideration is required, but interactions are limited in scope and not complex.
    3
    The EIP has strong interdependencies with multiple EIPs, requiring extensive coordinated cross-EIP testing as well as potential re-design of existing test vectors.
    • +1 for every 3 additional interacting EIPs beyond the first 3, each of which requires its own coordinated test cases. List the EIPs in the rationale.
    • This row is intentionally uncapped, unlike every other anchor: each interacting EIP is another axis of the test matrix, so a ceiling would make a 12-EIP product indistinguishable from a 3-EIP one.
  • Unspecified behavior requiring cross-client consensus · Checklist revision 2 only
    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.
    Score anchors
    0
    The EIP text determines the answer for every case a test could construct.
    1
    A few details are unspecified but have an obvious intended reading.
    2
    Details require client agreement before tests can be written, but they are localized.
    3
    A previously unspecified *and previously unobservable* behavior becomes consensus-critical; expect tests to be re-baselined on each round of EIP amendment.
    • Score this from the EIP's state at assessment time: whether it has client implementations, whether it has been through a devnet, and how many open questions remain on its discussion thread.