🚀 Gate Square “Gate Fun Token Challenge” is Live!
Create tokens, engage, and earn — including trading fee rebates, graduation bonuses, and a $1,000 prize pool!
Join Now 👉 https://www.gate.com/campaigns/3145
💡 How to Participate:
1️⃣ Create Tokens: One-click token launch in [Square - Post]. Promote, grow your community, and earn rewards.
2️⃣ Engage: Post, like, comment, and share in token community to earn!
📦 Rewards Overview:
Creator Graduation Bonus: 50 GT
Trading Fee Rebate: The more trades, the more you earn
Token Creator Pool: Up to $50 USDT per user + $5 USDT for the first 50 launche
Vitalik’s RISC-V Proposal Rejected! Arbitrum: Ethereum L1 Should Choose WASM
Core developer Offchain Labs of Ethereum Layer 2 Arbitrum has questioned Vitalik Buterin’s proposal to transition Ethereum’s execution layer to RISC-V, publishing a detailed technical article on Ethereum Research on November 20, arguing that WebAssembly (WASM) offers superior long-term advantages.
Vitalik’s RISC-V Proposal: Reduce ZK Proof Costs by 100x
(Source: Ethereum Magicians)
Ethereum co-founder Buterin proposed in an article published on Ethereum Magicians in April to replace the Ethereum Virtual Machine’s bytecode with the open-source RISC-V (pronounced “risk-five”) instruction set architecture (ISA). He believes this change could, in some cases, reduce zero-knowledge proof costs by up to 100 times.
RISC-V is an open-source reduced instruction set architecture, originally developed by the University of California, Berkeley. Unlike closed commercial architectures like ARM or x86, RISC-V’s open-source nature makes it ideal for decentralized systems. In the field of zero-knowledge proofs, the simplicity of RISC-V makes proof circuits easier to construct and optimize, which is Vitalik’s main reason for favoring it.
A 100x cost reduction is an extremely attractive figure. The high gas fees on Ethereum L1 have long been a bottleneck for large-scale adoption, and the computational costs of zero-knowledge proofs, as a core scaling technology, directly affect the economics of Layer 2. Reducing proof costs by 100x would make many more use cases economically viable.
However, researchers at Offchain Labs question the assumptions underlying this proposal. They wrote, “We support these goals, but we question Vitalik’s implicit assumption that a single ISA can best serve both zero-knowledge proof and smart contract delivery.” This critique goes to the heart of the matter: should the architectures optimized for proof efficiency and contract delivery be the same?
Delivery ISA vs. Proof ISA: Separation Is Optimal
(Source: Ethereum Research)
The team’s core argument is to distinguish between the “delivery instruction set architecture” (dISA, the format for uploading contracts to the chain) and the “proof instruction set architecture” (pISA, the format used by ZK virtual machines). They believe these two do not need to be the same. This view challenges a fundamental assumption in Ethereum’s technical roadmap.
Offchain Labs has built a prototype to prove this concept: Arbitrum blocks (including WASM-based Stylus smart contracts) achieve zero-knowledge proofs by first compiling WASM into RISC-V and then proving RISC-V execution. This practice demonstrates the feasibility of a separated architecture. The post states: “Today, we can perform ZK proofs of real-world blocks in blockchains that use WASM as dISA by using a RISC-V-based ZK-VM as the backend.”
The advantage of this separated architecture is flexibility. The delivery ISA should prioritize developer experience, tooling ecosystem, type safety, and maintainability; the proof ISA should prioritize the simplicity and computational efficiency of proof circuits. These two objectives are not always aligned and may even conflict. By separating the two, each can be optimized individually without compromise.
Offchain Labs’ prototype demonstrates this architecture in practice. Developers write smart contracts in familiar languages like Rust or C++, compile them to WASM format, and upload them to the chain. When a zero-knowledge proof is needed, the WASM code is just-in-time compiled to RISC-V, then executed in a RISC-V ZK-VM to generate proofs. This approach preserves WASM’s developer friendliness while leveraging RISC-V’s advantages in proof generation.
Three Main Advantages of a Separated Architecture
Flexibility: The pISA can be swapped out as proof technology evolves, without affecting already deployed on-chain contracts.
Optimization: dISA and pISA can each be optimized for their respective needs, with no need for compromise.
Future-Proofing: When better proof technologies emerge, there is no need for a hard fork of Ethereum L1.
RISC-V May Not Remain Optimal
The team questions whether RISC-V represents the endpoint of zero-knowledge proof virtual machine (ZK-VM) evolution, pointing out that proving mechanisms are rapidly changing. The recent shift from 32-bit RISC-V to 64-bit RISC-V implementations highlights this uncertainty. This transition itself demonstrates that the RISC-V standard is not fixed but constantly evolving.
They warn that locking RISC-V into L1 could trap Ethereum in a particular proving technology just as better alternatives emerge. WASM-based ZK-VMs like Ligero’s Ligetron have already shown that hardware-oriented ISAs may not be able to compete. Ligetron leverages WASM’s structured nature to achieve higher efficiency than RISC-V in certain proof scenarios.
Meanwhile, ZK proof costs have plummeted to about $0.025 per Ethereum block and continue to fall. This figure changes the economics of optimization. The researchers believe that optimization solely for proof efficiency is no longer as important. They write: “Even if L1 attestation requires multiple ZK proofs per block, compared to the gas fees and MEV that block builders can extract from each block, this cost is negligible.”
This argument has significant strategic implications. When proof costs are already negligible, the marginal benefit of further proof efficiency is very small, while the cost of sacrificing developer experience and ecosystem maturity is great. Ethereum L1’s choices should prioritize long-term ecosystem health, not just short-term technical metrics.
Historically, cryptographic technology evolves rapidly. Cryptosystems that were mainstream 10 years ago may be obsolete today, and ZK proof technology is undergoing similar rapid evolution. SNARKs, STARKs, Bulletproofs, Plonk, and other proof systems each have their strengths and weaknesses, and even better options may emerge in the future. If Ethereum L1 locks itself prematurely into a specific proof-friendly architecture, it risks missing out on better technological choices ahead.
WASM’s Structural Advantages and Mature Ecosystem
The team emphasizes WASM’s structured design, which makes code modification and optimization more convenient without breaking existing contracts. WASM’s modular structure allows specific parts of the code to be upgraded or optimized while other parts remain unchanged. This is extremely valuable in smart contracts, as contracts are typically immutable once deployed, but the surrounding execution environment and optimization tools can continuously improve.
In addition, WASM can run efficiently on common hardware, whereas most Ethereum nodes do not run RISC-V CPUs and would require emulation. This practical issue is often overlooked in theoretical discussions. Ethereum’s decentralization depends on broad node participation, with nodes running on a variety of hardware platforms, from high-performance servers to ordinary personal computers. WASM can run efficiently on mainstream architectures like x86 and ARM, while RISC-V requires an extra emulation layer, increasing computational overhead and complexity.
WASM’s verification features ensure type safety and prevent vulnerabilities, and its mature tooling ecosystem has been battle-tested in billions of runtime environments. WASM was originally designed for web browsers, and nearly all mainstream browsers now have built-in WASM support. This means billions of devices are routinely validating WASM’s safety and reliability.
The researchers write: “We believe WASM can serve as an Internet protocol for smart contracts, as the ideal intermediate layer between various source languages used to write smart contracts and the various backends used to execute and verify them.” This vision positions WASM as the “universal language” of the blockchain world, akin to HTTP’s role on the Internet.