Long-term L1 execution layer proposal: replace the EVM with RISC-V

Magicians Primordial Soup
,
122

Not sure if I understand the question (what do you mean by “target other back ends”?), but in general our pipeline looks like this:

  1. We use a normal, standard compiler (like rustc, clang, etc.) to build a normal, standard RISC-V ELF file. (Alternatively, we also have a Solidity compiler which uses LLVM to compile bog standard Solidity programs into a RISC-V ELF file).
  2. We take that ELF file and relink it into our custom RISC-V-like bytecode and custom container. This happens offline (on the dev’s machine), and is the part where we apply extra optimizations to the program (like e.g. instruction fusion), simplify the semantics, and in general make it appropriate for on-chain execution.
  3. Then the on-chain VM (which can stay simple because we do most of the work offline when we translate the raw RISC-V into our own bytecode) recompiles the bytecode into the native code and runs it.

Technically our bytecode doesn’t have to be recompiled into the native code - it could also be interpreted, or it could be even be executed to generate a ZK proof, although we haven’t implemented a ZK backend yet. We might someday, and it would be a cool project (if someone wanted to work on a ZK backend for PolkaVM I would gladly merge that PR) but we don’t really have any immediate use for it, since we can get much better and much cheaper scaling without ZK through other means. Compute-wise last time I benchmarked it I can execute the same computation from scratch something like ~20 times in the same time it’d take to verify a single ZK proof of it, nevermind needing to actually generate the proof (which is orders of magnitude more expensive), so there’s literally no point for us go the ZK route.

Technically what Ethereum could do (but won’t due to political reasons) is:

  1. Take our PolkaVM and use it for L1 execution (it’s a general purpose VM and it’s not really specific to any particular chain). This automatically gets you wide toolchain support (you can use almost any language, not just Solidity) and blazing fast near-native execution speed for free, and we have 30+ independent implementations of the VM itself in-progress to make sure the spec is implementable independently.
  2. Write a ZK backend for it and do whatever ZK stuff you need to do. (It should be as fast or faster than current RISC-V ZK VMs.)
  3. Scale down on the ZK use for those parts of the system which now maybe don’t need to use ZK due to better efficiency of the base VM.
3 Likes