2./ The comparison of performance is skewed by comparing *interpreted* and *executable* code. Contracts are *executable* (from proof perspective) are in zk-EVMs, not zk-VMs.
The reason zk-VMs are comparable with zk-EVMs is because a lot of workload are precompiles anyway.
The reason zk-VMs are comparable with zk-EVMs is because a lot of workload are precompiles anyway.
3./ In order to remove interpretation overhead but still have some kind of maintainability, it is desirable to build a minimal MMU so that every contract can be compiled to executable.
4./ Execution client then sits on top of it as a kind of an operating system kernel, handling finer details.
In fact, current execution client *is* a kind of such MMU. But arguably one can try to build much smaller, simpler one and for a different ISA.
In fact, current execution client *is* a kind of such MMU. But arguably one can try to build much smaller, simpler one and for a different ISA.
5./ There is no reason to expect that RISC-V is a good ISA architecture for zk proofs. I argue that some kind of restricted jumps (similar to EOF) would, for example, go a long way.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
