In a sense you are correct, a JIT will always suffer from JIT bomb. And yes, it will really be ideal that a singlepass compiler be used in a blockchain environment. LLVM and cranelift both suffer from the bombing issue.
However, I do want to provide my insights in 2 directions:
- Let me just say that I do believe there is a huge gap between our initial single-pass CKB VM AOT (/github.com/nervosnetwork/ckb-vm-aot) and the LLVM-based AOT (xuejie.space/2022_09_08_a_journey_to_the_limit/). The first one is a naive attempt modeling after an interpreter, while the latter one uses an architecture that matches x64 native code more closely. I do believe it is possible that we can take the architecture in the LLVM-based AOT, but instead use a singlepass compiler design that translates RISC-V to native code in linear time. It is true that such a design might not achieve the performance number from the LLVM-based AOT, but my bet is that it will be much better than our original CKB VM AOT. So I would doubt the claim that “your existing single-pass CKB VM AOT is probably already the best that can be done”. A typical RISC-V binary already contains many close-to-the-metal optimizations done by compilers, which is quite different from EVM binaries. All we need to do here, is a way to match RISC-V instructions to x64 instructions in a overhead-free way.
- This argument does not apply to Ethereum, but just want to provide a complete pictures in our design: these days blockchains really come in all shapes. While for a L1 blockchain, singlepass makes a lot of sense, everyday we see L2 blockchains or even other L1 blockchains that are happy with a JIT based architecture. Our belief is that the LLVM-based CKB-VM AOT can perfectly suit those environments, while at L1(in both CKB and Ethereum), I do agree a singlepass compiler might be the right way to go.
RISC-V is good, but also if someone does native x86_64 (eBPF!?), then it will work good as well.
Now it’s time to share some stories behind our original choice of RISC-V:
Back in 2018 - 2019 when we first designed CKB-VM, there are already other ISAs that are like RISC-V, some are even simpler and easier to implement than RISC-V. One can also argue that eBPF falls in this category. In a way, we can argue that any native ISA(just to be precise, personally, I don’t consider EVM or WASM to be native ISAs) could be a good choice, and all the techniques used in one ISA, can always be ported to another. We end up with RISC-V due to several reasons:
- Simpler ISAs do have fewer instructions and are easier to implement. But there is actually always a threshold you need to meet to efficiently express all cryptographic algorithms. I remember there was one time that EVM does not have bit-shifting operations, and it takes a lot of gases for heavy bitwise computations. This works as a good example that you want the ISAs to be not too simple nor too complex. Even if we add 64-bit integer types to EVM today, you will still need to add a considerable amount of operations(not just add/sub/mul) to make math-heavy programs performant enough. Another such example is: CKB-VM actually started out as a 32-bit RISC-V machine for simplicity. But as we build more programs on CKB-VM, it is clear to us that the programs could benefit a lot in performance with 64-bit instructions. On the other hand, almost all moderm machines run on 64-bit CPUs, and it would really be a waste of resources if we only allow 32-bit operations: to a modern CPU, both a 32-bit add and a 64-bit add finishes in one cycle in the ideal case. eBPF, to me also falls in this category, I would encourage one to compare standard eBPF instructions (/www.ietf.org/archive/id/draft-thaler-bpf-isa-00.html) to RISC-V Bitmap instructions(/github.com/riscv/riscv-bitmanip). I do understand it might not be fair comparing eBPF core instruction set to a RISC-V extension, but note that all RISC-V CPUs in the future will already support bitmap instructions(/riscv.org/riscv-news/2024/10/risc-v-announces-ratification-of-the-rva23-profile-standard/), so in a way it is no longer an extension, but part of the standard.
- Another part of the story is that we don’t want to keep maintaining a fork of compiler toolchain for our ISA of choice. A major goal of CKB-VM, is that it shall be possible to build CKB-VM programs with standard off-the-shell compiler suites without any patches. And back at the time, it really seemed that RISC-V has caught the most momentum. Today, I think it’s safe to say we have made the right choice: tons of devices ship with RISC-V cores inside(/riscv.org/wp-content/uploads/2024/12/Tue1100_Nvidia_RISCV_Story_V2.pdf), the support for RISC-V in LLVM, Rust and many compiler suits has caught up. To me, RISC-V is no longer a weird ISA, but one of the most widely use ISAs in the whole computer industry. I think blockchains can also benefit from the share ecosystem.
So those are why we want to bet on RISC-V: the ecosystem is already big enough, it is also similar enough to x64 / arm64 underneath, so I do believe we can build more performant singlepass translation compiler, compared to higher level solutions such as EVM or WASM.