Retrospective LLM-Based Complexity Evaluations

Shared comparison

Compare assessments

Select up to 6 assessments, from either evaluator and any EIP, to compare their complexity profiles side by side and criterion by criterion. The selection lives in this page's URL, so the view can be shared and reproduced.

    Nothing selected yet. Add assessments above, or select rows on the EIP index or any fork page.

    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
    • Modified opcodes
      Modifies pre-existing opcodes
    • Added precompiles
      Introduces new precompiles
    • Modified precompiles
      Modifies pre-existing precompiles logic or gas-accounting
    • Added system contracts
      Introduces new system contract, stateful or not
    • Modified system contracts
      Modifies pre-existing system contracts

    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
    • 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.
    • Blob gas accounting changes
      New Blob gas accounting rules which potentially affect pre-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.
    • New EVM gas refund
      New gas-refund mechanism

    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
    • New or modified transaction validity mechanisms
      Creates new or modifies pre-existing transaction types' validation mechanisms
    • New block / header fields
      Introduces new block or block header fields
    • Encoding changes (RLP/SSZ)
      Introduces encoding changes at the transaction/block/interfaces level
    • Block syncing changes
      Modifies block RLP validation mechanisms that require test client syncing.
    • New fork activation mechanism
      Modifies state, internal variables, or similar, at the fork activation block

    Client interfaces

    Engine API and transition-tool interface changes.

    • Engine API changes
      Introduces new fields to the Engine API directives
    • 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.

    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
    • 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.
    • 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.

    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.
    • Performance risks
      Introduces or modifies mechanisms and requires performance validation.
    • Edge/boundary conditions
      Feature contains edge/boundary conditions.
    • Cryptography
      Introduces new cryptography mechanisms or modifies existing functionality that involves cryptography

    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.
    • 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.
    Browse all assessmentsDownload the compare index