Vitalik Buterin proposes a new way to handle Ethereum cryptography

Ethereum co-founder Vitalik Buterin has backed EIP-8288 as a proposed way to support complex cryptography without repeatedly adding new verification functions to Ethereum, arguing that most heavy cryptographic work should happen outside the network’s main execution process.

In a series of October 19 posts on X, Buterin argued that Ethereum’s existing virtual machine and specialized cryptographic functions are unsuitable for supporting every new signature or proof system. He instead favored a design that would let users generate proofs locally and submit them through an aggregation mechanism.

The proposal, EIP-8288, would allow Ethereum to verify that cryptographic operations were performed correctly without including every original signature or proof in a block.

Vitalik Buterin described this approach as part of his vision for Ethereum as a cryptographic world computer, where substantial computation can happen outside the blockchain while its results remain verifiable.

The specification remains a draft and has not received approval for deployment on Ethereum mainnet.

Vitalik Buterin wants less cryptographic work inside Ethereum

Vitalik Buterin’s latest comments focus on how Ethereum handles cryptographic operations that require large amounts of computation or data.

Currently, developers can use the Ethereum Virtual Machine, or EVM, to run smart contracts that verify certain cryptographic statements.

Ethereum provides precompiles, which are built-in functions that perform specific calculations more efficiently than ordinary smart contract code.

These functions can help developers verify signatures, hashes and zero-knowledge proofs.

However, supporting additional cryptographic methods directly through precompiles can require changes to Ethereum’s protocol.

Vitalik Buterin argued that neither approach should become the default solution for every new cryptographic system.

His concern centers on the amount of data that must be included in Ethereum blocks when applications submit large signatures or cryptographic proofs for verification.

In the October 19 discussion, he estimated that even with improvements such as PeerDAS and blocks-in-blobs, the network would face practical limits around 8 megabytes per second before additional data became difficult to handle.

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.… https://t.co/kb3JfEQKpj

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

The estimate represents Buterin’s assessment of future engineering constraints, not Ethereum’s currently measured transaction throughput.

He described Ethereum as a cryptographic world computer in which the blockchain should handle only information requiring shared execution and verification.

The idea is consistent with his earlier work on reducing the amount of computation that every Ethereum validator must independently perform.

In September, crypto.news covered his cryptographic computer vision, which described Ethereum’s proposed transition toward proof-based verification, privacy and more efficient handling of data.

His October comments focused on a specific proposal for making that approach work across different cryptographic systems.

EIP-8288 would combine proofs before they reach Ethereum

The proposed mechanism is described in EIP-8288, titled In-mempool signature and proof aggregation.

Buterin and Ethereum researcher Thomas Coratger created the proposal on June 3, 2026.

According to the official specification, the system would let transactions declare which cryptographic statements must be verified without including all of the original proof material in the final block.

Those declarations would identify the verification scheme, a hash representing the relevant data and a hash associated with the verification key.

The network would use these references to connect transactions with evidence that the required operations were performed correctly.

Users would generate signatures or cryptographic proofs outside Ethereum’s main execution environment.

The proposal allows these proofs to be combined recursively, meaning one proof can establish the validity of several smaller proofs.

Instead of individually verifying every original signature and STARK, Ethereum would verify an aggregated proof covering the relevant transaction dependencies.

A STARK is a cryptographic proof that allows someone to demonstrate that a computation was performed correctly without requiring every verifier to repeat the entire calculation.

The proposed aggregation system would use Lean Ethereum tooling to generate and verify these proofs.

EIP-8288 describes a new transaction frame mode that would declare cryptographic dependencies. The proposal builds on EIP-8141, which introduces a framework for transactions with multiple execution and verification steps.

At the block level, a recursive STARK would demonstrate that the declared dependencies had been satisfied.

The system would continue recording necessary transaction information and cryptographic commitments on Ethereum.

However, its intended design would avoid publishing the original large signatures and proofs as ordinary transaction calldata.

The proposal is not a plan to remove all transaction data from the blockchain or allow applications to operate without verifiable records.

Quantum-resistant signatures are a major part of the proposal

EIP-8288 includes support for cryptographic signatures designed to resist attacks from future quantum computers.

Ethereum currently relies on established digital signature systems for account authentication and blockchain consensus.

Developers are researching alternatives that would remain secure if sufficiently powerful quantum computers become available.

Some proposed quantum-resistant signatures are much larger than the signatures used in conventional Ethereum transactions.

According to EIP-8288, hash-based signatures under consideration can require roughly 2–3 kilobytes and an estimated 150,000–200,000 gas to verify directly.

Lattice-based signatures present comparable challenges in the proposal’s cost discussion.

STARK proofs can require more than 128 kilobytes, with some configurations reaching approximately 512 kilobytes when optimized for fast proof generation.

Including large amounts of this material directly in transactions could create substantial data and execution costs.

Vitalik Buterin argued that users should be able to produce their preferred signatures locally and prove their validity through STARK aggregation.

He discussed the possibility of using lattice-based cryptography for Ethereum accounts and wallets if the relevant security assumptions were established.

His October 19 statement referred specifically to cryptography that might be proven secure against AI-related attacks. That condition is separate from the standard definition of resistance to quantum-computer attacks.

Earlier reporting on Ethereum’s roadmap described how quantum resistance and privacy had become priorities for the network’s future development.

The roadmap includes changes to signature verification and the cryptographic systems supporting Ethereum’s consensus and data availability.

EIP-8288 addresses part of that work by proposing a common method for verifying multiple cryptographic schemes.

Recursive aggregation would start before block production

The proposed process does not depend solely on a block producer collecting every signature and generating one final proof.

EIP-8288 describes recursive aggregation beginning in Ethereum’s mempool, where transactions wait before being included in blocks.

Under the design, users would submit transactions along with the cryptographic evidence required to authorize them.

Mempool participants could validate the submitted evidence, combine several proofs into one and pass the resulting package to other participants.

The specification describes an aggregation interval of 1,000 milliseconds for this process.

Block builders would then collect the relevant transactions and aggregated proofs before constructing an Ethereum block.

A final recursive STARK would cover the dependencies associated with the transactions selected for inclusion.

The draft proposes technical limits intended to prevent malicious users from overwhelming the aggregation system with excessive proof requirements.

For example, its current parameters allow up to 16 specified signature dependencies and one STARK dependency per transaction.

The specification also addresses compatibility with FOCIL, a proposed transaction-inclusion mechanism designed to make censorship more difficult.

An Ethereum analysis of proof-based verification published in September examined the distinction between verifying a computation’s result and ensuring the underlying data remains accessible.

EIP-8288 addresses cryptographic verification while retaining the transaction information needed to identify and validate dependencies.

Its design introduces additional work for mempool participants and block builders, which would need to generate, update and combine proofs. The proposal’s security section identifies the correctness of the proof circuits, hashing functions and recursive verification as assumptions that require careful evaluation.

EIP-8288 remains a draft requiring network approval

The official Ethereum Improvement Proposal repository classifies EIP-8288 as a draft standards-track proposal in the core category.

Its implementation would alter Ethereum’s consensus rules because blocks containing the proposed recursive proof format would not be understood by nodes running software without the update.

The specification identifies EIP-2718 and EIP-8141 as dependencies. Several implementation details remain incomplete, including parameters associated with the aggregated verification key and dependency hashing.

The proposal’s reference implementation is listed as forthcoming. Ethereum developers would need to complete technical work, review the security assumptions and agree on network activation before the design could be deployed. The repository does not currently list an approved mainnet activation date for EIP-8288.

The proposal’s existing test cases cover individual signature verification, multiple proof dependencies, invalid recursive proofs, mempool aggregation and compatibility with transaction inclusion lists.

Its backward-compatibility section states that ordinary transactions without the new cryptographic verification frames would retain their existing behavior.

Nodes that do not implement the new rules would reject transactions using the proposed frame mode and blocks carrying the recursive proof header.

The proposal therefore requires a coordinated network upgrade before its cryptographic aggregation system can become part of Ethereum’s mainnet rules.