EIP-8288 and the Ten-Million-Gas Signature
A Falcon-512 signature occupies 666 bytes. An ML-DSA-44 signature occupies 2,420 bytes. An ECDSA signature over secp256k1 occupies 65 bytes, and verifying it inside the EVM costs a flat 3,000 gas through a precompile the network has optimized for over a decade. Verify a lattice-based post-quantum signature inside the EVM today โ no precompile, no native number-theoretic transform, no big-integer acceleration โ and the meter runs to roughly ten million gas.
Ten million gas is not a transaction. It is close to a third of a mainnet block at current limits. A single post-quantum authorization, priced honestly by the current execution model, costs more than three hundred ordinary transfers combined. That ratio is not a tuning problem. It is a structural statement about where signature verification currently lives in the Ethereum stack โ squarely inside the critical execution path, executed byte by byte by an interpreter that was never designed for modular arithmetic over a 23-bit prime field.
On September 9, Vitalik Buterin published EIP-8288, and the interesting thing about the proposal is that it does not try to make that number smaller. It tries to make the number irrelevant. Recursive STARK aggregation happens in the mempool, not in the block. Signatures and proofs leave the execution path. What remains on-chain is a single aggregated proof and a statement that a batch of transactions was authorized.
Tracing the assembly logic through the noise, the headline is gas. The mechanism is a migration of authentication from the execution layer to the proving layer, and that migration has consequences the gas figure does not describe.
What the Proposal Actually Moves
The architecture described in EIP-8288 is a three-part pipeline. Nodes periodically aggregate transaction dependency relationships in the mempool. Block builders generate recursive STARK proofs over those aggregates. The resulting proof is verified once, and the execution layer processes state transitions that carry a 96-byte statement each โ an attestation, not a signature.
The design is explicitly modular. It does not require modifying the EVM. It is intended to be compatible with new signature families, specifically Falcon and ML-DSA, without forcing a consensus change to the precompile set. It supports private account abstraction, meaning accounts whose authorization relationship is not publicly linkable on-chain. Per the proposal, quantum-safe privacy transactions would fall from roughly ten million gas to the tens of thousands. Block-level overhead is stated at 100 to 300 kilobytes of STARK data, plus 96 bytes per proven statement. Buterin has indicated he wants the EIP folded into the I-star upgrade, the roadmap slot that follows Hegota.
One secondary thread in the proposal deserves more attention than it has received: the possibility of establishing RISC-V as the standard instruction set for recursive STARKs on Ethereum. That is not a footnote. It is a decision about what the proving layer is allowed to assume, and it will outlive the gas discussion by years.
I have watched this pattern before. In 2020 I spent three months on a local testnet simulating arbitrage paths between Uniswap V2 and Synthetix, looking for reentrancy surfaces in the proxy contract when flash loans were layered on top. What I learned then is what I read in EIP-8288 now: the cost number is always the visible part of the design, and the trust surface is always the part that ships. The proposal is not an optimization. It is a reallocation of where the network spends its verification budget, and it changes what a block even is โ from a list of authorized state transitions to a list of authorized state transitions plus a proof that the list is authorized.
The Accounting
Start with where ten million gas comes from, because the number is contested and the composition matters for what aggregation can actually fix.
Falcon operates over the ring Z_q[x]/(x^n+1) with q = 12289 and n = 512 or 1024. ML-DSA uses a module lattice with modulus q = 8380417 and n = 256. Both verification paths are dominated by two operations: a number-theoretic transform to move between coefficient and evaluation domains, and a norm check. A single 512-point NTT requires on the order of n log n / 2 โ 2,300 butterfly operations. Each butterfly is a modular multiply, two modular additions, and a reduction. In a compiled implementation on a modern CPU, that is microseconds. Inside the EVM, each modular multiply is a MULMOD opcode at 8 gas, each addition an ADDMOD at 8 gas, each value loaded from memory at 3 gas, each stack manipulation at 3 gas. Multiply that by a factor of roughly four for the surrounding bytecode that has to manage the transform loop, the twiddle factor table, and the coefficient buffers.
The dominant cost is not the arithmetic itself. It is that the arithmetic is being interpreted. The EVM executes one opcode at a time, with no vectorization, no register file, no instruction-level parallelism. A native NTT is a tight loop over registers; an EVM NTT is a stack machine walking memory tens of thousands of times.
There is a second cost center that gets less attention. Falcon and ML-DSA both derive their challenge values from SHAKE256 โ a sponge construction, not a MerkleโDamgรฅrd hash. Keccak-f[1600] is 24 rounds over a 1,600-bit state. There is a SHA3 precompile, but SHAKE256 with the required output lengths and domain separation is not a single precompile call; in practice it is implemented in bytecode. My rough estimate for a bytecode Keccak-f permutation, accounting for loop overhead, memory copies, and the theta/rho/pi/chi/iota round functions, is in the range of tens of thousands of gas per permutation, and multiple permutations are needed per verification. That term alone can account for a meaningful fraction of the ten million.
Now the aggregation argument. Suppose a block contains N post-quantum transactions. Without aggregation, the signature verification cost scales linearly: N ร 10M gas. With recursion, the aggregate proof size is logarithmic in the number of statements, not linear โ that is the entire property recursive STARK composition is purchased for. The on-chain cost becomes a verifier cost, plus 100โ300 KB of calldata (at 16 gas per non-zero byte, roughly 4.9 million gas for 300 KB, and STARK proofs are high-entropy enough that almost every byte is non-zero), plus 96 bytes per statement at roughly 1,536 gas each.
The amortization is brutal in the right direction. The marginal on-chain cost per transaction drops from ten million gas to low single-digit thousands, and the ratio improves as the aggregate grows. The break-even against a direct verification is crossed almost immediately, which is why the "tens of thousands of gas" figure in the proposal is credible rather than promotional.
That is the part everyone will quote. The part that constrains the design is elsewhere.
Aggregation requires an ordered set of statements. A proof attests that a specific computation was executed in a specific sequence. A mempool is not a sequence. It is a directed acyclic graph of dependencies, where transactions that touch the same storage slot are partially ordered and transactions that do not are unordered. If you aggregate two transactions that both mutate the same slot, you must encode their relative order inside the proof โ which is possible, but it costs proving complexity and constrains the batch.
In a low-contention mempool, aggregation ratios are enormous and the amortization is close to theoretical. In a high-contention mempool โ a trending mint, a liquidation cascade, a congested arbitrage window โ most transactions in flight conflict with each other, and the aggregation graph fragments into small, nearly-linear chains. The efficiency of EIP-8288 is inversely proportional to how much anyone actually wants to use Ethereum at that moment. The proposal degrades exactly when demand is highest, and that is not a bug in the writing; it is a property of any system that batches by non-conflict.
There is a latency dimension as well. A proof must be produced before the block it authorizes. Aggregation takes time โ recursive STARK proving is compute-heavy, and the deep recursion needed for large batches multiplies the prover workload. A user who needs inclusion in the next block cannot wait for an aggregation round. The natural equilibrium is a two-tier mempool: aggregated transactions that are cheap and slow, and unaggregated transactions that are expensive and fast. That is a priority-fee market with a new axis, and the new axis is priced in proving latency rather than in gas.
And then the instruction set question. If RISC-V becomes the canonical target for recursive STARKs, the proving layer inherits a dependency on a specific ISA and its interpreters. Auditing the space between the blocks, that means the correctness of a RISC-V execution model becomes consensus-adjacent. Formal verification of RISC-V cores has been done, but at scopes far smaller than a production prover โ RV32I without caches, without speculation, without the full memory model. A production STARK prover is a large software artifact written in Rust or C, and its correctness is not established by the ISA choice alone.
The code does not lie, it only reveals. The question is whether anyone has read all of it.
What the Proof Does Not Cover
Three blind spots are worth naming directly.
Trust minimization is a soundness property, not a liveness property. A recursive STARK gives you a cryptographic guarantee that an aggregated batch was correctly authorized. It gives you nothing about which transactions entered the batch. Whoever selects the aggregation set determines which transactions become economically viable โ not by forging them, but by excluding them from the cheap path. That actor is a new gatekeeper, structurally analogous to a PBS relay, and it accumulates exactly the kind of power that proposer-builder separation was designed to distribute. The proposal does not describe the aggregator selection mechanism in terms of incentive compatibility. That is the gap I would flag first in a security review, and the one I would expect to be attacked first in production.
Mempool privacy is not chain privacy. Private account abstraction hides the link between an account and its authorization in the committed state. But aggregation happens in the mempool, on plaintext, before the proof exists. The aggregator sees the transactions. The chain does not. That distinction is real and it is often elided. A privacy guarantee that holds against every observer except the one entity that decides whether your transaction is cheap is a weaker guarantee than the phrase "trust-minimized privacy" suggests. Closing it requires an encrypted or threshold-decrypted mempool, and EIP-8288 as described does not include one. This is the same failure mode I documented when I tore apart ERC-721 metadata handling in 2021: the guarantee was defined at the level of the committed object, and the interesting information had already leaked upstream.
"No EVM modification" is purchased at the verifier. A STARK verifier expressed in EVM bytecode โ field arithmetic, Merkle path verification against the FRI commitment, the transcript โ is expensive. The cheap path is a precompile, and a precompile is an EVM modification with a permanent deprecation horizon. So the compatibility claim is true in a narrow sense and expensive in a broad one. If the ecosystem later adds a verifier precompile to make the economics work, it has created a consensus-critical surface that cannot easily be removed. The architecture of trust is fragile precisely because it is additive. You can add a precompile. You cannot subtract one.
There is a broader migration risk worth stating. Post-quantum signature schemes are young relative to ECDLP. Falcon's security rests on the NTRU lattice problem and requires discrete Gaussian sampling, which is notoriously difficult to implement in constant time โ the floating-point sampling routines have been the subject of side-channel literature for years. ML-DSA rests on Module-LWE and has a shorter deployment history than any scheme currently in Ethereum consensus. Committing either to the authorization layer is a multi-decade decision made with a handful of years of cryptanalysis. That is not an argument against doing it. It is an argument for treating the signature-scheme choice as the highest-stakes component of the proposal rather than as an implementation detail beneath the gas headline.
I ran a version of this analysis in 2022 on a different system, reverse-engineering the UST mint-and-burn loop to find the liquidity threshold that triggered the death spiral. The lesson that carried over is not about stablecoins. It is that systems fail at the boundary between two components that each assume the other is doing more work than it is. In EIP-8288, the boundary is the aggregator, sitting between a mempool that does not guarantee fairness and a prover that does not guarantee availability.
The Takeaway
Where logical entropy meets financial velocity, the gas number is the least informative part of EIP-8288. Ethereum is proposing to move authentication out of the execution layer and into the proving layer, permanently, and to do it in the same cycle in which it decides what instruction set the proving layer runs on. Those two decisions will be read together in retrospect, and the gas figure โ ten million down to tens of thousands โ will look like a consequence rather than a cause.
The signal to watch is not the EIP's adoption date. It is whether the proposal acquires a section on aggregator selection incentives and mempool confidentiality before it reaches a testnet. If it does not, the network will have optimized the cost of proving a batch while leaving open the question of who gets batched.
The signature is cheap now. Ask who is paying for the proof.