Key Highlights:
- Vitalik Buterin argues that Ethereum should depend less on precompiles and the Ethereum Virtual Machine (EVM) for supporting extra cryptographic systems.
- He proposes using EIP-8288 to let users generate cryptographic proofs locally and submit STARK proofs through a recursive aggregation mechanism.
- The approach aims to decrease on-chain data and computation while allowing users to adopt distinct cryptography methods without needing new precompiles,
Ethereum co-founder Vitalik Buterin has argued that the network should rethink how it supports distinct cryptographic systems, proposing an idea centred on EIP-8288 and STARK proofs rather than expanding precompiles.
In a post on X, Buterin said both precompiles and the Ethereum Virtual Machine depend on on-chain data, creating restrictions as Ethereum scales. He outlined a simultaneous option in which users perform heavy computations natively, generate cryptographic proofs, and submit those proofs through a recursive aggregation mechanism.
The proposal aims to keep Ethereum’s main execution layer lean while enabling broader cryptographic flexibility for wallets, accounts, and other applications.
Why Does Vitalik Buterin Think Ethereum Should Move Beyond Precompiles?
Buterin argued that precompiles and the EVM are not ideal places to add cryptographic support. They operate on data that must be included in the Ethereum chain. He said that this often means putting the information into blocks as call data, which consumes limited network capacity.
He pointed to a practical data throughput ceiling of approximately 8 MB per second, even with PeerDAS and blocks in blocks. In his view, requiring extra cryptographic operations to depend on on-chain data could place unnecessary pressure on Ethereum’s available capacity. Precompiles provide specialized functionality for cryptographic operations, while the EVM executes smart contract code.
But Buterin’s argument is that extending these mechanisms to accommodate every new cryptographic system would make the network reliant on data and computation being processed directly on-chain. He also acknowledged a probable exception for lattice-based cryptography. Buterin said such cryptography could still be supported through a precompile for applications, including accounts and wallets, provided it is proven to be AI secure.
However, Ethereum should avoid making additional precompiles as its default approach to expanding cryptographic compatibility.
Buterin framed the issue around Ethereum’s role as a system for processing cryptographic computation rather than simply as a blockchain. He argued that data and computation that do not need to be part of the network’s main data and execution processes should be handled outside that core layer.
How Could EIP-8288 and STARK Proofs Change Ethereum’s Approach?
Buterin identified EIP-8288 as his preferred route to supporting a wider range of cryptographic systems. Under the approach he described, users would create signatures and perform the relevant computations natively. They will later produce a STARK proof demonstrating that the computation was completed successfully.
The resulting proof would be submitted through an aggregation mechanism that recursively combines proofs rather than needing Ethereum to process all the underlying data and computation directly. The chain would receive evidence that the work had been performed and information about the outcome. This could decrease the amount of data that needs to be published on-chain.
It would also allow users to work with different cryptographic systems without needing Ethereum to produce a dedicated precompile for every new method. Buterin said client-side proof generation has become faster, including on mobile phones, making this approach increasingly practical. The idea is to move heavy, self-contained computation away from Ethereum’s main execution layer while retaining a way for the network to verify the outcome.
The proposal could have implications for wallets, accounts, and applications that need cryptographic adaptability. Developers could probably use the cryptography methods suited to their applications while depending on proofs to demonstrate that their operations were carried out properly. The comments outline his preferred technical direction, confirming that Ethereum has adopted the approach as a network-wide standard.
The practical impact would rely on implementation, proof generation performance, and how the proposed mechanism works with Ethereum’s existing infrastructure. Ultimately Buterin’s argument is that Ethereum can support more cryptographic diversity without needing every computation or underlying data input to be processed directly on-chain.
By using locally generated proofs and recursive aggregation, the network could aim to preserve a lean execution layer while giving developers autonomy over the cryptographic tools they use.
