Ethereum co-founder Vitalik Buterin has outlined a roadmap that would push advanced cryptography deeper into Ethereum’s core design, with zero-knowledge proofs, formal verification and privacy-preserving computation taking a larger role in how transactions are processed and blocks are built.
In remarks tracing the sector’s evolution since Bitcoin launched in 2009, Buterin described a transition from comparatively simple blockchains to “complex cryptographic networks” able to verify more activity without exposing all of the underlying data. The direction would move more computation away from Ethereum’s main chain, while using cryptographic proofs to let the network check results efficiently.
Buterin said Ethereum aims to make STARK-based verification widely available within roughly two years. STARKs, or scalable transparent arguments of knowledge, are a type of zero-knowledge proof designed without the trusted setup required by some SNARK systems and are generally viewed as more resistant to risks from future quantum computing.
He referred to an Ethereum improvement proposal, described as EIP-8288, as part of a path toward putting STARKs “everywhere” following future protocol upgrades. The wording suggests a more immediate implementation target than earlier long-range roadmaps, where advanced proof systems were often discussed as tools for later stages of Ethereum’s scaling plans.
Proofs would carry more of Ethereum’s workload
Zero-knowledge proofs allow one party to demonstrate that a calculation or statement is valid without revealing the data used to produce it. In an Ethereum setting, that mechanism could let users or secondary networks execute complex computations outside the base layer and submit a compact proof for verification on-chain.
Buterin argued that large proofs do not necessarily need to be processed individually by Ethereum. Proof generation and verification tasks can be parallelized off-chain, then aggregated so that one final proof attests to many computations or transactions when it reaches the network.
That architecture follows the logic already used by many layer-2 networks, which group transactions away from Ethereum’s main chain before publishing compressed data and proofs back to it. Expanding the approach to more protocol functions would give Ethereum’s base layer a narrower task: provide data availability, consensus and final settlement while external systems handle much of the execution work.
The outcome could reduce the amount of data and computation each Ethereum validator must handle directly. It would also give privacy tools a more practical path to deployment, since sensitive information could remain on a user’s device or within a dedicated processing environment before a proof of validity is sent onward.
Buterin described this as a change in the questions blockchain systems can answer. Earlier designs largely concentrated on authorizing transfers — effectively, who can send which asset. Advanced cryptography adds rules around visibility, including who can see a transaction’s details and which parties may verify its validity.
Faster blocks remain a separate challenge
Ethereum’s cryptographic ambitions do not eliminate the network’s performance constraints. Buterin contrasted centralized systems, which he said can reach latency of roughly 100 to 300 milliseconds, with Bitcoin’s global network latency of about 600 milliseconds and its approximately 10-minute block interval.
Ethereum currently targets blocks every 12 seconds, while finality — the point at which a transaction becomes extremely difficult to reverse — takes about 16 minutes under the figures cited in Buterin’s presentation. Future targets discussed in the talk included reducing block times to between four and eight seconds and lowering finality to a range of eight to 32 seconds.
Reaching those targets would require Ethereum to balance responsiveness against the need for geographically distributed validators to communicate reliably. Shorter slots can improve the experience for applications and users, but they can also favor participants with lower-latency infrastructure if pushed too far.
Buterin framed the intended tradeoff as one that limits general-purpose computation rather than forcing the base layer to absorb every application workload. That places more responsibility on proof systems, layer-2 networks and specialized execution environments, while maintaining Ethereum’s role as a shared settlement layer.
FOCIL targets transaction inclusion
The proposal also extends to block production, where transaction ordering and inclusion have become increasingly concentrated among specialized builders. Buterin cited FOCIL, an Ethereum proposal for multi-party block construction, as one potential response.
Under the model he described, 16 participants would contribute to constructing a block before a final builder completes it. The stated aim is to ensure that a valid submitted transaction can be included in the following slot rather than being delayed or excluded by a single block-building actor.
Transaction inclusion has become a sensitive issue as maximal extractable value, or MEV, has made ordering rights economically valuable. Builders can prioritize transactions that generate revenue, while certain transactions may face delays during periods of heavy activity. A multi-party inclusion system could reduce the ability of one participant to control which transactions make it into a block, though its practical effects would depend on the final protocol design and adoption.
AI and formal verification add pressure to the roadmap
Buterin also linked the rapid development of artificial intelligence tools to cryptographic engineering. He argued that AI-assisted coding and security work could help developers build systems that were previously too complex to deploy safely, particularly as codebases extend beyond hundreds or thousands of lines.
The risk is that cryptographic systems demand unusually high assurance. A flaw in a smart contract, proof circuit or bridge can create losses or invalidate the guarantees users expect. Buterin described formal verification — the use of mathematical methods to show software matches a specification — as a major bottleneck for layer-2 security.
Layer-2 systems have frequently relied on layered safeguards, including security committees and redundant checks, when their proof mechanisms or upgrade paths cannot provide complete guarantees. Formal verification aims to strengthen that foundation by demonstrating that an implementation conforms to its stated rules.
Buterin cited falling proof-generation costs as evidence that more computation can become practical. He said ZK-SNARK overhead for AI inference and certain hashing tasks had dropped below 10 times the cost of native computation, while a system he called FLoC had carried roughly 250 times overhead, a figure he said was declining rapidly.
He also pointed to fully homomorphic encryption, which allows computation on encrypted data, and obfuscation techniques as tools advancing faster than expected. These technologies remain computationally demanding, but they could eventually allow applications to process private data without exposing it to operators or counterparties.
Ethereum’s emerging design therefore places cryptographic proofs, aggregation and verification alongside traditional block production and consensus. The approach would make the main network less dependent on checking every detail itself, while demanding that the systems handling work elsewhere can prove their results accurately and securely.
For a deeper look into Ethereum’s evolution and upgrades, explore this detailed guide on Ethereum’s 2025 Pectra roadmap.
Disclaimer: The content on this page is provided for general informational purposes only and does not represent the views or financial advice of Toobit. We make no guarantees regarding the accuracy or completeness of this information and shall not be held liable for any errors, omissions, or outcomes resulting from its use. Investing in digital assets involves risk; users should independently evaluate their financial situation and the risks involved. For further details, please consult our Terms of Service and Risk Disclosure.
