Vitalik Wants One STARK to Rule Ethereum's Crypto

EIP-8288 would collapse Ethereum's precompile pile into a single recursive proof — if the Ethereum Foundation agrees.

By The crypto-money Desk

[1]

The case against precompiles is mechanical. Each new one demands a hard fork, an implementation in every client, and onchain calldata — a pipeline Buterin estimates tops out at around 8 MB/s even with PeerDAS included. Under EIP-8288, mempool nodes would recursively fold user-generated proofs together until each block carries just one, meaning, as Buterin wrote, "Ethereum can then never add a new precompile again." [1]

[2] a16z argued the recursive proving that Ethereum's hash-based plans rely on is "intricate and bug-prone," while StarkWare's Eli Ben-Sasson countered that lattices are "ripe for AI to attack." [1]

EIP-8288 would sidestep the lattice-versus-hashes fight by letting any scheme — lattice or otherwise — wrap itself in a STARK client-side. But the proposal remains a draft, its leanSTARK route still marked "reserved," and the Ethereum Foundation's own roadmap keeps post-quantum signature precompiles on the docket for a future fork called J*. [1]

The gap between a co-founder's architectural vision and the foundation's published roadmap is not new — but the post-quantum deadline is narrowing, and the cost of the wrong choice compounds with every validator added to the set.

Until EIP-8288 moves from draft to spec, Ethereum's cryptography strategy remains two things at once: a clean long-term thesis and a precompile list that keeps growing. [1]

Ethereum can then never add a new precompile again.Vitalik Buterin