Instruction set architecture

As the zkVM processor is just a set of constraints by which rows are changed in response to instructions execution, the usual size of instruction set question presents quite unusual possibilities. While it’s true that each new instruction added to the set will bring additional complexity, with a clever column layout, new instructions cost may vary greatly. Parts of constraints, already introduced by previously added instructions can be reused almost freely. Also actual instructions execution time is neglectable compared to proving costs, so more complex instructions can greatly decrease trace size, actually improving performance. On the other hand, bloating the instruction set will still call for bigger instruction size and would definitely increase overall complexity, as even opcode selection itself would become rather complicated.

Our instruction set was originally restricted to very basics of what would make the processor work - RISC core with only arithmetic operations, conditional jump and call/ret. But with the infrastructure needed for this bare set of instructions, we decided to go a little bit further and actually exposed quite a number of instructions, derived from constraint combinations of the basic instruction set. This extended set of instructions seems to reduce strings of instructions, produced by more sophisticated pointer manipulations, but it’s still quite experimental and was introduced only because it had almost no implementation cost.

Also we introduced peripherals - native modules, having a memory-mapped interface and helping to extend the instruction set without bloating instructions itself. From the instruction execution point of view peripherals are free, as processed data just appears in memory, already proven.