Vitalik's cheap post-quantum signatures come with a canonical ISA attached
EIP-8288 prices a hash-based signature at 3,000 gas against 150,000 today, and buries the decision to give Ethereum an instruction set in the last paragraph.
Vitalik Buterin published a note on September 9 arguing that EIP-8288 belongs in I-Star, the Ethereum fork after Hegota. The proposal sets verification of a hash-based post-quantum signature at 3,000 gas. Today the same job costs 150,000 to 200,000 gas by the EIP's own accounting, and a quantum-safe private transaction runs to roughly 10 million.
Call it a factor of fifty on signatures and roughly three hundred on private transactions. But the saving does not come from better cryptography.
It comes from moving the cryptography out of the block.
Here is the shape of it. Your transaction carries a "dependency frame", which is a list of claims rather than data — message hash M was signed by SPHINCS+ key P, data hash D satisfies the statement behind verification key V. Your signature itself travels in an envelope to the mempool and stops there. Mempool nodes tick, batch every envelope they have seen, and produce one recursive STARK proving all of the claims at once (the builder is treated as just another mempool node). What lands on chain is a single proof plus 96 bytes per claim.
A note on recursive STARK mempools (EIP-8288) t.co/XNBuNtkKmi
This is an EIP that I am hoping we can get included in I-star (the fork after Hegota) that you can think of as the next step after Frames, that would unlock extreme amounts of power. Particularly:
* Ultra-cheap quantum-safe signatures (SPHINCS-). Much of the cost savings comes from the fact that the signature data (~3 kB) does not have to go onchain
* Ultra-cheap quantum-safe privacy protocols. Status quo minimum cost for private txs is ~300k if you engineer very well (no one does), status quo quantum-safe is ~10M gas, this could reduce it to low tens of thousands.
* Universal support for your favorite new signature or proof scheme without needing EVM changes. Whatever you use (Falcon, ML-DSA, some other lattice-based thing, something code-based or isogeny-based or even more esoteric), you can just wrap it client-side in a STARK, onchain gas cost low tens of thousands just like privacy protocols. Hopefully, Ethereum will never need "please support my favorite cryptographic algo" politics again.
* Private account abstraction: keep your account logic private, and in a private location onchain. Then you can make one transaction to change the ownership of all your onchain state - accounts, defi positions, privacy protocol notes, everything - without revealing which objects' ownership you're changing.
Here's how it works.
Your transaction can include a type of frame that we call a "dependency frame". The frame is a list of statements, asserting claims like "message hash M was signed by SPHINCS- public key P" and "data hash D was proven to satisfy a statement defined by verification key V".
When you send your transaction, you send it in an envelope, which includes a signature or a STARK for each statement in a dependency frame.
Once the transaction reaches the mempool, nodes aggregate them. Each node runs a loop: wait one tick (eg. 500ms), aggregate all new envelopes (either single-tx or multi-tx) that you've seen, remove any transactions that are expired, generate a STARK recursively proving all dependencies, and send a new multi-tx envelope containing that STARK.
Hence, the bandwidth load is bounded: each node's outbound is one STARK (~100-300 kB) per tick, plus each transaction getting broadcasted through the network once (as happens already).
The block builder acts as "yet another mempool node", receiving envelopes from the mempool (plus any side channels), generates its own STARK covering the subset of transactions it intends to include in the block, and adds that STARK to the block.
Total onchain overhead: one STARK (100-300 kB), plus 96 bytes for each statement being proven.
This is what I've called before ( t.co/3jfVkYTZrR ) "The Proof Singularity". Today, we have all the ingredients to actually implement it.
As a developer, this requires a somewhat different workflow than you are used to, but it is conceptually simple. Any signatures or STARKs, you put into a separate frame. Then the main logic that today is verifying a signature or STARK, you replace with checking for the existence of a frame that includes the correct statement as a dependency.
Examples of useful statements:
* [tx sighash] verifies against [the pubkey at sload(0)]
* there exists a secret and a merkle branch such that hashing secret+0 and applying the merkle branch outputs (public) root R, and hashing secret+1 outputs (public) nullifier N
* there exists a secret address A, salt S and signature Z such that sload(0) = hash(A, S) and a merkle proof of address A inside a recent ethereum state contains some pubkey D where [tx sighash] was signed by D [this is private account abstraction; all variables except [tx sighash] and sload(0) are private; you can also make D a STARK verification key]
* there exists an ML-DSA signature signing [tx sighash], that verifies against an ML-DSA pubkey whose hash is sload(0)
At the core, this is moving any compute and data other than bookkeeping "business logic" outside the core path of Ethereum execution, sharding and parallelizing it via the mempool.
Notice also that this requires agreeing on a _language_ (aka. an ISA) for the recursive STARKs to define statements in. The current leading candidate is RISC-V. So this would also de-facto be Ethereum adding RISC-V (or something else we decide on) as a canonical ISA - a big decision that should be done carefully, but that I think will be necessary to drive Ethereum forward.
So the ~3 kB SPHINCS+ signature never touches the chain. Neither does the 128 kB to 512 kB STARK a privacy protocol would otherwise post.
Ethereum stops paying per signature and starts paying per block.
Which raises the question nobody asked on the timeline. If you are not paying per signature, what does the block pay?
Buterin's answer is one STARK of 100 to 300 kB, every block, plus the 96-byte triples. A fixed cost has a break-even, so we worked it out. At roughly 3 kB per hash-based signature, a 100 kB block proof only pays for itself above about 33 post-quantum statements per block, and a 300 kB proof needs about 100. Below that line the aggregate proof is probably more data than the signatures it replaced. We would like to see that curve drawn before I-Star scoping, because on a quiet block it points the wrong way.
A small thing we enjoyed. The note says nodes "wait one tick (eg. 500ms)" before aggregating. The EIP's constant table sets AGGREGATION_INTERVAL to 1000 milliseconds. One of those is going to change, and the gap between a man's tweet and his own specification (three months old, still Draft) is usually where the argument still is.
Coverage got the verb wrong, too. Wu Blockchain reported this as Buterin proposing the design. He and Thomas Coratger filed EIP-8288 on June 3. What happened on September 9 was lobbying, and lobbying for a specific fork is a different act with a different audience.
Now the part that matters more than the gas numbers.
Recursive aggregation needs every prover to agree on a language for expressing statements. Buterin says so in the last paragraph, names RISC-V as the leading candidate, and calls it "a big decision that should be done carefully, but that I think will be necessary to drive Ethereum forward." Read plainly, the pitch for cheap quantum-safe signatures is also the pitch for giving Ethereum a canonical instruction set that is not the EVM. If you have been waiting for the RISC-V argument to arrive, it arrived inside a gas-savings post.
Our read is that the ISA is the real content of the I-Star fight, and that post-quantum urgency is probably the vehicle carrying it. The Ethereum Foundation has set a December 2029 deadline for quantum-resistant transactions, validators and storage, which gives anyone arguing for a large architectural change a clock to point at. We would expect the ISA question, not the aggregation scheme, to consume most of the I-Star discussion by the end of this year, and we would expect EIP-8288 to stay out of Hegota entirely. If the magicians thread stays on gas accounting and never gets to RISC-V, we are wrong about what this is.
One more thing for whoever has to build on it. Buterin is explicit that the developer workflow changes. Signatures and proofs move into their own frame, and your contract stops verifying and starts checking that a dependency exists. Small edit in a sentence. Large edit in every wallet, paymaster and privacy pool that already ships.
EIP-8288 is still marked Draft. Hegota comes first.
Sources
Show all 11 sources
LAPTOP peaked at $190.81 two minutes after launch, on $48,000 of liquidity. The design did the rest
Hunter Biden's memecoin printed a $144 billion valuation against a pool smaller than a house deposit, then lost 99 percent inside an hour. He says nobody on his side sold. The tokenomics say nobody on his side could.
Continue ↓