Vitalik Buterin has a new answer for Ethereum’s cryptography problem: stop solving it on-chain.
In a post on X, the Ethereum co-founder argued that precompiles and the EVM are both the wrong place to put most cryptographic support, since both ultimately depend on data that has to be squeezed into a block as calldata—a resource he said has a practical cap of about 8 megabytes per second even with upcoming scaling upgrades.
Buterin wrote that the correct solution is “EIP-8288 maximalism”—the proposal he co-authored with Thomas Coratger that lets heavy computation be run and proven off-chain, with only a compact recursive STARK submitted to the chain.
What Buterin Argued
Buterin’s framing centers on a distinction he’s made before: Ethereum, he wrote, is “not a blockchain,” but “a cryptographic world computer,” and any data or computation that doesn’t need to be in the “main thread” of execution shouldn’t be put there.
Precompiles—specialized, hard-coded functions the EVM calls to speed up specific cryptographic operations—and the EVM’s general execution environment both fail that test, in Buterin’s view. He said this is because both still require their inputs to be included in a block as calldata, space he said has a practical ceiling of roughly 8 megabytes per second “before it starts getting uncomfortable,” even accounting for PeerDAS and blobs-in-blocks.
His proposed alternative, EIP-8288, lets a transaction attach a compact “dependency” claim instead of the raw cryptographic data—for instance, that a signature is valid for a given message or that some computation satisfies a given proof. Mempool nodes then bundle these claims from across the network into a single recursive STARK roughly every half-second, so the chain only ever has to verify one proof per block rather than each piece of cryptography individually.
“If you have any heavy computation that’s self-contained, compute it and STARK it client-side… and push the STARK through the EIP-8288 recursive aggregation mechanism,” Buterin wrote. “The chain sees the fact that the computation was done and what the result is; it never needs to see the actual data and computation.”
Why It Matters
Buterin has previously said EIP-8288 could cut the cost of quantum-safe private transactions by more than 99%. A well-engineered private transaction costs about 300,000 gas today and roughly 10 million gas to make it quantum-safe, figures he’s said could fall to the low tens of thousands under the proposal.
He has said he hopes to see it included in “I-star,” the fork after the upcoming Hegota upgrade, describing it as the natural next step after Frame Transactions (EIP-8141), which EIP-8288 depends on.
Adopting the proposal would also effectively make a shared instruction set Ethereum’s canonical standard for writing these off-chain proofs against—a choice Buterin has called a “big decision” that needs to be made carefully, since it shapes what cryptography the network can support going forward. In his latest post, he framed the payoff as letting “everyone use whatever cryptography they want” while keeping the Ethereum chain itself lean, “and we never need to add more precompiles again.”
A Parallel Debate Over Which Cryptography to Trust
Buterin’s post landed in the middle of a separate but related argument playing out on X over the past several days: whether Ethereum’s long-term cryptography roadmap should lean on lattice-based schemes or stick to hash-based ones like the STARKs EIP-8288 relies on.
The debate traces back to an October 16 post from a16z crypto announcing Aerie, a tool that aggregates lattice-based Falcon signatures using lattice-based SNARKs.
According to a16z, Aerie can aggregate roughly an Ethereum slot’s worth of signatures—32,768 Falcon-512 signatures—on a single laptop in 0.65 seconds, which the firm said is about 29x faster than leanVM, the hash-based aggregation tool Ethereum’s current roadmap relies on.
a16z argued that Ethereum’s planned hash-only design leans on “non-standard constructions” outside NIST’s standards, with the underlying hash still undecided, limiting support from hardware wallets and institutional custody systems—and that relying exclusively on hash-based cryptography “may appear safer” but “can lead to more brittle systems.”
Starknet founder Eli Ben-Sasson pushed back directly, calling lattice cryptography “ripe for AI to attack” and arguing that the succinct lattice-based proof systems a16z is building on are “too new,” having existed only since 2012. He recommended waiting another three to five years “for AI to kick the tires, before entrusting serious $ with it.”
Responding in the same thread, developer Gabriel Shapiro said Ethereum’s hash-based approach “remains the best option” for now, while suggesting lattice support could still be added later “through a precompile if it is proved to be AI-secure”—a framing Buterin rejected. Replying directly, he argued the better path is to support any cryptography, including lattices, through EIP-8288 itself: “You make whatever signature you want locally, then STARK it, and then it gets included through the stark aggregator machine. Don’t need any calldata onchain. Ethereum can then never add a new precompile again.”
Also read: OpenAI Agent Uses Another Wallet’s ETH Without Approval
