The 37x Problem: EIP-8288, RISC-V Canonicality, and the Post-Quantum Gas Bill Ethereum Has Not Priced

A standard Ethereum transaction carries a cryptographic signature that is exactly 65 bytes long. Sixty-five. That is the entire trust anchor for a transfer of any size — from a $0.40 USDC dust sweep to a $400 million institutional settlement. Inside those 65 bytes live an R value, an S value, and a recovery byte that together assert ownership of a secp256k1 private key over a 256-bit elliptic curve which has now survived fifteen years of adversarial attention without a public break. Last week I sat in a Telegram thread where someone had pasted a claim: Vitalik Buterin is pushing a proposal, EIP-8288, that would reduce the cost of "quantum-safe privacy" by making RISC-V the canonical instruction set of Ethereum, and the team hopes it lands in an upgrade called I-star, which follows something called Hegota. I read it three times. Then I did what I always do, which is open four browser tabs and start checking. Here is the honest result, stated up front because a claim without a confidence interval is not analysis: I could not verify EIP-8288 in the ethereum/EIPs repository. I could not map "I-star" or "Hegota" onto any upgrade sequence I recognize, and I have been tracking All Core Devs calls since before the Merge was called the Merge. The 65-byte-to-2,420-byte arithmetic below is real, checkable, and entirely independent of that uncertainty. The naming is not. So treat what follows as a direction-of-travel analysis, not a fact pattern. That distinction matters more than usual in a bull market, where a headline can be priced in ninety seconds and a correction takes nine days to propagate. To understand what "RISC-V as canonical instruction set" would actually change, you have to understand what the EVM currently guarantees and where those guarantees are physically implemented. The EVM is a stack machine with a 256-bit word size, a 1,024-item stack depth limit, separate volatile memory that is byte-addressable with quadratic gas cost, and persistent storage that is a 256-bit key-value map charging 20,000 gas for a cold SSTORE from zero. Every arithmetic opcode operates modulo 2^256. Every hash is Keccak-256, exposed through the SHA3 opcode at 30 gas plus 6 gas per word. This design was not arbitrary — 256 bits was chosen so that Keccak-256 output and secp256k1 scalars fit into a single word without alignment gymnastics. Cryptographic operations that are too expensive to express in bytecode get promoted to precompiles: native functions at fixed addresses, priced by governance fiat rather than by measured work. Address 0x01 is ECRECOVER at 3,000 gas. Address 0x02 is SHA-256 at 60 plus 12 per word. Address 0x03 is RIPEMD-160. Address 0x04 is the identity function. Address 0x05 is MODEXP. Later, 0x06 through 0x09 added the BN254 pairing operations for zk-SNARK verification, and 0x0a added KZG point evaluation for proto-danksharding. That list of precompiles is not a technical footnote. It is the actual constitution of the EVM. The instruction set is open and general; the precompiles are where a fixed set of assumptions gets privileged with a hundredfold gas discount. You can implement secp256k1 recovery in Solidity. Nobody does, because it would cost millions of gas instead of 3,000. This is the structure any credible post-quantum proposal has to attack. Now the cryptographic side. Current Ethereum signature verification rests on the discrete logarithm problem over secp256k1. Shor's algorithm solves that problem in polynomial time given a sufficiently large fault-tolerant quantum computer. The exposure is total and it is retrospective: every public key ever revealed on-chain is a candidate for retrospective key recovery. The usual "harvest now, decrypt later" threat model assumes an adversary records ciphertext today and decrypts when hardware arrives. On a public blockchain, the data is already recorded. There is no harvest step. There is only the decryption step, and a clock. The NIST post-quantum standards finalized in 2024 give three families worth caring about. ML-DSA (FIPS 204, lattice-based, derived from Dilithium) produces a 2,420-byte signature at the ML-DSA-44 parameter set, with a 1,312-byte public key. SLH-DSA (FIPS 205, hash-based, derived from SPHINCS+) produces a 7,856-byte signature at SLH-DSA-SHA2-128s, with a 32-byte public key. FN-DSA (Falcon, lattice, NTRU-based) produces a 666-byte signature at Falcon-512, with an 897-byte public key. Compare against secp256k1: 65-byte signature, 33-byte compressed public key, 20-byte address. Anyone who has ever priced calldata will feel a cold hand on the back of the neck here. Calldata has cost 16 gas per non-zero byte and 4 gas per zero byte since EIP-2028 in 2018. A transaction that currently spends 1,040 gas on signature bytes would spend 38,720 gas on an ML-DSA-44 signature — a 37x multiplier on the cheapest part of the pipeline, before anyone has verified anything at all. That arithmetic is the entire premise of the proposal. The bottleneck for post-quantum Ethereum is not cryptography. It is economics. On the roadmap side I need to be careful. Ethereum's published direction over the last two years has been organized around a set of named themes — the Merge, the Surge, the Scourge, the Verge, the Purge, the Splurge. The Verge is the one that matters here: the ZK-everything track, the one that commits to replacing or wrapping the EVM with something that can be proven efficiently rather than executed redundantly by every node. "I-star" and "Hegota" do not appear anywhere in that vocabulary that I can locate. Hegota reads phonetically like a portmanteau, or a mis-transliteration of something else entirely. I-star reads like a placeholder that never got replaced. My working hypothesis — confidence low — is that this is either an internal codename that leaked, a secondhand retelling of a proposal whose name changed during discussion, or a composite assembled from several different conversations. I flag it because in this domain the naming is the metadata, and metadata is where you detect whether a source is primary. One more piece of context matters. The EIP process is not a rubber stamp. A proposal enters as a draft, gets discussed on Ethereum Magicians and in the EIP editors' repository, gets argued about in All Core Devs calls, and only then may be scheduled for a network upgrade — where it needs implementation in at least two independent clients, currently Geth, Nethermind, Besu, Erigon, and Reth, plus broad ecosystem readiness. Proposals have been killed at every stage of that pipeline. So the correct read on "hopes to include in the next upgrade" is: early, contingent, low-probability but high-impact. Vitalik's support is influential and neither necessary nor sufficient. Ethereum has rejected his preferences repeatedly, and the network has generally been better for it. The phrase "canonical instruction set" is doing an enormous amount of work inside a single sentence, and I want to decompose it, because the three plausible readings have wildly different costs and almost nobody reporting on this distinguishes them. The most radical reading is that RISC-V becomes the execution layer and the EVM becomes a compiled target. The canonical state transition function is defined over RISC-V instructions. Solidity compiles to Yul, Yul compiles to RISC-V through a new backend, syscalls replace opcodes, and the EVM's 256-bit semantics get emulated on a register machine with 32- and 64-bit registers. This reading has the worst backward-compatibility story imaginable. Every gas schedule in existence, every tool that measures gas, every formal specification of EVM semantics — the Yellow Paper, KEVM, the execution-specs reference implementation — would need re-derivation. The least disruptive reading is that RISC-V becomes the proving target rather than the execution target. Nodes keep executing EVM semantics exactly as they do today, but the canonical proof of correct execution is expressed as a RISC-V trace, because RISC-V is what general-purpose zkVM projects prove natively. Under this reading nothing changes for Solidity developers or for gas; the change is in what a light client or a rollup has to verify. The third reading is a hybrid: RISC-V for new and expensive cryptographic primitives, exposed through a precompile-like interface. Post-quantum verification, and perhaps a handful of other ZK-adjacent operations, get implemented as RISC-V programs whose proofs are verified on-chain. This is the reading that most directly serves the stated goal of reducing the cost of quantum-safe privacy, and it is the reading that requires the least consensus. The hybrid is boring, and boring is how protocol changes actually ship. The radical reading is what generates headlines. Now the zkVM argument, because I believe it is the actual engine of this proposal and it is badly underreported. Every general-purpose zkVM I have spent meaningful time with over the last three years uses RISC-V as its guest instruction set. RISC Zero, SP1, Jolt, Pico, OpenVM — different proof systems underneath, different recursion strategies, different hardware acceleration paths, but the same guest ISA. There is a reason. RISC-V is open, has a clean formal specification, has a small instruction count relative to x86, and does not require licensing from anyone. If you are building a prover, you want a guest ISA you can specify exhaustively, compile to from many source languages, and that no single company can revoke. The EVM is a terrible guest ISA by comparison. Consider what a prover has to do to prove EVM execution. The field mismatch alone is brutal. The EVM is defined modulo 2^256. Modern proof systems work over prime fields — 2^31 - 1 in some systems, a 254-bit prime like the BN254 scalar field in others, or a 64-bit field in newer STARK designs. Every 256-bit modular operation in the EVM must be decomposed into limbs over the proof field. A single MULMOD becomes a multi-limb arithmetic circuit with carry propagation. The instruction is cheap on the host and expensive in the circuit, which is precisely inverted from the intuition a Solidity developer carries around. Keccak-256 compounds the problem. The EVM's hash function was designed for hardware efficiency, not circuit efficiency, and its mixing layer uses bit rotations that are free in silicon and expensive in an arithmetical circuit. Because Keccak is called on almost every nontrivial operation — every storage read for a mapping, every log topic, every contract creation address — the hash dominates proving cost. Estimates I have seen from zkEVM teams put Keccak somewhere between 30% and 60% of total proving time depending on workload. Confidence medium on the range, high on the ranking: Keccak is the single largest cost center. And then there is the stack machine. The EVM's architectural model is a 1,024-deep stack with no random access and no registers. A register machine maps to a proving-friendly AIR or R1CS layout far more naturally than a stack machine, because register access patterns are local. When you prove a stack machine, the memory consistency argument — proving that the value popped at step N is the value pushed at step M — becomes a global constraint problem, and global constraints are where lookup arguments and permutation checks get expensive. Viewed from this angle, the RISC-V proposal is not fundamentally about quantum computers. It is about the fact that the most credible path to ZK-verifying Ethereum's own execution runs through a guest ISA Ethereum does not currently use, and every year the EVM stays non-RISC-V is another year of accumulated translation overhead. That is the hidden motive — confidence medium — and it is the piece of the story I would most want a primary source to confirm. Now let me put numbers on the post-quantum side, because this is where the cost thesis either holds or collapses. Verification cost, not just calldata cost, is the real problem. ECRECOVER costs 3,000 gas because it is implemented natively in every client. If you implement post-quantum signature verification in EVM bytecode instead — as an ordinary smart contract, with no precompile — you are paying for the arithmetic in gas. Public benchmarks from teams who have attempted this land in uncomfortable territory. A Keccak-based SLH-DSA verifier written in pure EVM bytecode has been measured in the range of several hundred thousand to a few million gas depending on parameter set and optimization effort; verification is hash-dominated and the EVM prices Keccak at 30 plus 6 per word, which is a discount relative to true circuit cost but not a large one at this volume. An ML-DSA verifier in EVM bytecode is worse, because NTT-based polynomial arithmetic in a stack machine is punishing. Published experiments have landed in the multi-million gas range. Set that against 3,000 gas for ECRECOVER and the shape of the problem becomes visible. A post-quantum Ethereum without new precompiles is not a more expensive Ethereum. It is a non-viable Ethereum, because a single signature check would exceed the gas cost of most useful user operations. Let me do the full accounting for one transaction, because the aggregate number is what people will actually feel. Assume an ML-DSA-44 signature at 2,420 bytes and a public key at 1,312 bytes. Assume the account abstraction path where key material and signature arrive in calldata rather than being recovered from the transaction envelope. Calldata cost is (2,420 + 1,312) × 16, which equals 59,712 gas. Verification via an optimistic precompile priced at roughly five times the circuit cost of a pairing check — the BN254 pairing precompile charges 45,000 plus 34,000 per pair — comes to roughly 150,000 gas, which is generous. Total: approximately 210,000 gas per signature-bearing transaction. Current cost for the same transaction: 65 × 16, which is 1,040 gas of calldata, plus 3,000 for ECRECOVER, which is 4,040 gas. That is a 52x increase in the fixed cost of using Ethereum. At a 30 million gas block, the number of simple transfers per block drops by more than an order of magnitude. At current fee levels this is survivable. Under congestion it becomes a fee market where the marginal user is priced out permanently. The mitigations are all partial. Signature aggregation does not work for lattice schemes the way it works for BLS: you can batch verification, but you cannot compress many ML-DSA signatures into one constant-size object, because lattice signatures are large precisely because the security reduction demands the entropy. Hash-based schemes are even less aggregable. This is a structural property rather than an engineering gap, and it is the same reason rollup compression gets harder as you move away from ECDSA. Blob-based data availability helps the calldata term. Post-EIP-4844, blob space is priced by a separate market. But blobs are not readable from inside the EVM, only their commitments are, so using a blob to carry signature material requires a proof-of-opening construction. You have converted a calldata problem into a KZG problem. Someone will build it. It will be clever and it will be slower than calldata. Threshold and MPC schemes reduce how often you verify on-chain, but they move the trust into a signing committee, and a committee is a set of entities with legal identities. Liquidity is just trust with a price tag, and this particular price tag is denominated in validator collusion risk rather than dollars. In 2024 I audited an MPC threshold signing setup for an Indian exchange preparing for institutional custody flow, and the finding that mattered was not in the threshold parameter or the curve. It was a side-channel leakage risk in the key generation ceremony. The math was clean. The ceremony was not. Every threshold scheme inherits that asymmetry: the cryptography is provable, the operational envelope is not. There is one more consequence of the migration that almost nobody discusses, and it is larger than it first appears. Ethereum addresses are derived from public keys. An externally owned account's address is the last 20 bytes of the Keccak-256 hash of its secp256k1 public key. Inside contracts, a much larger surface depends on this. EIP-2612 permit, the gasless approval standard, is built on ecrecover. Every implementation of it in existence hardcodes a call to the precompile at 0x01. So does every meta-transaction relayer, every signature-based order book, every off-chain order with on-chain settlement, every multisig, every session key scheme. Under a post-quantum signature scheme, the address derivation function changes, the recovery mechanism changes, and the precompile returns nothing usable. That means every one of those contracts needs a new verification path, deployed and audited, and every integration that assumed a 65-byte signature needs to reason about a 2,420-byte one. This is not a client upgrade. It is a coordinated migration of the application layer, on a network where the application layer holds hundreds of billions of dollars in value and cannot be paused. RISC-V canonicality, in any of its three readings, is also a change to the substrate beneath Solidity. Solidity survives — it is a compiler, and compilers can target new backends. But an enormous amount of Ethereum's practical security depends on artifacts defined in EVM terms. Gas estimation is the first casualty. Every wallet, every dapp, every block builder estimates gas by simulating EVM execution against a gas schedule. Rebasing execution onto RISC-V cycles means either keeping a gas model that is now an abstraction over something else, or re-deriving metering from instruction counts. The second option breaks compatibility for every tool in existence. The first option means the gas you pay is no longer a measurement of work, which weakens the denial-of-service argument that justifies the gas schedule in the first place. Formal verification is the second. The EVM has accrued a decade of formal specification: the Yellow Paper, the K framework semantics used by KEVM, the execution-specs Python reference, plus the tooling built on them — Halmos, hevm, the Kontrol KEVM backend, Certora's CVL. All of it is expressed over EVM opcodes. A RISC-V canonical layer means either a refinement proof connecting the two layers, which is hard and valuable and rarely attempted at this scale, or a gap that nobody has measured. Audit practice is the third. Every auditor working today reasons about reentrancy, storage layout, delegatecall semantics, and gas griefing in EVM primitives. In 2020 I spent three weeks reverse-engineering the internal accounting modules of an early perpetuals protocol, ignoring the market entirely, and the reentrancy vector I found lived in the interaction between a flash loan callback and a storage write ordering that only makes sense inside the EVM's execution model. That class of bug is EVM-specific. Under a different execution model the bug class changes, and the people who can find it are the people fluent in both models, which for a while will be almost nobody. I cannot quantify the toolchain tax honestly, and I will not pretend otherwise. The number of engineering hours required to re-target Ethereum's tooling onto a RISC-V execution model is not estimable from public information, and anyone who hands you a number is guessing. What I can say with medium confidence is that the transition cost is a multi-year, multi-thousand-engineer effort, and that this ecosystem has historically underestimated such efforts by a wide margin. The Merge was specified for years and shipped late. Danksharding has been re-scoped repeatedly. This would be larger than both. Here is the uncomfortable symmetry nobody states plainly. The case for post-quantum migration is that Ethereum's current cryptography has a finite shelf life, and that when quantum hardware arrives the exposure is total and retrospective. That is correct. I do not dispute it. ECDSA over secp256k1 is broken by Shor's algorithm in polynomial time; every public key that has ever appeared in a transaction is already recorded and already harvestable. But note what the migration actually does. It takes an assumption set that has been attacked continuously for fifteen years by every cryptanalyst with an incentive — secp256k1, Keccak-256, the EVM's arithmetic — and replaces it with a set attacked for three years under standards finalized in 2024. That is not a criticism of the NIST process, which was long and careful. It is an observation about the shape of risk. You are trading a slow-burn risk for a fast-burn risk, and the slow-burn risk has a timeline measured in decades while the fast-burn risk goes live the day the code ships. There is a precedent I keep returning to. In 2017, working through an early Gnosis Safe iteration while my peers were chasing presales, I found an integer overflow in the initialization function. It was not a cryptographic break. It was an ordering bug. The signature checks were fine. The arithmetic was fine. The vulnerability lived in the sequence of state transitions, and it was exploitable because the contract's invariants assumed a state that the code did not enforce. Audit reports are promises, not guarantees. Every protocol ever drained had a report. The report said what the auditor checked, and the exploit lived outside that boundary. The boundary in question here is the EVM-to-RISC-V translation layer, and that is where I would bet the first real loss occurs. Not in the RISC-V specification. Not in the lattice signature scheme. In the seam between the two semantics. Consider the surface. EVM arithmetic is modulo 2^256 up to 256-bit inputs. RISC-V is a 32- and 64-bit register machine. Emulating 256-bit modular arithmetic on 64-bit registers requires multi-word sequences with carry handling, and each sequence is a place where an off-by-one in the carry chain, a missing sign extension in a shift, or a divergence in the treatment of division by zero produces a result different from the specification. The EVM defines division by zero as zero and modulo by zero as zero. The underlying RISC-V DIV and REM instructions do not. Someone will have to specify and test every one of those divergences, and the tests will be written by people, and people miss cases. Fuzzers find the rest. There is a governance dimension too. Any proposal at this scale concentrates decision-making, because you cannot migrate an execution layer by committee of millions. It moves through the EIP editors, the All Core Devs calls, a handful of client teams, and the researchers who wrote the specification. That is a narrow set of people holding effective veto power over the most consequential change in the network's history. I have watched the same pattern in a smaller arena. The standard defense of a decentralized oracle network is that it is operated by twenty independent node operators. The standard reality is that the hardware, the software, the update mechanism, and the multisig that pushes a new version are controlled by a much smaller group. Twenty signatures from twenty entities sharing one deployment pipeline is not decentralization; it is a quorum. RISC-V canonicality would be defended in exactly the same register — an open standard, adopted by an open process, implemented by independent clients — and the honest accounting is that the people who can actually change it number in the low dozens. I am not arguing that this is wrong. I am arguing that it should be priced. In a bull market it is not priced anywhere, because the pricing is denominated in coordination risk and coordination risk has no ticker. The final contrarian point is the least comfortable one. The most probable explanation for a proposal bearing an unfamiliar name, an unfamiliar upgrade sequence, and no traceable source is that something in the retelling is wrong. Before anyone builds a thesis on EIP-8288, someone should confirm that EIP-8288 exists. That is not skepticism for its own sake. It is the same discipline that separates an audit from a marketing page. Strip the naming uncertainty away and the direction remains legible, because the direction is forced by arithmetic rather than by preference. Post-quantum signatures are ten to one hundred twenty times larger than the ones Ethereum uses today. The EVM prices bytes and opcodes in a way that makes those signatures economically unusable without protocol-level accommodation. RISC-V is the guest ISA the proving industry already standardized on. Those three facts, laid end to end, produce something very much like the proposal described, whoever named it and whatever upgrade it eventually ships inside. So my forecast, stated as a forecast. The first material exploit attributable to this direction will not be in a post-quantum primitive. It will be a semantic divergence bug in the execution translation layer — a carry-handling edge case, a zero-division mismatch, or a gas metering discrepancy that lets a caller do more work than they paid for. Confidence medium. The reasoning is structural rather than anecdotal: cryptographic primitives get broken by cryptanalysts over years, and translation layers get broken by fuzzers in weeks. The second thing I would watch is the gas schedule itself. Any proposal that rebases execution cost onto a new instruction set is quietly also a proposal about who wins block space. That is a redistributive question wearing technical clothing, and it will produce the loudest disagreement of the entire process — later, once everyone has already agreed on the easy parts and the hard parts are frozen. Yield is a function of risk, not just time. If you hold ETH through this transition, you hold a claim on the successful execution of the most complex coordinated change in the network's history, and you are being paid in the interim by issuance and fee burn, which is to say, by nothing that prices that transition risk at all. That is not an argument to sell. It is an argument to read the EIP before you read the headline, and to check the repository before you check the price. The repository, in this case, is the first thing I would check. Everything else follows from whether it is there.