I have been a long-term riscv enthusiast. I have 4 riscv devices, that I toy with and use some as home servers, some as compilation targets to check that work, and as a testbed for my work on zkvms. I was in the room when r55 was created, I helped building it, and I came up with the name (I won’t tell you where it comes from, it’s a stupid pun).
Disclaimer even though it’s adjacent to the current debate on EOF v. riscv, this is not primarily about this. It’s a honest evaluation of the relevance of investing energy into riscv at this point in time.
In my view, there are a few reasons not to replace the EVM with riscv, let alone in the sort term:
- One thing that is obvious when tinkering, is that the riscv ecosystem isn’t production-ready: linkers are deadly slow, library support is drearily wanting so very few things compile, and there is no network effect since very few projects even bother building riscv releases.
- There isn’t only one riscv, there’s many flavors. There’s the choice between 32 bytes and 64 bytes. There are extensions to the instruction set architecture (ISA) to support memory management, floating points, etc… The modularity is great, but all these extensions can be confusing. Compilers typically support only one or two targets, and more often than not, it’s not the one that is needed. For example, go only compiles to riscv64gc but most zkvms target riscv32imc. We could easily spend a year trying to decide which extensions we want.
- The riscv hardware itself is still very, very slow: it’s much faster to emulate the evm on a fast amd64 processor than run native code on a riscv processor[*]
- I hear some zkvms are moving away from riscv and either using WASM (e.g. powdr) or developing their own ISA. From what I gather, riscv isn’t that zk-friendly either. It’s definitely better than EVM because the word size is smaller, but it’s possible to do much better. If zkvms are the endgame, enshrining riscv now is probably a bad idea.
TLDR I don’t think it’s a good idea to rush into making such a big change at this moment.
I do love riscv and I want a riscv-enabled Ethereum. I believe the better route, would be that of an execution engine. My opinion is that riscv should come as part of the native rollup roadmap, as a secondary execution engine, rather than a replacement for the EVM. This would make the transition smoother, as the engine could be maintained independently.
[*] I’m aware that there exist some Chinese boards that have much better performance, but they’re currently unavailable for purchase, and the listed price is bonkers.