## EPF - Week 8 This week was spent sharing/discussing updates with my mentor. In addition I wanted to integrate the support for 256-bit arithmetics which I thought would be a quick thing after last weeks research, but turned out to take up all of my time, fun times. ## Discussions with mentor I shared some of the work I had done recently and was asking for some ideas / feedback on what would make most sense for implementing opcodes interacting with state. This resulted in a discussion on what is even considered a sufficient proof and how some of these answers are tackled by other proposals like [native rollups](https://ethresear.ch/t/native-rollups-superpowers-from-l1-execution/21517). Mostly as I thought passing in state as constants in the assembly would be "cheating", but that is also what would in practice happen when providing traces to the execute opcode. This requires more thinking on my part, but I hope to include a small section on this with one of the following updates. ## 256-bit support So I had already something working from [last week](https://hackmd.io/v3eLjX7eQxGbzxOYvcvmTw#Int256U256-support) for the zkVM side. However, since I'm using a separate architecture for testing with Unicorn to make it easier to make sure that opcodes are implemented correctly, it caused a lot of headaches. **TLDR**: many gotchas with the assembler and how Unicorn accepted the input without me easily noticing that something went wrong. ---- First of all, I learned the hard way that OpenVM correctly does use the optimized opcodes, however this was done in a nonobvious way by running `RUSTFLAGS="--emit=asm -C debuginfo=0" cargo openvm build` I saw that it would generate `zkvm_u256_wrapping_add_impl` which would map to the [bigint extensions](https://github.com/openvm-org/openvm/blob/ca36de3803213da664b03d111801ab903d55e360/extensions/bigint/guest/src/externs.rs#L8) and I saw that as the following from the assembly output as well. ```assembly zkvm_u256_wrapping_add_impl: #APP .insn r 11, 5, 0, a0, a1, a2 #NO_APP ret ``` This works great for the OpenVM toolchain as it knows how to use that instruction, but Unicorn doesn't and it failed in a non obvious way and required me to do quite some debugging. One bigger annoyance is that I hoped I could just change the target of the OpenVM code to build for `riscv32im-unknown-none-elf` instead of `riscv32im-risc0-zkvm-elf` (custom extension used by OpenVM), but that also was an adventure which turned out to be unsuccessful. Alright, I thought, I can just split out the library to a separate Rust module and have a compiler flag and then use `RUSTFLAGS="--emit=asm -C debuginfo=0"` to allow me to re-link the code and use the `.include` directive. All reasonable, but I completely forgot that I was using `riscv64-linux-gnu-as` which is just an assembler and doesn't link any of the code and the lack of linkage of the included files caused Unicorn to be stuck in a weird loop and I once again started debugging silly problems. Then when looking at all of the linking needed, I just thought it would be easier to have some of it be hardcoded. So yeah, we now have a [PR that does work](https://github.com/2xic/erigon-risc-v-executable-proof-sourcing/pull/3), but I don't love the layout here as it involves a bit more handcrafted assembly than I would like and the different codepaths between Unicorn and OpenVM which make our testing infra a bit less elegant. Probably need some more work for it to be merged. ## Check-in with the roadmap So we now have ~2 weeks left before the second part of the roadmap should be done. We still have some opcodes left before we are able to run the first [hello world contract](https://hackmd.io/rPta9aOqTmKauiLOh7rPYw#Opcodes-to-implement-for-next-week), but I think those should be possible to land either next week or the week after. ## Next week We should get the 256-bit support over the finish line and then we should also get (most of) the state interaction opcodes implemented. We probably won't run the [hello world contract](https://hackmd.io/rPta9aOqTmKauiLOh7rPYw#Opcodes-to-implement-for-next-week) next week, but most of the opcodes and pieces should be in place.