# EPF - Week 5
This week was spent writing the [project proposal](https://github.com/eth-protocol-fellows/cohort-six/pull/179) and doing some work on [the scaffolding](https://github.com/2xic/erigon-risc-v-executable-proof-sourcing/pull/1) for the project.

## Project proposal
Most of the week was spent working on the [project proposal](https://github.com/eth-protocol-fellows/cohort-six/pull/179). It contains the high level approach on how we want to implement this project with a roadmap and discussion of possible challenges.

## Preparing for possible challenges
One of the themes of the possible challenges from the project proposal is incorrect transpilation. Put differently, we need to have good test coverage. I wanted to start this project off with some good foundations in this area.

The way I'm thinking of doing it now, is to leverage the [unicorn engine](https://www.unicorn-engine.org/) as a way to easily emulate the RISC-V without needing to run the full ZkVM pipeline for each test (that would be slow and doesn't give much introspection which makes debugging harder). The idea is to use [EBREAK](https://msyksphinz-self.github.io/riscv-isadoc/#_ebreak) after each transpiled instruction to allow doing a step by step comparison of the stack.

Visualized it would be something like this for the EVM

PUSH1 1  # stack: [1]
PUSH1 1  # stack: [1, 1]
ADD      # stack: [2]

Which will then be transpiled into this (pseudo RISC-V)

// Doing the first PUSH1
addi sp, sp, -8
li t0, 1
sd t0, 0(sp) 
EBREAK          // [1]

// Doing the second PUSH1
addi sp, sp, -8
li t0, 1
sd t0, 0(sp) 
EBREAK          // [1, 1]

// Doing the ADD
ld t0, 0(sp)
addi sp, sp, 8
ld t1, 0(sp)
add t2, t0, t1
sd t0, 0(sp) 
EBREAK          // [2]

So even though we can see there are many more instructions for the RISC-V code and it doesn't really match the EVM equivalence, the way we can do ground truthing of the transpilation would be to cross-check the stacks which we can see is similar. This logic is now already somewhat implemented in the PR, but needs some more love before I merge it.

## Learning from this week
Initially I thought wrapping Erigon with the tracer module would make it easier to iterate for the first few weeks, I still think that is somewhat true, but I had to already now do some [small patches](https://github.com/2xic-speedrun/erigon/compare/v3.0.14...feature/patch-vm) to export some fields that are not exposed from the module. I also don't love the "aesthetics" of the tracer approach as some vm symbols are not exposed and need to be patched. I spent some time wondering if I instead should just patch the [executionFunc](https://github.com/erigontech/erigon/blob/a8c2718e1b9f9824feb99101160ba1431245240a/core/vm/jump_table.go#L38) from within Erigon. I'll probably keep the tracer approach for a few more weeks, but I think we sooner rather than later will move more of this logic inside Erigon instead of wrapping around it.

## Next week
If there are any suggestions to improve my proposal, I want to address those. Other than that, I'm planning to keep working on getting a good testing foundation in place for the project. I'll also try to share an update with my mentor in case he has some feedback.