How AI’s HBM–GPU Shift Mirrors Blockchain’s Move to State Trees and NewVMs

3-Point Summary

• AI entered a new era by redesigning its architecture with HBM and GPUs; Ethereum now faces similar structural turning points with State Tree restructuring (EIP‑7864) and a VM transition (EVM → RISC‑V).
• EIP‑7864 aims to remove Ethereum’s data‑access bottlenecks by shortening Merkle paths, reducing ZK proving costs, and reorganizing state into page‑based structures.
• EVM’s complexity makes ZK proving inefficient, making a RISC‑V‑based NewVM a necessary evolution for the ZK and L2 era.

Ethereum now faces the same structural turning points that pushed AI into its new era.

20-Second Shorts Video

Two structural shifts Ethereum must prepare for in the AI era

Over the past decade, the AI industry has entered a completely new era through two structural shifts. First, to handle exploding data, it adopted High Bandwidth Memory (HBM), and second, to cope with workloads that general-purpose CPUs could no longer handle, it shifted to a GPU‑centric architecture.

These two changes were decisive moments where AI abandoned its legacy architecture and embraced a new one to break through the bottlenecks of data access speed and execution environment efficiency.

Ethereum is now facing two very similar turning points to what AI has already gone through: namely, a State Tree restructuring (EIP‑7864) and a VM transition (EVM → RISC‑V‑based NewVM).

In my previous post, Why ETH Could Break Out Again in 2028: The Structural Thresholds Driven by Onchain Finance, AI, and RWA , I discussed three thresholds at which Ethereum could be structurally re‑rated.

If we seriously prepare for the moment when tokenized U.S. Treasuries reach 1% of all Treasuries,
stablecoins reach 1% of global M2,
and Ethereum L2 settlement fees reach 1% of TradFi payment rails,
then State Tree restructuring (EIP‑7864) and VM transition (EVM → RISC‑V) are less a choice and more a necessity.

---

1. AI’s High Bandwidth Memory (HBM) and Ethereum’s State Tree overhaul (EIP‑7864)

The first turning point of the AI era began with acknowledging that “data access speed is the bottleneck.” What large models truly needed was not just raw compute, but how fast parameters could be fetched from memory.

HBM provides far higher bandwidth than conventional DRAM and sits right next to the GPU, minimizing data movement distance. Thanks to this architecture, AI can run ultra‑large models like GPT‑4 at practical speeds, and the paradigm has shifted from “compute‑centric” to “data‑access‑centric.”

Ethereum is at a similar point. Its current state tree uses a hexary MPT + keccak structure, but limitations are already visible in ZK proving, client verification, and storage access performance.

EIP‑7864 proposes changing this to a binary tree + faster hash function (blake3 or Poseidon). Through this, it aims to:

• Shorten Merkle branch length by roughly 4×,
• Reduce ZK proving costs by 3–100×,
• Group storage into “pages” to optimize bulk data access, and
• Make it easier for clients and ZK apps to directly prove Ethereum state.

Just as AI fundamentally redesigned its memory architecture with HBM, Ethereum is entering a phase where it redesigns the State Tree data structure itself via EIP‑7864.

---

2. EVM inefficiency from the perspective of ZK proof generation and verification

To understand ZK technology, it is crucial to distinguish between “proof generation (proving)” and “proof verification (verification)”. In a ZK rollup, L2 compresses all processed transactions into a single ZK proof and submits it to L1, and L1 simply checks whether that proof is valid.

The key point is this: proof verification is very fast, but the cost of proof generation heavily depends on the VM architecture. EVM exposes structural inefficiencies precisely in this “proof generation” phase.

① Why ZK proof generation is hard: EVM inevitably leads to large circuits

A ZK prover must translate every EVM operation into a mathematical circuit. However, because EVM uses a stack‑based architecture, a wide variety of opcodes, and non‑ZK‑friendly hash functions, the resulting circuits become unnecessarily large and proving time increases significantly.

• Stack‑based architecture: many push/pop operations make circuits more complex,
• 140+ opcodes: each opcode requires its own circuit rules,
• Non‑ZK‑friendly hash: keccak is very expensive in circuit form,
• Irregular memory access: makes circuit optimization difficult.

For example, if an L2 processes 1,000,000 transactions, the ZK prover must convert all corresponding EVM operations into a massive circuit. This process accounts for most of the L2 cost and is a major reason why today’s ZK rollups are still relatively slow and expensive.

② In contrast, proof verification on L1 is very fast

The beauty of ZK is that verification cost is extremely small. Whether an L2 processes 1,000 or 1,000,000 transactions, L1 only needs to check “whether this proof is valid.” In other words, even if the number of L2s grows, the burden on L1 barely increases.

The problem is not L1, but rather that the process of proving EVM execution on L2 is structurally inefficient. This is why ZK rollup proving costs remain high and L2 fees are not dropping as quickly as we might hope.

③ Why client‑side proving is difficult

In the long run, a “client‑side proving” model— where users directly generate ZK proofs of their account state or specific transaction execution—will be important. However, EVM is too complex for lightweight ZK proof generation on devices like smartphones or laptops.

• Too many opcodes, making circuits heavy,
• A complex memory model that is hard to optimize,
• A stack‑based design that does not map cleanly to ZK circuits.

In short, EVM is far from the kind of “lightweight and simple VM” needed in the ZK era. To address this limitation, Vitalik has proposed a RISC‑V‑based NewVM, aiming to dramatically reduce proving costs through a ZK‑friendly architecture.

3. AI’s CPU → GPU transition and Ethereum’s EVM → RISC‑V transition

The reason AI moved from CPU to GPU is straightforward: the legacy execution environment could no longer meet the computational demands of the new era. CPUs are optimized for serial processing, whereas AI requires massive parallelism, so GPUs—with thousands of cores for parallel computation—naturally became the standard.

Ethereum’s VM challenges can be understood in the same light. EVM is a general‑purpose VM designed in 2015, without today’s on‑chain finance, ZK, and L2 environment in mind. As a result, it shows multiple limitations in terms of execution efficiency and structural simplicity.

• Limits of computational efficiency
  EVM struggles to process complex operations quickly, so it relies on separate precompile modules for cryptography, hashing, and signature verification. This undermines the internal consistency of the VM and increases protocol complexity.
• Structural complexity
  A growing set of opcodes, stack‑based semantics, and accumulated exception rules make the VM heavier and harder to maintain. Over time, this becomes a burden for L1, L2, and clients alike.
• Misalignment with the ZK era
  As discussed in section 2, EVM is not ZK‑friendly, which imposes structural limits on how much L2 proving costs can be reduced. In other words, it is not an ideal VM for the ZK rollup era.

For these reasons, Vitalik is proposing a RISC‑V‑based NewVM. RISC‑V has a simple instruction set and rule‑based structure, making it much lighter and more predictable than EVM, and naturally more compatible with ZK provers.

• A simple instruction set that makes VM implementation easier,
• Significantly smaller ZK circuits, reducing proving costs,
• The ability to replace most precompiles with plain NewVM code,
• A cleaner, more maintainable protocol structure over the long term.

Just as AI opened a new era by moving from CPU to GPU, Ethereum’s transition from EVM to a RISC‑V‑based VM looks like a natural evolutionary path for the age of on‑chain finance, ZK, and L2.

---

Conclusion: AI has already arrived, Ethereum is still on the road

Thanks to its centralized environment, AI was able to adopt structural changes like HBM, GPUs, and large‑scale parallel computing relatively quickly and has already settled into its new era.

Ethereum, by contrast, must attempt changes of similar magnitude under far stricter constraints: global node consensus, decentralization, security, and backward compatibility. This makes the process slower, more complex, and consensus‑building takes much longer.

Even so, if we take seriously the moment when tokenized U.S. Treasuries reach 1% of the total, stablecoins reach 1% of global M2, and Ethereum L2 settlement fees reach 1% of TradFi payment networks, then State Tree restructuring (EIP‑7864) and VM transition (EVM → RISC‑V) are effectively unavoidable choices.

As AI has already demonstrated, the bigger opportunities lie with those who redesign their data structures and execution environments for the new era. It is worth watching how well—and how quickly—Ethereum can walk that path.

Younchan Jung
Researcher exploring structural shifts in AI, blockchain, and the on‑chain economy.

If you would like to read this article in Korean, please click the button below.

Read This Article in Korean →