Support WASM instruction set for Stage 1

[aborg-dev]

This is a tracking issue for all WASM instructions that we need to support to complete Stage 1.

The goal is roughly to support WASM MVP opcodes, but we might delay some that are tricky to support with current ZK processor till Stage 2.

Tasks

Beta Give feedback

1. Support Multiplication and Division in ZKWASM #24
   +0
   
2. Arithmetic operations: add, sub, mul, div, rem
3. Bitwise operations (e.g. i32.shl)
4. Control flow operations: block, loop, if, else, br, br_if
5. Function call operations
6. i32.rotl
7. i32.lt_u
8. i64.extend_i32_u
9. Global variables: global.set, global.get
10. Memory load and store operations (e.g. i64.load, i64.store)

[nagisa]

So one thing that has been floating in my mind is that we're definitely not going to (nor it makes sense to) have support for all and every single one of the WASM/clif-ir instructions in our MVP for stage1. For instance, anything involving floats is an immediate out at the time being (it wouldn’t be too onerous to implement, but it would be a soft float affair and I don’t believe it is a good way to spend our limited time at the moment.)

With that in mind, I think we should have a representative contract that we would use as our MVP test target. This should be something like with integer operations and non-trivial control flow (loops, blocks, function calls etc.) similar to the ft-transfer contract that we had in our benchmarking efforts. I would potentially go with ft-transfer, but unfortunately it doesn’t really have that much integer or control flow in it and would be disproportionally a test of the host function calls rather than regular execution performance.

[nagisa]

memory.size and memory.grow from the list above in particular are instructions I think we can punt on right now, as those don't really have much use in the NEAR ecosystem. They pose interesting challenges for zkasm in particular, but I don't think those challenges need to be solved for Stage 1.

[aborg-dev]

memory.size and memory.grow from the list above in particular are instructions I think we can punt on right now, as those don't really have much use in the NEAR ecosystem. They pose interesting challenges for zkasm in particular, but I don't think those challenges need to be solved for Stage 1.

I'm fine with that, as long as these instructions are not necessary for a few representative performance benchmarks #90. I'll investigate which instructions are used there and report back here with requirements.

[aborg-dev]

We have all the features listed above implemented. For SHA256, we are still missing Global Data Segments and loads from a frame pointer that are tracked in #143.