Ethereum’s core architect is entering a major overhaul, with a two-part plan to reform the execution layer rather than applying incremental tweaks, aiming to tackle the biggest proving bottlenecks.

A binary-state design would organize storage into pages of 64 to 256 slots, reducing gas costs for adjacent access and cutting execution costs on common storage patterns.

The VM shift could reduce reliance on precompiles and enable client-side proving, letting users generate proofs about contract calls locally.

Hash function options under consideration, including Blake3 or Poseidon variants, to boost prover performance and verification efficiency.

The transition prioritizes backward compatibility, with potential gas changes during the shift and integration within broader scaling efforts to avoid disrupting existing systems.

Longer-term ideas include moving from the EVM to a RISC-V based VM to restore simplicity, better align with prover environments, and improve efficiency.

EIP-7864 would replace the hexary Merkle Patricia Tree with a binary state tree and a more efficient hash, shrinking Merkle branches and boosting light-client proving by up to several-fold.

The binary-tree approach could yield 3x to 100x proving efficiency gains depending on the hash function, with Poseidon requiring extra security review.

The first change is a state-tree overhaul via EIP-7864 to reduce data bandwidth and boost proving efficiency, potentially affecting light clients and revisiting Verkle/other prior designs.

Near-term gains could come from a vectorized math precompile, a GPU-like accelerator for EVM cryptographic ops to accelerate performance.

Overall, the proposals tie state-tree reform and VM replacement as central to Ethereum’s future scalability, aiming for better proving efficiency, lighter clients, and a cleaner design.

A phased deployment outlines introducing the new VM for precompiles first, then contracting within the new VM alongside the EVM, and finally retiring the EVM by running it as a smart contract inside the new VM; similarly, a three-stage move to a RISC-V VM would start with precompiles, then contracts, and finally retire the EVM.