Skip to content

EIP-8037: check_transaction state gas pre-check is stricter than the EIP #2578

@yperbasis

Description

@yperbasis

Summary

The EELS check_transaction in the Amsterdam fork adds a per-tx state gas dimension check that is stricter than what EIP-8037 specifies. This can reject valid blocks.

EIP-8037 block validity rule

The EIP defines block-level validation only:

Track separate counters: block_regular_gas_used and block_state_gas_used
Block validity uses: gas_used = max(block_regular_gas_used, block_state_gas_used)

No per-transaction pre-check on the state gas dimension is specified.

EELS check_transaction (stricter)

state_gas_available = block_env.block_gas_limit - block_output.block_state_gas_used

if tx.gas > state_gas_available:
    raise GasUsedExceedsLimitError("state gas used exceeds limit")

This reserves the tx's full gas limit against the state gas budget, even though the tx may consume far less state gas.

Example of a valid block rejected by the pre-check

block_gas_limit = 100

tx1: regular_gas = 10, state_gas = 50
tx2: gas_limit = 60, regular_gas = 50, state_gas = 10

Per-tx check before tx2:
  state_gas_available = 100 − 50 = 50
  tx2.gas_limit = 60 > 50 → REJECT

EIP block-end check:
  max(Σ regular = 60, Σ state = 60) = 60 ≤ 100 → VALID

The block satisfies the EIP's block-end validity rule but is rejected by the EELS pre-check.

Question

Is this intentional? If so, should the per-tx state gas reservation requirement be added to the EIP text? If not, should check_transaction be relaxed to only validate against actual state gas usage at block end?

This also affects the regular gas pre-check (min(TX_MAX_GAS_LIMIT, tx.gas) > regular_gas_available), which similarly reserves the full tx gas limit against the regular dimension.

Metadata

Metadata

Assignees

Labels

A-spec-specsArea: Specification—The Ethereum specification itself (eg. `src/ethereum/*`)

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions