Vitalik Buterin Shifts Ethereum Scaling Back to L1, Backing EIP-7864 Binary State Tree and RISC-V Beyond the EVM

Crypto Twitter loves a simple story: rollups fix fees, blobs fix data, and everyone can go back to posting "GM" while the base layer quietly does its thing.

Vitalik Buterin is not buying that as the long-term plot.

On March 1, 2026, Buterin publicly pushed Ethereum$1,686.33's scaling conversation back toward Layer 1, arguing that the real ceiling is not blob throughput or the number of Layer 2s, it is two core pieces of Ethereum$1,686.33's plumbing: the state tree and the virtual machine. ^[1] His framing is blunt and very Ethereum$1,686.33-core-dev coded: if zero knowledge (ZK) proving is going to sit at the center of the roadmap, then the parts that make proving expensive have to change.

Ethereum Foundation Publishes 'Strawmap' Roadmap to 2029, Mapping Seven Hard Forks and Major Network Upgrades

Enjoy articles without ads?

The bottleneck he keeps pointing at: proving cost, not vibes

Buterin's claim is straightforward: Ethereum's state tree and VM account for more than 80% of proving costs today. ^[2] That matters because ZK proofs are increasingly treated as the path to cheaper verification, better privacy tooling, and rollup security guarantees that do not depend on trusting a single sequencer or a single prover setup.

If the base layer is "prover-hostile," the ecosystem ends up compensating with layers of workarounds: custom circuits, special precompiles, app specific designs, and parallel systems that duplicate Ethereum state instead of plugging into it cleanly.

CT translated this into the usual meme: "L2s are cool, but the L1 is still the boss fight." The more serious read from dev circles is that ZK is starting to look less like a bolt-on feature and more like an architectural constraint. Once that happens, ignoring proof costs becomes a tax on everything.

EIP-7864: swapping the state tree for a binary design

The most concrete piece of this L1 pivot is EIP-7864, which proposes replacing Ethereum's current hexary Merkle Patricia tree with a binary tree. ^[3]

That sounds like a dry data structure debate, but it hits several pain points at once:

Shorter Merkle proofs: Buterin's argument, echoed in the reporting, is that binary trees can produce proofs that are roughly 4 times shorter than today's structure. Shorter proofs reduce bandwidth and verification overhead, which directly helps light clients and any application that needs to verify state efficiently.
More efficient access patterns: The proposal also introduces the idea of grouping storage slots into "pages." Many smart contracts read adjacent storage slots repeatedly, so fetching a page of related data can be cheaper than grabbing scattered pieces across the tree.
Real gas implications: The reporting notes that for some workloads, this could save more than 10,000 gas per transaction in cases where apps repeatedly touch nearby storage. That is not a blanket gas cut for everything, but it is meaningful in the places where it applies, especially for heavy DeFi contracts and onchain games that are constantly reading and writing state.

There is also a "pair it with better hashes" angle. Buterin floated using more efficient hash functions alongside the tree redesign, which could further reduce proof generation overhead.

The big meta goal is not just cheaper proofs for their own sake. It is making Ethereum's base layer more natively compatible with ZK workflows, so privacy-preserving apps and ZK systems can integrate with Ethereum state without building an entire shadow stack next to it.

Ameen Soleimani Says Ethereum Needs a Poseidon Hash Precompile to Unlock zkEVM Privacy

Why this matters beyond gas: light clients and privacy

Shorter proofs and cleaner state access matter for more than transaction costs.

Light clients live and die on proof sizes and verification costs. Privacy systems do too, because private verification often means proving something about Ethereum state without revealing everything you touched. If proving remains expensive, privacy stays boutique. If proving gets cheaper, more teams can justify building it for normal users instead of just for research demos.

That is why EIP-7864 reads like an infrastructure proposal, but it lands like a product roadmap change.

The other half of the problem: the VM, and a path beyond the EVM

The second pillar of Buterin's post is even spicier: Ethereum's execution layer, and whether the EVM (Ethereum Virtual Machine) is still the right long-term interface.

Buterin floated a future where Ethereum could move toward a RISC-V based architecture. RISC-V is an open instruction set used broadly in systems design, and the pitch here is not "new for novelty's sake." It is about efficiency, simplicity, and making proving less painful. ^[4]

One of his sharper observations is that Ethereum's growing reliance on precompiles (specialized built-in functions for things like cryptography) is a signal. Precompiles exist because some things are too awkward or too expensive in the EVM's current model. Over time, stacking precompiles can start to feel like patching around a deeper mismatch between what Ethereum needs and what the EVM was designed to do.

A RISC-V direction suggests a world where Ethereum's execution environment is closer to a clean, general purpose target that ZK provers can optimize for more naturally, rather than constantly translating EVM quirks into circuits.

What the community is watching: "Does this break my contracts?"

This is where the temperature rises in developer chats.

The EVM is not just a VM, it is a social contract. It is tooling, audits, battle-tested compiler paths, and a shared mental model for security. Anything "beyond the EVM" instantly triggers two instincts:

Excitement from researchers and protocol folks who want a cleaner proving target.
Caution from builders who have to ship, maintain, and secure production code.

Threads discussing "more execution layer changes" have been circulating in Ethereum community spaces, with the same recurring question: how do you evolve the execution layer without stranding existing contracts, or splitting the ecosystem into incompatible worlds? ^[5]

Buterin's comments read more like a direction of travel than a near-term migration plan. Still, the fact that it is being said out loud, in public, is itself a signal. Ethereum is willing to revisit sacred cows if ZK economics demand it.

Vitalik Buterin: Ethereum Smart Accounts Could Launch Within 12 Months, Ushering in Account Abstraction

The L2 angle: not a rejection, more like a rebalancing

None of this is "rollups are dead." It is closer to: rollups are not the final answer if the base layer remains expensive to prove against.

Ethereum's rollup centric roadmap made sense when the primary scaling constraint was execution on L1 and the main optimization game was data availability. But if the future involves more ZK verification everywhere, then the cost structure of proving becomes a first-class bottleneck. That bottleneck lives inside Ethereum's state model and execution model.

So yes, L2s still matter. But L1 needs to become a better proving substrate, or L2s inherit an avoidable inefficiency tax.

Practical takeaway: what to watch next, and what can go wrong

For readers trying to trade, build, or just avoid getting rugged by narratives, here are the real catalysts and risks to track:

EIP-7864 momentum: Watch for concrete progress beyond concept, including client prototypes, devnet discussions, and sustained engagement from core devs. A state tree change is not cosmetic, it is deep surgery.
Compatibility strategy: Any credible plan will need crisp answers on migration, tooling, and how Ethereum preserves existing contract behavior. If this stays hand-wavy, adoption slows.
ZK performance benchmarks: The whole thesis is "proof costs are the bottleneck." Expect increasing pressure for measurable proving improvements, not just architectural elegance.
Execution layer experimentation: RISC-V talk is a long-range signal. The near-term story is likely incremental VM changes, more standardization, and fewer special-case hacks. The risk is fragmentation if multiple execution targets compete without a clear path.

Ethereum is doing what it always does at its most serious moments: choosing hard engineering over easy slogans. If you are holding a bag, building an app, or just lurking in Discord waiting for the next narrative wave, the key is simple: watch the protocol proposals, not the hot takes. The next cycle of "scaling" might be less about adding layers and more about rebuilding the foundation.