EIP-8288 post-quantum proofs: EVM, RISC-V or a new ISA for Ethereum?

Victoria Shinder10 October 2026, 09:472 min read

An Ethereum Research post published on 8 October tackles a design question behind EIP-8288: when Ethereum lets transactions depend on post-quantum proofs verified outside the EVM, what exactly should a proof prove, and in which instruction set?

The setup. EIP-8288 lets a transaction depend on post-quantum signatures (leanSPHINCS) and STARK proofs (leanSTARK), listed as dependencies inside an EIP-8141 frame transaction. Nodes verify them before relaying, and one recursive STARK per block attests that every dependency in it is valid. The motivation is privacy pools: today a pool checks a Groth16 proof on-chain using the BN254 pairing precompile — and once a quantum machine can break BN254, such proofs can be faked. Under EIP-8288 the pool only checks that the transaction depends on a proof for its own program with the expected public inputs.

The problem. EIP-8288 currently identifies a proof's computation by a verification-key hash — a placeholder. That key would change with every update to leanVM, the zkVM producing leanSTARK proofs, breaking any pool that cannot be upgraded. The post proposes instead that proofs show a program ran correctly, identified as program_id = hash(ISA version, program bytes).

Three candidate ISAs, by the authors' comparison:

• EVM — could ship first, since Ethereum already maintains it, but runs through an interpreter: about 2× the cycles of RISC-V when a precompile does the heavy work, 78–163× when EVM code does (their privacy-pool benchmark with BLAKE2s).
• RISC-V (RV64IM per the Ethereum zkVM Standards) — native proving speed and the largest zkVM tooling, but Ethereum must first pin what the standard leaves open, such as the memory map.
• An Ethereum ISA for proving (eISA) — potentially cheapest to prove, but not yet designed and likely to need new versions as provers change.

Which fits depends on what leanVM ends up running natively; its repository explores RISC-V and its own six-instruction leanISA.

Keeping immutable contracts working. Because each program's identity includes its ISA version, a pool stores one program_id forever, and every later prover must keep each activated version provable — much as clients carry every fork's rules. The authors also discuss two alternatives credited to Vitalik and Alex: wrapping old proofs in new ones, and freezing one canonical ISA.

Why it matters. This is plumbing, but it decides whether privacy applications built now survive both a quantum break of today's curves and future changes to Ethereum's own proof system.

Source: Ethereum Research, "Exposing an ISA for post-quantum proofs on Ethereum", 8 October 2026 — https://ethresear.ch/t/exposing-an-isa-for-post-quantum-proofs-on-ethereum/26136