RFC 0004: expand cross-engine state to decision-ready proposal

[proofmancer]

Third RFC expansion in the series (after #70 RFC 0001 and #72 RFC 0002). Same shape: take an open-design RFC with N candidates and M open questions, commit to specifics, reduce both.

This one closes the "one state root across WASM and EVM" claim that's been deferred since v0.3 shipped.

What changed

Picks option (b)

The original RFC laid out 4 design candidates with no recommendation. This revision commits to option (b): unified KV addressed by (engine, identity, key) triples. The case against (a), (c), (d) is in the body. Short version:

• (a) two-namespaces ducks the cross-engine read question
• (c) EVM-shaped breaks the simple WASM slot model
• (d) WASM-shaped breaks EVM compatibility
• (b) lets each engine speak its native surface; runtime translates both to the shared substrate

Concrete byte-level encoding

        1 byte    20 bytes              variable
       +-------+ +-------------------+ +-------------------+
key =  | engine| |   identity        | |  engine-specific  |
       +-------+ +-------------------+ +-------------------+

WASM identity = synthetic 20-byte address = keccak256(chain_id || module_name || version)[0..20]
EVM identity = deployed contract address (standard)

Cross-engine reads, no cross-engine writes (v0)

• WASM->EVM: extern host fn evm_storage_read(addr, key) -> [u8; 32] (gated on RFC 0002)
• EVM->WASM: reserved precompile address with readU64(module, slot) signature
• Writes across engines: deferred to a future RFC (atomicity guarantees not in v0)

Performance: <5-10% slowdown target

Back-of-envelope: prefix encoding adds ~10ns to the ~120ns state_get hot path = ~8%. With per-instance prefix caching, drops well under 1ns. Real numbers from the implementation issue (#50).

4-phase implementation roadmap

• Phase A: Shared KV backend + prefix encoding (~200 LoC)
• Phase B: Wire WASM engine to shared backend (~150 LoC)
• Phase C: Wire REVM engine via Database trait (~200 LoC)
• Phase D: Cross-engine read host fn + precompile (~300 LoC)

Total ~850 LoC. Smallest of the runtime-side RFC implementations.

Open questions reduced 6 -> 1

Question	Resolution
Pick a candidate	decided: option (b) unified KV
Synthetic addresses	decided: keccak256 of structured inputs
Cross-engine semantics	decided: reads only via host fn / precompile
State proofs	decided: unified, single Merkle root
Migration	decided: not applicable (no production chains)
Performance	OPEN: validate <10% target with real bench in #50

Why now

RFC 0001 and 0002 are now decision-ready (PRs #70 and #72). Continuing the expansion push leaves 0003 (project metadata) and 0005 (third-party protocols) — neither of which blocks any open implementation issue. RFC 0004, by contrast, is the pre-condition to #50 (the cross-engine state sharing implementation), which is the next sensible runtime-side ship.

The implementation will move significantly faster against a decision-ready RFC. The week we want to start #50 is the week this RFC needs to be at this level of detail.

What this PR does NOT do

• Not a decision. Stays in `draft`. Decision criteria are explicit: maintainer sign-off, performance sanity check via bench, one independent review.
• Not implementation. Issue Runtime: cross-engine state sharing implementation (one state root across WASM + EVM) #50 tracks the code; this RFC defines the contract.
• Not the byte-level wire spec. A full `spec/abi/state.md` sub-doc lands with Phase A implementation; the RFC commits to the framework, not the bit layout.
• No migration story. v0.3 chains aren't in production; v0.4 ships with this directly.

What unblocks next

After 0004 is accepted, #50 implementation can start with clear specs. The four phases map directly to four small PRs.

The remaining unexpanded RFCs (0003 project metadata, 0005 third-party protocols) are lower priority — neither blocks a tracked implementation issue. The position paper #67 gains another concrete RFC to cite.