execution-client-hardening

name	execution-client-hardening
description	L1 trigger - audits execution engine (EVM interpreter, WASM, SVM) for memory corruption, gas mispricing (EXTCODESIZE class), opcode semantics, and VM invariant breaks.

Injectable Skill: Execution Client Hardening

L1 trigger: L1_PATTERN=true AND (core/vm/ OR revm OR interpreter OR opcodes.go OR evm-exec OR svm/ OR move-vm OR wasmi detected in recon subsystem map) Inject Into: depth-state-trace or depth-external Language: Go, Rust, occasionally C++ Finding prefix: [EX-N] Status: v0.1 draft, Round 4 exemplars pending

Orchestrator Decomposition Guide

• Sections 1, 2: depth-state-trace (VM state transitions)
• Sections 3, 4: depth-edge-case (opcode semantics)
• Section 5: depth-external (gas metering)
• Section 6: depth-consensus-invariant (cross-client consistency)

When This Skill Activates

Recon identifies a VM / execution engine. Covered VMs: EVM (all execution clients), SVM (Solana), Move VM (Aptos, Sui), WASM runtimes (NEAR, Polkadot), custom VMs. Client-vs-client divergence in VM behavior is Critical — historically several Ethereum consensus splits were VM implementation bugs.

1. Opcode Coverage Mapping

Enumerate every opcode / instruction the VM supports. For EVM, consult the latest Yellow Paper + EIPs. For others, the spec document.

Opcode	Gas cost	Stack delta	State touched	Notes

This mapping grounds later checks. A new client must implement every opcode; a fork client must not accidentally remove or reprice any opcode.

Tag: [OPCODE-COVERAGE:{missing-or-extra}]

2. Gas / Resource Metering

Every operation must be priced to cover its real cost. Historical bugs: Ethereum Shanghai attacks (2016) — EXTCODESIZE was too cheap relative to disk I/O.

Patterns to check

• Disk-touching opcodes: SLOAD, SSTORE, EXTCODESIZE, EXTCODECOPY, EXTCODEHASH, BALANCE. Gas cost must reflect the (possibly cold) storage fetch.
• Recursive opcodes: CALL, DELEGATECALL, CALLCODE, STATICCALL. Gas forwarding (63/64 rule) correctness.
• Memory-expanding opcodes: MLOAD, MSTORE, RETURNDATACOPY, MCOPY. Memory expansion gas must be computed before the access.
• Hashing: KECCAK256 cost proportional to input size.
• Log emission: LOG0-LOG4 cost proportional to data size.

Warm/cold access (EIP-2929)

• Access list enforcement: first touch is cold (more expensive), subsequent warm
• Is the access list correctly reset per transaction?
• On reverted subcalls, does the access list roll back correctly?

Tag: [GAS-MISPRICE:{opcode}:{actual-cost}:{charged-cost}]

3. Opcode Semantics

For each opcode, the semantics must match the spec exactly. Common drift points:

3a. SELFDESTRUCT

• Pre-Cancun: destroys contract, transfers balance
• Post-Cancun (EIP-6780): only transfers balance if called in same tx as creation
• Bug class: incorrect balance accounting (see Optimism OVM_ETH exemplar)

3b. CREATE / CREATE2

• Address calculation: CREATE = hash(sender, nonce); CREATE2 = hash(0xff, sender, salt, init_code_hash)
• Collision handling: what happens if the computed address already has code/balance/nonce?
• Init code size limit (EIP-3860)

3c. RETURNDATACOPY

• Out-of-bounds access must revert (EIP-211)
• Returns empty buffer if no return data (not panic)

3d. PUSH0 (EIP-3855)

• Valid only post-Shanghai. Pre-Shanghai must be invalid.

3e. TLOAD / TSTORE (EIP-1153)

• Transient storage; resets per transaction
• Interaction with reverts

3f. MCOPY (EIP-5656)

• Memory copy, post-Cancun

3g. BLOBHASH / BLOBBASEFEE (EIP-4844)

• Blob-related

Tag: [OPCODE-SEM:{opcode}:{drift}]

4. Precompiles

Precompiles are native implementations of common functions at fixed addresses.

Check per precompile

• Is the precompile address correct? (e.g., 0x01 ECRECOVER, 0x02 SHA256, ...)
• Is the gas cost formula correct? Many precompiles have length-dependent gas.
• Is the input validated? Precompile panics crash the client.
• Context-dependent inputs (like Moonbeam's precompile-delegatecall bug): does the precompile care whether it's invoked via CALL vs DELEGATECALL? If yes, is it enforced?

Tag: [PRECOMPILE:{address}:{issue}]

5. Memory Safety

For Go clients, memory safety is largely on the runtime. For Rust clients (reth, revm), unsafe blocks in the VM are a bug source.

Check:

• Every unsafe in the interpreter hot path
• Every raw pointer manipulation
• Every length-based slicing — off-by-one crashes the VM

Interaction with rust-unsafe-audit skill.

5b. Interned/Compacted Identity Coherence

Trigger: The code assigns a compact numeric index or handle to a named entity (a type, account, resource, module, or similar) — typically to avoid storing the full name/key repeatedly — and one or more OTHER structures cache data derived from that entity, keyed by the compact index rather than by the entity's original identity. Common in interning tables, symbol/type caches, and any "intern this name once, refer to it by a small integer afterward" optimization (for example, a Move VM-style loader that interns module/type identities into a numeric table).

Why this is structurally distinct from §8's cache lifecycle set-cover: §8 concerns a SINGLE bounded cache whose OWN entries go stale or grow unbounded. This section concerns MULTIPLE structures that share one index/ handle space, where one structure can be reset/compacted while a SIBLING structure — keyed by the same index space — is not, so a recycled index silently points a stale consumer at a different entity's data. This is an asymmetric-invalidation bug across coupled structures, not a single eviction policy gap, and set-cover on one structure's legs will not catch it.

Methodology:

1. Enumerate every structure keyed by the index/handle space — not just the primary interning map. Grep for the index type's name (e.g. a TypeIndex, ModuleHandle, or similar newtype) across the codebase and list every map/vector/cache that uses it as a key, not just the one that assigns it.
2. For every reset / flush / compact / GC path on ANY of those structures, verify that ALL of them are invalidated together, in the SAME atomic step. A reset that clears the primary interning table but leaves a derived cache populated (or vice versa) is the bug.
3. Check whether index/handle assignment can restart from a low or previously-used value after a partial reset (e.g. a counter reset to 0, or a freelist that recycles slots). If assignment can produce a value that used to belong to a different entity, and any sibling structure still holds an entry under that recycled value, a lookup now silently resolves to the WRONG entity's data instead of erroring.
4. Trace whether any derived identity is computed by looking up the recycled index in a structure that is NOT part of the reset — e.g. a storage/lookup key, a resource type, or a permission/capability scope derived by indexing into a stale sibling structure. This is the concrete exploitation mechanism: the recycled index doesn't just serve stale bytes, it makes the system compute a DIFFERENT identity than the one the caller intended (structurally analogous to a native-vs-wrapped token mixup, where the same numeric handle is silently resolved against the wrong underlying asset).

Required check: for the primary index/handle-assigning structure and every sibling structure found in step 1, confirm they are reset by the SAME function/transaction boundary, not by independently-triggered paths. Two reset paths that are supposed to stay in lockstep but are invoked from different call sites are a red flag even if both eventually run.

Tag: [IDENTITY-COHERENCE:{index-space}:{structures-affected}]

Severity baseline: High to Critical when the recycled index can be attacker- influenced (attacker controls timing/ordering of the partial reset and the next allocation) and the derived identity affects storage/permission resolution; Medium when reachable only through operator/admin-triggered resets.

6. Cross-Client Consistency (for forks and alt-clients)

If the target is a fork of an upstream execution client:

1. git diff upstream/main...HEAD -- core/vm/ (or equivalent)
2. For each modified opcode, cross-check against the reference (EVM reference implementation py_ecc or execution-spec-tests)
3. For each precompile, test with reference vectors

Tag: [VM-DRIFT:{opcode-or-precompile}]

7. Boundary conditions

State	Test	Expected	Observed
Empty code	contract with 0 bytes	spec-defined
Max code size	24576 bytes (EIP-170)	accepted
Code size + 1	24577 bytes	rejected on CREATE
Gas = 0	call with 0 gas	out-of-gas
Stack overflow	1025 items on stack	revert, not panic
Stack underflow	POP on empty stack	revert, not panic
Memory OOB	MLOAD from MAX_U256	out-of-gas (memory expansion cost)
SELFDESTRUCT after state change	tx does CREATE then SELFDESTRUCT	correct accounting (post-EIP-6780)

8. Output schema

• Layer: execution
• Bug class: gas-misprice / opcode-semantics / precompile / memory-safety / cross-client-drift
• Preferred evidence tags: [CONFORMANCE-PASS] (execution-spec-tests / Hive) > [DIFF-PASS] (Fluffy-style differential) > [LSP-TRACE]
• Severity baseline: Critical for cross-client divergence; High for gas mispricing; Medium for precompile bugs without fund loss

9. Known bug exemplars (v0.2 — Round 4 verified)

1. 2016 Shanghai EXTCODESIZE DoS (block 2283416) — EXTCODESIZE cost ~20 gas but required a disk read of contract code. Attacker invoked it ~50k times per block, forcing 50k disk reads and 20-60s block validation times. Parity unaffected, Geth crawled to a halt. Fix codified as EIP-2929 years later. EF blog; ethos.dev Shanghai attacks. Skill catch point: Section 2 — the gas-per-disk-read ratio is the core invariant. Any opcode where (disk_reads × disk_latency) >> (gas_cost × gas_rate) is a gas-mispricing finding.

2. Geth RETURNDATACOPY corruption (CVE-2020-26241, Fluffy OSDI '21) — precompile dataCopy did shallow copy of input; subsequent memory write aliased RETURNDATA, causing divergence from other clients. Found via multi-tx differential fuzzing. Fluffy paper. Skill catch point: Section 4 (precompiles) — every opcode that writes to RETURNDATA must fully copy, not alias.

3. Geth transfer-after-destruct (CVE-2020-26265, Fluffy OSDI '21) — transfer semantics to already-destructed contract diverged between Geth and OpenEthereum. Caused mainnet hard fork event 4 months after disclosure. Skill catch point: Section 3a (SELFDESTRUCT semantics) — model contract lifecycle transitions (create → live → destruct → resurrect) and verify each produces identical output across clients.

4. Aptos MoveVM integer overflow DoS (October 2022) — MoveVM arithmetic lacked overflow guard; crafted input triggered DoS / chain halt potential. Patched. CyberExpress report. Skill catch point: Section 5 (memory safety / arithmetic) — every VM arithmetic op must use checked_* or explicit modular arithmetic. Every as cast between integer widths is a narrowing-overflow candidate.

5. Moonbeam precompile CALL/DELEGATECALL confusion ($1M + $50k bounty, pwning.eth, 2022) — Moonbeam's custom precompiles (XC-20, staking, democracy) did not distinguish CALL from DELEGATECALL. A malicious contract could DELEGATECALL the precompile and impersonate msg.sender of the original caller, accessing precompile storage of any user. Immunefi bugfix review. Skill catch point: Section 4 — for every custom precompile, assert at entry. See also .

Critical methodology addition from Round 4 (gas-per-disk-read ratio)

Insert as new Section 2f: The Shanghai lesson has been re-learned multiple times. The core invariant:

For every opcode O:
  worst_case_wall_clock(O) <= gas_cost(O) / target_gas_rate

Where target_gas_rate is the protocol's gas-per-second target (Ethereum: ~10M gas / 12s = 833k gas/s).

Check: for every opcode that touches disk, network, or complex computation, compute worst_case_wall_clock / gas_cost. Any ratio suggesting the opcode can be invoked enough times per block to violate the gas-rate budget is a finding.

Tag: [GAS-RATIO:{opcode}:{worst-ns}:{gas-cost}:{violates?}]

9. Unused Configuration Parameter Audit

A parameter declared in struct Config / Params / ChainSpec that is never read is often a missing enforcement — the developer intended the parameter to cap something but forgot to wire it in. This class hides real resource-bound vulnerabilities.

Methodology:

1. Find every public field in the protocol's Config / Params / ConsensusParams / ChainConfig struct.
2. For each field, grep the entire codebase for read sites. Use pre-baked {SCRATCHPAD}/scip/xref_map.md or Grep on .{field_name}. (MCP tools are unavailable in subagent contexts per Claude Code bug #25200.)
3. A field with ZERO read sites in any validator / enforcer / adjuster is a finding.
4. A field read only in test / debug / display code is a finding — it means production doesn't enforce it.
5. Pay special attention to fields with names like max_*, min_*, limit_*, cap_*, ceiling_*, floor_*, bound_* — these are almost always intended as enforcement.
6. A field read only in ONE branch of a condition may be dead in the hot path.

Required artifact: {SCRATCHPAD}/config_parameter_usage.md:

| Field | Declared at | Read sites (count) | Enforced? | Notes |
|---|---|---|---|---|
| max_validators | ChainConfig:L42 | 3 | YES | EndBlocker.apply_updates |
| max_difficulty_adjustment_factor | ChainConfig:L51 | 0 | **NO** | **UNUSED — difficulty spike unbounded** |
| min_commit_depth | ChainConfig:L63 | 1 (test only) | **NO** | read only in test_harness.rs |
| max_commitment_txs_per_block | ChainConfig:L89 | 0 | **NO** | **UNUSED — commitment flood possible** |

Every "NO" row is a finding. Severity depends on what the parameter was supposed to bound — parameters that would have capped a resource are Medium to High.

False positives: parameters read only by genesis (legitimately one-time), parameters read transitively through a cloned config struct (grep misses it — verify with SCIP), parameters reserved for future versions (should be commented // reserved, otherwise flag).

Tag: [CONFIG-UNUSED:{field_name}], [CONFIG-TEST-ONLY:{field_name}]

10. Fallback if primitives unavailable

• Find the opcode dispatch table (switch op in Go, match opcode in Rust)
• Read each arm
• Cross-reference against the spec (latest Yellow Paper section)
• Grep for SELFDESTRUCT, CREATE2, MCOPY individually

Cross-references

• Related: cross-environment-semantic-drift (L1/L2 semantic differences), consensus-safety-invariants (cross-client divergence is a consensus bug), rust-unsafe-audit (for Rust VMs)
• Consumed by: depth-state-trace, depth-external, depth-consensus-invariant
• Severity: docs/l1-mode/severity-matrix.md