Vitalik Pushes EIP-8288 Over New Precompiles
Vitalik says EIP-8288, and not a growing pile of precompiles, should carry Ethereum's cryptography going forward.
Vitalik Buterin made the case Sunday night for Ethereum to quit baking new cryptography into the EVM through precompiles and lean on EIP-8288 instead, writing that precompiles and the EVM are “the wrong place to put most cryptography support into Ethereum.”
— (@)
Enjoying this article?
Subscribe to Bankless or sign in
What’s the Scoop?
The case against: Precompiles are built-in contracts that make specific cryptographic operations cheap, but every new one requires a hard fork plus an implementation in every client, and the data they check must still be posted onchain as calldata. Vitalik estimated that data budget tops out around 8 MB/s, PeerDAS included.
The alternative: EIP-8288, which Vitalik co-authored with Thomas Coratger and which we covered in September, would have users prove any signature or proof scheme locally inside a STARK, with mempool nodes recursively folding those proofs together until each block carries just one. Under that model, he wrote, “Ethereum can then never add a new precompile again.”
The lattice debate: His posts capped a weekend argument that started Friday, when a16z crypto released Aerie, which aggregated 32,768 lattice-based Falcon-512 signatures on a single laptop in 0.65 seconds. 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.” Under EIP-8288, lattice fans could still use their schemes by wrapping them in a STARK client-side.
Not settled yet: EIP-8288 remains a draft, and the spec still marks its leanSTARK route as “reserved.” The EF’s post-quantum roadmap meanwhile keeps “PQ sig precompiles” on the docket for a later fork it calls J*, so Vitalik’s no-new-precompiles stance isn’t yet reflected in the Foundation’s own plans.