Vitalik Buterin is pushing EIP 8288 to boost Ethereum's cryptography capabilities without adding extra precompiles or weighing down the Ethereum Virtual Machine with more verification tasks.

The idea takes a different approach that enables STARK proofs to be generated locally and consolidated before being uploaded to the blockchain by moving complex computations to users' devices. Buterin argues that Ethereum should verify the results of these computations without requiring the underlying data to be processed and stored on-chain.

Why Vitalik Buterin Wants Fewer Ethereum Precompiles

Buterin argues that the majority of additional cryptographic functions cannot be supported by precompiles or the Ethereum Virtual Machine. Both methods necessitate the entry of relevant information into Ethereum's execution environment, usually via transaction calldata.

Because Ethereum's data carrying capacity is limited, this raises a scaling issue. Even with PeerDAS and blocks carrying blob data, Buterin noted a practical data throughput ceiling of about 8 MB per second in his post on X on October 19, 2026.

The strain on this limited capacity could be increased by adding more cryptographic functions. Buterin wants developers to carry out complex calculations outside of the blockchain's primary execution mechanism, rather than adding more cryptographic operations that Ethereum must manage directly.

He referred to this strategy as EIP 8288 maximalism, claiming that calculations that don't require Ethereum's primary execution channel ought to stay outside of it.

How EIP 8288 Uses Client Side STARK Proofs

The system described in EIP 8288 allows users to carry out cryptographic calculations on their own devices and produce STARK proofs to show that the work was done correctly. Instead of sending Ethereum all the underlying calculations and data, users can show that the necessary operation was carried out.

Scalable Transparent Arguments of Knowledge, or STARKs, enable a verifier to verify a computational claim without having to perform the computation again. Recursive aggregation, as proposed, merges several proofs into a single proof that is block-level verifiable.

Dependency frames that specify cryptographic needs using scheme identifiers, data hashes, and verification key hashes are introduced in the official specification. The validity of these dependencies can be established by the recursive STARK that results from aggregating them outside of the primary execution process.

As a result, Ethereum wouldn't need to get each original signature or proof in its entirety to validate the necessary cryptographic claims. Additionally, Buterin pointed out that STARK proof generation is getting quicker, even on mobile devices, which makes client-side computation a more logical choice.

Ultimately, precompiles and EVM are both the wrong place to put most cryptography support into Ethereum. The reason is that precompiles and EVM both operate on data that has to be included into the ethereum chain somehow, which realistically means included in a block as calldata. That space is limited - even with PeerDAS and blocks-in-blobs, there's a practical cap of ~8 MB/s before it starts getting uncomfortable.

Remember: it's not a blockchain. It's a cryptographic world computer. Any data/computation that does not need to be in the "main thread" of data/execution should not be put into the main thread.

Instead, the correct solution is... EIP-8288 maximalism.

If you have any heavy computation that's self-contained, compute it and STARK it client-side (this is quickly getting faster and faster, even on phones), and push the STARK through the EIP-8288 recursive aggregation mechanism. 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.

This way everyone can use whatever cryptography they want, the Ethereum chain can be lean, and we never need to add more precompiles again.

— vitalik.eth (@VitalikButerin) October 19, 2026

Recursive Aggregation Could Support Quantum Safe Signatures

Support for cryptographic systems that are costly to verify using current Ethereum transaction processes is one of EIP 8288's main uses. The proposal focuses on STARK proofs and quantum-resistant signatures, both of which, when submitted separately, might demand a significant amount of gas and calldata.

According to the proposal, hash-based quantum-resistant signatures can take up between 2 and 3 KB and need between 150,000 and 200,000 gas to verify. STARK proofs can be larger than 128 KB, and if faster proof creation is given priority, they can approach 512 KB.

Quantum-resistant authentication and privacy applications may become costly to run if these elements are submitted separately. An alternative is provided by recursive aggregation, which unifies their verification requirements into a single proof.

The specification also explains how mempool nodes transfer aggregated data to peers and combine valid transaction requirements into recursive proofs. This decreases the additional bandwidth used by block builders and lessens the quantity of repetitive information expressed across the mempool.

To reduce denial-of-service threats, the proposal places restrictions on dependencies per transaction and wrapper. The reliability of the underlying aggregation circuits, hashing algorithms, and proof methods all affect its security.

Ethereum's Cryptographic Flexibility & the EIP 8288 Debate

With EIP 8288, developers may have more flexibility in selecting cryptographic methods without Ethereum having to create a specific precompile for every new system. Developers might create proofs locally and verify their correctness on-chain using the aggregation approach.

Applications requiring privacy tools, quantum-resistant signatures, and other cryptographic techniques that could otherwise face significant verification costs benefit from this flexibility. Additionally, it supports Buterin's claim that Ethereum ought to function as a cryptographic world computer instead of requiring all computations to follow its primary execution path.

But EIP 8288 is still only a draft. Clients without support would reject transactions using the new dependency frame mode and blocks including the proposed recursive proof field, according to its specification, which also lists a network update as required for activation.

As a result, the proposal describes a potential architecture modification rather than an existing Ethereum functionality. Adoption of the necessary protocol modifications, security evaluation, and implementation will determine its impact.

If you find any issues in this article or notice missing information, please feel free to reach out at team@etherworld.co for clarifications or updates.

To promote your Web3 articles, events, and projects, you may reach out anytime via EtherWorld PR for submissions and collaboration.

Related Articles

1. Vitalik’s Bitcoin-Inspired Plan for Ethereum
2. Vitalik Buterin Outlines Ethereum's Lean Vision
3. Vitalik Buterin Explains Cryptography’s “Final Boss”
4. Vitalik Buterin Says Options-Based DeFi Is Already Taking Shape
5. Vitalik Buterin Unveils Analysis on Ethereum's Diverse Layer 2 Landscape

To follow blockchain news, track Ethereum protocol progress, and read our latest stories, subscribe to our weekly today.

Join the EtherWorld & Avarch Internship Program and build your career in blockchain, content, social media, video, podcast editing, or operations. Send your resume and brief introduction to contact@etherworld.co.