Trust minimized transaction simulation using state proofs

What it is

A concrete wallet-simulation architecture ("verified prestate simulation") proposed on ethresear.ch, built on three specific RPC calls — debug_traceCall with prestateTracer, eth_getBlockByNumber, and eth_getProof — combined with local execution in revm (Rust EVM).

How it works

flowchart TD
    A[debug_traceCall + prestateTracer] -->|discovers required accounts/storage| B[Query N independent RPC nodes]
    B --> C{All stateRoots match?}
    C -->|No| R[Reject simulation]
    C -->|Yes| D[eth_getProof for each account/storage slot]
    D --> E{All MPT proofs verify locally?}
    E -->|No| R
    E -->|Yes| F[Execute locally in revm with verified prestate]
    F --> G[Self-generated traces shown to user]

Account proofs verify against the global state root; storage proofs verify against each account's storageHash. Non-existent accounts are verified as not-yet-deployed and their state is left to revm execution. Any single proof failure or state-root disagreement causes the whole simulation to be rejected (optionally retried against different nodes).

Preconditions / Affected

Requires the target chain to support eth_getProof (described as "widely supported") and debug_traceCall with prestateTracer (described as "less common" — a practical deployment blocker on chains/providers that don't expose it). Works on Ethereum mainnet and most L2s; chains with non-standard state representations would need adapted proof-verification logic. Requires access to multiple independent RPC providers simultaneously, since the consensus step needs unanimous state-root agreement — one unreachable or disagreeing node fails the whole simulation (explicit availability-for-security trade-off).

Caveats

The authors state these as open, unresolved gaps, not solved problems:

• Prestate completeness is not verified, only correctness of what's provided. A malicious node could give accurate proofs for an incomplete prestate, hiding storage slots. The stated planned fix — checking post-execution that revm didn't access anything outside the verified prestate — is explicitly "future work," not implemented.
• Conditional/branching contract logic (e.g., behavior keyed on block.timestamp or msg.sender) can still make simulation show benign behavior while on-chain execution differs — acknowledged as unsolved and not specific to this approach.
• MEV reordering can change actual execution block position versus simulated order, also unaddressed.
• The unanimous-consensus design is explicitly posed by the authors as an open question (security-over-availability trade-off; no per-user configurability yet).