I noticed that Vitalik recently shared very important details about the future of the execution layer in Ethereum, and the topic is worth taking a moment to discuss.



The first development relates to the state tree. The idea here is to transition from the current Merkle Patricia structure to a more efficient binary tree structure, with the main improvement relying on the use of stronger hash functions like Blake3 or Poseidon series. This significantly reduces the length of Merkle branches, thereby lowering the bandwidth costs for verification. What I like about this approach is that they are studying its application through EIP-7864, not just a theoretical idea. Additionally, the plan includes unifying storage cells into pages, which reduces access costs for adjacent storage, while maintaining metadata bits to enable future state expiration features.

The second development is more bold: replacing the entire EVM. Vitalik points to the possibility of using a RISC-V architecture for the new virtual machine. The idea is that the new VM should improve execution efficiency and proof generation simultaneously, support creating ZK proofs on the client side, and simplify overall code execution. The application path is clear: first replace pre-defined contracts, then allow deploying the new virtual machine contracts, and finally achieve backward compatibility and a gradual transition from EVM.

What’s interesting is that these improvements are not random—each change is designed to solve a specific problem. Using an optimized hash function means better performance, restructuring the tree means resource savings, and moving to RISC-V opens the door for more efficient proofs. This reflects a long-term vision for the evolution of Ethereum’s core.
View Original
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
  • Reward
  • Comment
  • Repost
  • Share
Comment
Add a comment
Add a comment
No comments
  • Pin