# EPF - Week 6
This week we got the project proposal merged into the [main repo](https://github.com/eth-protocol-fellows/cohort-six/blob/master/projects/erigon_riscv_proof_sourcing.md). We also had the scaffolding that we started on last week [merged](https://github.com/2xic/erigon-risc-v-executable-proof-sourcing/pull/1). This includes a simple EVM bytecode program where we add two one byte numbers.

PUSH1 0x42
PUSH1 0x41
ADD 

Not only does this scaffolding provide a way for us to test that the code we transpiled can be executed in the zkvm environment, but also a way for making sure that the transpilation works as expected with the [Unicorn + EBREAK stack snapshot idea](https://hackmd.io/uazVXv0_RMClls9_ksptSA#Preparing-for-possible-challenges) mentioned last week. With this in place, we should be able to focus more on implementing opcodes for the next few weeks.

## OpenVm has 256-bit optimized opcodes
I originally opened an issue against OpenVM to ask about supporting [vector extensions](https://github.com/openvm-org/openvm/issues/1909), but then learned that OpenVM actually has [optimized arithmetic opcodes](https://github.com/openvm-org/openvm/blob/ca36de3803213da664b03d111801ab903d55e360/docs/specs/RISCV.md#bigint-extension) for this, which I somehow missed in earlier weeks. This is great as it helps reduce the risk of additional overhead for us emulating the 256-bit arithmetic of the EVM.

## Opcodes to implement for next week
For the current phase of the project, we want to be able to run basic contracts by the end of it. I took a simple counter contract and looked at what opcodes it uses.

pragma solidity ^0.8.26;

contract Counter {
    uint256 public count;

    function get() public view returns (uint256) {
        return count;
    }

    function inc() public {
        count += 1;
    }

    function dec() public {
        count -= 1;
    }
}

Compile with the following

solc --no-cbor-metadata --optimize --via-ir --opcodes 

We get the following opcode distribution by aggregating the results of the previous command

| OPCODE | COUNT | IMPLEMENTED |
| ------------ | ----- | ----------- |
| PUSH1 | 36 | [X] |
| PUSH0 | 18 | |
| JUMPI | 16 | |
| DUP1 | 9 | |
| JUMPDEST | 8 | |
| DUP2 | 7 | |
| MSTORE | 6 | |
| ADD | 6 | [X] |
| SWAP1 | 5 | |
| REVERT | 5 | |
| PUSH4 | 5 | |
| NOT | 5 | |
| CALLVALUE | 5 | |
| CALLDATASIZE | 5 | |
| SLT | 4 | |
| SLOAD | 4 | |
| EQ | 4 | |
| RETURN | 3 | |
| STOP | 2 | [X] |
| SSTORE | 2 | |
| GT | 2 | |
| SWAP2 | 1 | |
| SHR | 1 | |
| SHL | 1 | |
| POP | 1 | |
| MLOAD | 1 | |
| LT | 1 | |
| ISZERO | 1 | |
| INVALID | 1 | |
| DUP3 | 1 | |
| CODECOPY | 1 | |
| CALLDATALOAD | 1 | |

So now we have a good idea of opcodes that we should implement and in what order. I think the goal for the following week should be to implement most of them, especially the low hanging ones (`EQ`, `SHL`, `SHR`, `PUSH_N`, etc). Some of the more complex ones like `SSTORE`, `SLOAD` and `CALLDATALOAD` might not happen before week 8.