Vitalik Buterin is steering Ethereum away from the familiar L2 scaling narrative and back toward something more fundamental: fixing the protocol’s architecture itself. In a recent detailed proposal, the Ethereum co-founder argued that the network’s real constraints aren’t rollup capacity or blob space, but rather deeper structural issues embedded in how the protocol manages state and executes code. His ethereum core upgrade vision tackles two components that account for over 80% of proving costs, a critical bottleneck as zero-knowledge technology becomes central to Ethereum’s future.
This shift represents a philosophical pivot in how Ethereum thinks about scaling. Rather than continuing to stack solutions on top of an aging foundation, Buterin is asking whether the foundation itself needs reconstruction. The proposal combines near-term pragmatism with longer-term architectural ambition, suggesting changes that could make Ethereum dramatically more efficient while setting the stage for a fundamentally different execution model.
The State Tree Problem: Why Current Architecture Limits Efficiency
At the heart of Buterin’s proposal lies a surprisingly specific technical insight: Ethereum’s current state management structure creates unnecessary overhead when generating zero-knowledge proofs. The state tree—essentially the data structure that tracks every account balance, smart contract state, and storage value on Ethereum—was designed for read-write efficiency during normal operations. It was not optimized for the kind of cryptographic operations required by modern proving systems.
This mismatch becomes critical as zero-knowledge rollups and validity proofs transition from experimental to essential. When a prover needs to generate a ZK proof that verifies a transaction’s correctness, they must produce mathematical evidence of every step of computation. The current state tree architecture makes this proof generation expensive and slow. The architectural constraints around state verification mean that proving costs scale poorly as the network grows, creating a ceiling on how efficient L2s and validity proofs can ultimately become.
From Hexary Trees to Binary: A Structural Redesign
Buterin’s primary solution is encoded in EIP-7864, which proposes replacing Ethereum’s current hexary Merkle Patricia tree with a binary tree structure. This sounds like a minor technical detail, but the implications are substantial. Binary trees produce Merkle proofs roughly four times shorter than hexary structures, dramatically reducing the cryptographic overhead required to prove state transitions. Imagine trying to prove ownership of a specific account balance—currently you need a lengthy cryptographic certificate proving your position in Ethereum’s state tree. With binary trees, that proof shrinks by roughly 75 percent.
The efficiency gains extend beyond mere proof size. The binary tree design groups storage slots into pages, allowing applications that repeatedly access related data to load them together rather than individually. In practice, many decentralized applications cluster related state—think of a lending protocol accessing multiple collateral positions, or an AMM querying adjacent liquidity buckets. With proper page alignment, these common access patterns could save over 10,000 gas per transaction in optimized scenarios. Gas savings compound across the network, reducing user costs while improving throughput.
Buterin also suggested pairing the tree change with more efficient hash functions, potentially delivering additional gains in proof generation speed. The combination of structural redesign plus optimized cryptographic primitives could create multiplicative efficiency improvements. More importantly, the redesign would make Ethereum’s base layer genuinely prover-friendly, allowing zero-knowledge applications to integrate directly with Ethereum’s state instead of building parallel systems that never fully integrate with mainnet. This resolves a fundamental tension in current scaling strategies: L2s achieve throughput by abandoning Ethereum’s state, but doing so fragments liquidity and user experience.
Consolidating a Decade of Lessons Into a Clean Architecture
Ethereum’s current state tree evolved organically during the network’s first decade, optimized for immediate practical concerns rather than long-term strategic requirements. Each amendment, fork, and optimization added complexity without fundamentally revisiting whether the underlying structure remained appropriate. The binary tree proposal represents an attempt to step back and consolidate everything learned about state management into a cleaner, more future-proof design.
This consolidation matters beyond pure efficiency metrics. A simpler state tree is easier to reason about, audit, and upgrade. It reduces the mental model required to understand how Ethereum works at its deepest levels. For a protocol that aspires to be decentralized and auditable, architectural clarity has genuine value. Developers building on Ethereum can more easily understand the underlying constraints, making better design choices in their applications. Validators and stakers gain confidence that they understand how their consensus actually secures the network.
The Virtual Machine Question: Is the EVM Itself the Bottleneck
Even more ambitious than the state tree redesign is Buterin’s longer-term critique of the Ethereum Virtual Machine itself. The EVM—the runtime environment in which smart contracts execute—was revolutionary when introduced but has accumulated decades of technical debt. More importantly, Buterin argues, its design reflects assumptions about computation that no longer align with how modern zero-knowledge systems actually work.
The symptom of this misalignment is the EVM’s growing dependence on special-case precompiles: hand-optimized implementations of cryptographic operations like elliptic curve pairing, modular exponentiation, and hash functions. Each precompile exists because the EVM cannot efficiently execute these operations through its normal instruction set. Instead of a general-purpose virtual machine, Ethereum increasingly resembles a specialized appliance bolted together with domain-specific components. If Ethereum’s core promise is general-purpose programmability, Buterin argues, the VM should support that vision without requiring constant special-casing.
RISC-V as a Long-Term Replacement Path
Buterin’s radical proposal involves eventually moving beyond the EVM toward a RISC-V–based architecture. RISC-V is an open-source instruction set architecture designed for simplicity and extensibility. Unlike the EVM, which was purpose-built for Ethereum, RISC-V is a genuine general-purpose computing platform used in academic research, embedded systems, and increasingly in production hardware.
The advantages of RISC-V for Ethereum are compelling. First, it offers dramatically reduced complexity. The EVM instruction set reflects layer upon layer of design decisions made under different constraints. RISC-V starts from first principles: a minimal set of instructions that can compose into arbitrary computation. Second, RISC-V enables better raw execution efficiency. General-purpose instruction sets compiled to RISC-V often run faster than code optimized for the EVM, because the EVM was never designed for that kind of workload. Third, and most importantly for Ethereum’s roadmap, RISC-V already integrates deeply with zero-knowledge proving systems. Companies building ZK provers have optimized their systems around RISC-V, making it far cheaper to prove RISC-V execution than EVM execution.
Buterin proposed a phased transition path rather than a disruptive fork. Initially, RISC-V would power precompiles—handling specialized operations like cryptographic functions. As quantum and cryptographic threats evolve, having a more flexible execution model becomes valuable. Over time, RISC-V support would expand to user-deployed contracts, allowing developers to compile existing applications into RISC-V and deploy them on Ethereum. Eventually, the EVM itself would become a compatibility layer running atop RISC-V, preserving backward compatibility while enabling superior performance for new applications.
The Vectorized Math Precompile: Near-Term Cryptographic Acceleration
Between now and any hypothetical EVM replacement lies a decade or more of gradual transition. In the nearer term, Buterin proposed a more pragmatic upgrade: a vectorized math precompile, essentially a GPU-like acceleration module for the EVM. This precompile would allow large-scale cryptographic operations—matrix multiplication, polynomial evaluation, batch verification—to execute far faster than the current precompile suite supports.
For applications relying on advanced cryptography—zero-knowledge rollups, confidential transactions, threshold encryption schemes—this acceleration could provide immediate throughput improvements. A vectorized math precompile wouldn’t require replacing the EVM or restructuring Ethereum’s state, yet would address one of the most significant bottlenecks in current proof generation. It represents the kind of incremental improvement that maintains compatibility while delivering genuine efficiency gains.
The Complexity Counterargument: Adding Layers Creates Risk
Not everyone embraces Buterin’s vision. Analyst DBCrypto and others have criticized what they see as proliferating abstraction layers across Ethereum’s roadmap. Each new framework, protocol modification, or architectural component adds complexity, introduces assumptions that might not hold under real-world conditions, and creates additional potential attack surfaces. The Open Intents Framework, designed to address L2 fragmentation, exemplifies this concern: adding a new layer supposedly to fix problems created by previous layers.
The counterargument carries weight. Ethereum’s security model depends partly on the ability of a single validator with modest hardware to audit the entire protocol and detect attacks. Each architectural layer makes that validation harder. Protocol complexity also makes it easier for subtle bugs to hide. The history of smart contract exploits and protocol vulnerabilities demonstrates that even tiny oversights in complex systems can cost billions. Adding more complexity—even well-intentioned complexity—increases the surface area for catastrophic failures.
Layering Versus Reworking: The Strategic Debate
The tension between Buterin’s approach and the complexity skeptics reflects a deeper strategic disagreement about how to scale Ethereum. The layering approach—focused on L2s, blob scaling, and interoperability frameworks—accepts Ethereum’s current architecture as a constraint and works within it. This strategy offers incremental improvements and minimizes disruption risk. If L2s achieve sufficient throughput and user experience quality, perhaps the base layer architecture never needs fundamental change.
Buterin’s reworking approach, by contrast, argues that certain architectural decisions cannot be optimized around indefinitely. State tree structure, virtual machine design, and proving efficiency are foundational choices that cascade through every layer built on top. Attempting to add scaling solutions on top of suboptimal foundations creates permanent limitations. Better to invest effort in upgrading the foundation itself, even if that requires greater complexity and coordination in the short term.
Buterin acknowledges the complexity risk directly in his proposal, suggesting a phased approach rather than disruptive changes. The state tree upgrade could occur gradually, with parts of Ethereum operating under the new structure while other parts transition. RISC-V support could start with precompiles and expand over years. This gradualism doesn’t eliminate risk, but it allows Ethereum to test and validate each component before making larger commitments.
Zero-Knowledge Proving as the Inflection Point
The timing of Buterin’s proposal is not accidental. Zero-knowledge technology has transitioned from academic curiosity to production necessity. Multiple validity rollups now operate on mainnet, proving transaction execution and settling to Ethereum in compressed form. As this technology matures and proliferates, the bottlenecks Buterin identifies become increasingly acute. Ethereum’s price dynamics increasingly reflect expectations around scaling capacity and proving efficiency.
If Ethereum’s long-term scaling strategy depends on validity proofs—which offer better security guarantees and faster finality than optimistic rollups—then the cost and speed of proof generation becomes critical infrastructure. A system that requires proving billions of transactions daily cannot tolerate 80% of proving costs coming from state tree and virtual machine operations. Buterin’s proposal directly targets this inflection point, asking what Ethereum needs to look like if validity proofs become the dominant scaling paradigm.
From Niche to Essential: Reorienting the Protocol Around ZK
Five years ago, zero-knowledge proofs were a niche research topic. The Ethereum roadmap reflected broader concerns about scalability approaches without assuming ZK would dominate. Today, the situation has inverted. Every serious scaling proposal involves validity proofs. Privacy applications increasingly depend on ZK. Bridges between blockchains use ZK for security. The protocol is gradually baking ZK assumptions deeper into its architecture, from consensus mechanisms to precompiles to roadmap priorities.
Buterin’s proposal is essentially a commitment to orient the entire protocol around making ZK-based applications as efficient and native as possible. Rather than treating zero-knowledge as one optional tool among many, the core upgrade would make it a first-class citizen. This reorientation has implications far beyond performance: it affects how developers think about building on Ethereum, what applications become feasible, and ultimately what role Ethereum plays in a multi-chain ecosystem.
What’s Next: When Might These Changes Actually Happen
Buterin’s state tree proposal could realistically enter development and testing within 1-2 years, with potential deployment in a major fork within 3-5 years. The binary tree structure has undergone preliminary research, and several core developers have begun analyzing implementation paths. The efficiency gains are well-understood and substantial enough that incentives exist to prioritize this work. However, Ethereum upgrades require broad consensus and extensive testing, so timelines remain uncertain.
The virtual machine questions operate on a longer horizon. A transition to RISC-V, even a gradual one, represents a multi-decade undertaking. It requires building entirely new proving infrastructure, developing compiler support, and thoroughly testing compatibility with existing applications. Buterin framed RISC-V as a direction rather than an imminent change, something Ethereum might pursue over 5-10 years as the technology matures and use cases clarify.
What’s certain is that Ethereum’s scaling conversation has fundamentally shifted. The focus has moved from surface-level throughput metrics to deeper architectural questions about state representation, execution models, and proving efficiency. As regulatory clarity and institutional adoption accelerate, the protocols that invested in fundamental improvements will likely outperform those built on increasingly fragile abstractions. Buterin’s vision, for all its technical complexity, represents Ethereum consciously choosing the harder path of architectural excellence over the easier path of adding more layers.
