Vitalik Buterin Outlines Ethereum’s Two Most Consequential Long-Term Technical Changes

Vitalik Buterin has proposed replacing Ethereum’s state tree with a binary structure under EIP-7864 and, longer term, swapping the EVM for a RISC-V virtual machine to solve proof-efficiency bottlenecks.

The State Tree Change: EIP-7864

The more near-term of the two proposals is EIP-7864, worked on by @gballet and others, which switches Ethereum’s current hexary keccak Merkle Patricia Tree to a binary tree using a more efficient hash function.

The current hexary structure was designed for a different set of priorities than the proving-heavy future Ethereum is building toward. Switching to a binary tree produces four times shorter Merkle branches, because binary is 32 times log(n) compared to hexary’s 512 times log(n) divided by 4. That reduction makes client-side branch verification significantly cheaper and cuts data bandwidth requirements for tools like Helios and PIR by the same factor.

The proving efficiency gain compounds from there. The 3x to 4x improvement from shorter branches is separate from the hash function change, which could deliver an additional 3x using blake3 compared to keccak, or potentially 100x using a Poseidon variant, though Buterin notes more security work is required before Poseidon would be deployment-ready.

The binary tree structure also introduces a page-based storage design, grouping adjacent storage slots into pages of 64 to 256 slots, roughly 2 to 8 kilobytes. The block header and the first 1 to 4 kilobytes of code and storage share the same page, which means contracts that read from their first few storage slots get batch efficiency rather than paying individual access costs. Buterin notes this could save more than 10,000 gas per transaction for dapps that already load data from their first storage slots, which describes a large portion of active deployed contracts.

Binary trees are also simpler to implement and audit. A more predictable access depth across large and small contracts reduces variance in execution costs, and the structure creates a natural place to embed metadata needed for future state expiry work.

The VM Change: EVM to RISC-V

The second proposal is longer-term and, by Buterin’s own characterization, still non-consensus. The argument is that the EVM’s architecture is the wrong substrate for a proving-heavy blockchain, and that replacing it with a more efficient VM such as RISC-V would address the problem at the root rather than managing it through accumulating precompiles and workarounds.

The case Buterin makes rests on four properties RISC-V has over the EVM. First, raw execution efficiency: RISC-V outperforms the EVM to the point where most precompiles become unnecessary, because the underlying computation they were pre-optimizing for can simply run efficiently in the VM itself. Second, prover efficiency: ZK provers are today written in RISC-V, which means a RISC-V blockchain VM is natively aligned with the proving infrastructure being built.

Third, client-side proving: a RISC-V VM allows users to generate ZK proofs locally about what happens when their account is called with a specific piece of data, enabling privacy and verification use cases that the EVM cannot support without external tooling. Fourth, simplicity: a RISC-V interpreter is a couple hundred lines of code, which is what a blockchain VM should require.

The deployment roadmap Buterin sketches has three stages. In the first, a new VM, potentially RISC-V, handles precompiles only, with 80% of current precompiles and many new ones becoming blobs of NewVM code. In the second, users can deploy NewVM contracts directly. In the third, the EVM is retired and reimplemented as a smart contract written in NewVM, preserving full backwards compatibility for existing deployed contracts with the only meaningful change being gas cost adjustments, which Buterin argues will be overshadowed by the broader scaling work happening in parallel.

Why Both Changes Matter Together

Buterin frames both changes as addressing the same root problem from two directions. The state tree and the VM together account for more than 80% of the bottleneck in efficient proving. Addressing either one without the other leaves the larger problem partially intact. Addressing both produces a protocol that is structurally aligned with the ZK-proof-heavy future Ethereum has been building toward rather than one that is perpetually retrofitting that future onto infrastructure designed for a different era.

The honest acknowledgment in Buterin’s framing is that the VM change in particular is not where current consensus sits. He describes it as the thing that will become obvious once the state tree changes are finished, a sequenced argument rather than an immediate proposal. Binary trees first. Then, once the proving infrastructure matures around the new state structure, the case for replacing the VM becomes harder to argue against.

The EVM has accumulated complexity over years of incremental additions driven partly by a reluctance to engage with its core limitations. Buterin’s position is that meeting Ethereum’s generality promise requires fixing the VM rather than routing around it indefinitely.

The post Vitalik Buterin Outlines Ethereum’s Two Most Consequential Long-Term Technical Changes appeared first on ETHNews.