## Submission for Paradigm Fellowship

Hey there, I am Manav Darji and this is my submission for the technical question requested in the Paradigm Fellowship application form. I am really hoping to get in!

I've attempted to work on first task i.e. simulating an EVM with tracing. This documents mentions everything about the project implementation, my approach towards implementing some modules, and few things which I though are worth mentioning. I've also attached a video link for the walkthrough and a working demo.

Github: https://github.com/manav2401/goevm

### Overview

The implementation contains the fundamental modules needed for the EVM i.e. stack, memory and storage to begin with. It contains bunch of isolated opcodes (e.g. arithmeric and logical operations) and certain opcodes which interact with state/storage as well. The whole set of opcodes supported can be found [here](https://github.com/manav2401/goevm/blob/main/evm/jump_table.go).

While I can keep on adding more and more opcodes, the interesting and fun part lies in breaking the isolation. As it's a simulation, most of the operations happen in a separate isolated database which is easier to mock. E.g. for opcodes like SLOAD/SSTORE, a simple in-memory storage (like map) can be used. Hence, to try something different, I thought of implementing a storage interface which can be used against any existing EVM chain's database. More on it below in the storage section.

For simplicty, I've only added static gas costs (except memory expansion during MSTORE) and have only accounted for warm storage.

It also supports tracing (which is done simply via logging relevant info). More on it below in the tracing section.

### Storage design

The storage interface defines some generic methods which any storage should implement. There are 2 storage designs supported.

1. A simple storage -- A basic in-memory storage using map for storing account and state.
2. A remote storage -- A storage which is pluggable to any geth based datadir (using level db and hash based scheme).

The simple storage is helpful to perform isolated simulations and testing. The remote storage provides a neat interface to interact with the underlying state of any existing EVM chain (which follows the same structure). To prevent data corruption on any existing chain's db, write functions are not implemented for remote storage. It allows you to read balance, nonce and state data (e.g. contract slots) from any existing chain. Opcodes like SLOAD and BALANCE can read data from remote db.

Hence, the methods like `GetBalance`, and `GetState` when called from opcodes like `BALANCE` or `SLOAD` interacts with the state trie and uses those results in the EVM execution. I think this is one of the crucial highlight of this project.

### Tracing

The implementation contains a very simple tracer which logs the following things for each opcode.
- Stack changes (pre and post executing an opcode)
- Memory changes (including expansion, pre and post executing an opcode)
- Storage changes
- Tracks all the reads for the remote storage
- Track the state-diffs for the in-memory storage (i.e. pre and post execution values)

Some example traces:

### Running the simulation

While the github mentions relevant commands to run, there are majorly 2 simulations which one can run right away.

1. Simple simulation for using the in-memory db. This also uses `SSTORE` to write to the db.
2. Remote simulation using any external db. Some values are hardcoded for simplicity. This prevent any writes (i.e. usage of `SSTORE`).

Both the simulations tries to use different set of opcodes (not all) with operations like arithmetic, logical, bitwise, environment, memory and storage.

### Demo

Demo video (watch at 1.2x / 1.5x): https://www.loom.com/share/432318c00598400b9da2b8a55d292c41?sid=08ce76f8-19a0-4b35-9810-bc3084c8809e

---

Thank you! Hope you liked the project. Looking forward to getting accepted in the fellowship and build something impactful.