Evmv2 poc

[siladu]

PR description

Reference branch of EVM V2 that attempts to migrate the code from https://github.com/ahamlat/besu/tree/optimize-wei-operations into the EVM V2 skeleton structure.

Adds -Dtest.evm.v2=true to enable v2 for referenceTests and referenceTestsDevnet.

• ./gradlew referenceTests -Dtest.evm.v2=true passing
• evmtool --Xevm-v2=true block-test ... for eest benchmarks passing

Gets in sync on mainnet, still measuring performance.
Not tested with glamsterdam devnets/tests

---

Key Architectural Insights

1. The dual-stack trap: V1 OperandStack and V2 long[] are completely independent. Any V1 stack method (stackSize(), popStackItem()) returns wrong results in V2 mode. Every V2 operation must exclusively use V2 stack methods (stackTopV2, stackHasItems).

2. The shadow registry problem: V1 uses a fork-aware OperationRegistry (each fork registers only valid opcodes). V2's static switch bypasses this — it must manually replicate every fork gate. Two patterns coexist: inline ternary (enableByzantium ? ... : Invalid) and internal checks in staticOperation(). The inconsistency makes omissions hard to spot.

3. Read-only vs mutable account access: WorldUpdater.getAccount() wraps in UpdateTrackingAccount, marking as "touched". WorldUpdater.get() is pure read. V1's AbstractOperation.getAccount(addr, frame) helper does the right thing; V2 operations initially called the mutable path directly.

4. Gas mutation ordering matters: gasAvailableForChildCall() mutates frame gas internally. Must be called AFTER decrementRemainingGas(cost), not before. A 1-line reorder fixed 2/940 test failures.

5. 0-input operations are the canary: When testing opcode validity per fork, only operations that need zero stack items (STOP, PUSH0, RETURNDATASIZE, SLOTNUM, etc.) produce different outcomes when incorrectly enabled. Stack-consuming operations fail via underflow regardless.

V2 Dispatch Exception Handling

The V2 dispatch loop only catches OverflowException and UnderflowException — it assumes all operations are crash-proof. Raw JVM exceptions (like IndexOutOfBoundsException) propagate all the way to the block processor, which rejects the block as invalid. In V1, each operation's execute() has its own try-catch and returns OperationResult — the dispatch never sees raw exceptions.

The CALLDATALOAD IndexOutOfBoundsException exploited this design: when (int)0x80000000L wraps to negative, tuweni's slice() throws. Fixed with (s[off + 3] >>> 31) != 0 which catches any long whose bit-31+ is set.

[siladu]

re: stack underflow/overflow

• stackHasSpace(n) : return stackTopV2 + n <= txValues.maxStackSize()
• Push/DUP operations guard both directions:

// PushOperationV2:
if (!frame.stackHasSpace(1)) return OVERFLOW_RESPONSE;

// DupOperationV2:
if (!frame.stackHasItems(index)) return UNDERFLOW_RESPONSE;
if (!frame.stackHasSpace(1)) return OVERFLOW_RESPONSE;

★ Insight ─────────────────────────────────────

• The evmv2-poc branch treats underflow and overflow as symmetric pre-conditions: every operation checks exactly what it needs — underflow guard for items consumed, overflow guard for items produced — rather
  than relying on the exception-based safety net from V1's OperandStack.
• This is a better pattern for performance: exceptions are expensive to construct and throw, so replacing them with simple integer comparisons at hot-path boundaries is worth the discipline of writing
  explicit checks.
  ─────────────────────────────────────────────────