EIP-7702: Consensus bugs in authorization processing (meta)

[bshastry]

Overview

Multiple consensus bugs in evmone's EIP-7702 (Set Code Transaction) authorization processing were found via differential fuzzing. All bugs reside in process_authorization_list() within the state transition layer (test/state/state.cpp), NOT in the EVM bytecode interpreter.

Root Cause

All bugs stem from the same architectural mismatch: evmone's get_or_insert() conflates two distinct operations:

1. EIP-2929 access list warming — a metadata operation that should NOT mutate the state trie
2. Account creation/touching — a state mutation that creates the account in the trie

In geth, these are cleanly separated:

• AddAddressToAccessList() only modifies the access list (a transaction-scoped data structure)
• GetOrNewStateObject() / createObject() creates the account in the state trie

Sub-Issues

• EIP-7702 authorization accepts invalid y_parity (v=29) #1444 — EIP-7702 authorization accepts invalid y_parity (v=29)
• EIP-7702: Authority accounts warmed after validation instead of before #1447 — Authority accounts warmed after validation instead of before (2,500 gas difference)
• EIP-7702: Incorrect refund calculation for warming-only authority accounts #1448 — Incorrect refund calculation for warming-only authority accounts (12,500 gas difference)

Impact

Production: None. No production blockchain uses evmone's state transition layer for consensus. The bugs affect evmone-statetest/t8n testing tooling only. The EVM bytecode interpreter (lib/evmone/) is unaffected.

Downstream: zvm1 (erigontech fork) contains unfixed code for #1447 and #1448. Zilkworm uses zvm1's state transition directly but is explicitly marked as not production-ready.

Fix

A fix for #1447 and #1448 is available on branch fix/eip7702-authority-warming (commit a7e51739).

Found by goevmlab-based differential fuzzer maintained by the EF Protocol Security team.