onlydustxyz / imhotep Goto Github PK

Add the ability to parse the opcodes defined in the 20s section of the yellow paper, in order to decode the instruction and call the correct function.

https://ethereum.github.io/yellowpaper/paper.pdf
https://ethereum.org/en/developers/docs/evm/opcodes/

Add the ability to parse the opcodes defined in the 30s section of the yellow paper, in order to decode the instruction and call the correct function.

https://ethereum.github.io/yellowpaper/paper.pdf
https://ethereum.org/en/developers/docs/evm/opcodes/

Add the ability to parse the opcodes defined in the a0s section of the yellow paper, in order to decode the instruction and call the correct function.

https://ethereum.github.io/yellowpaper/paper.pdf
https://ethereum.org/en/developers/docs/evm/opcodes/

Add the ability to parse the opcodes defined in the 80s section of the yellow paper, in order to decode the instruction and call the correct function.

https://ethereum.github.io/yellowpaper/paper.pdf
https://ethereum.org/en/developers/docs/evm/opcodes/

Add the ability to parse the opcodes defined in the 0s section of the yellow paper, in order to decode the instruction and call the correct function.

https://ethereum.github.io/yellowpaper/paper.pdf
https://ethereum.org/en/developers/docs/evm/opcodes/

Context

EVM bytecode often starts with conditional jumps based on the function selector given as an input.
Since this is the beginning of the bytecode, we need to be able to execute it to test the rest of the opcodes implementations.

Goal

Have an in-memory program counter, passed to functions as an implicit argument. This counter is not incremented yet, this will be done when implementing the execution loop for the stack machine.
We also need to implement the JUMP opcode that updates the program counter value.

Expectations

• 100% test covered code
• program counter lives in memory
• program counter is given as an implicit argument to the function executing the JUMP opcode, altered and returned there

Context

This is the first implementation of the EVM memory.
The goal is to be able to mimic a random-access memory, addressed by offset.

Goal

Have two internal functions corresponding to MSTORE and MLOAD. The store should take as an argument a value to store as well as an offset, the load function should take an offset to load from.
Don't use the stack implementation at this point unless #15 is done.

Expectations

• 100% test covered code
• do not use storage var, too expensive and persistent, memory is volatile
• work with 32-byte values

Add the ability to parse the opcodes defined in the f0s section of the yellow paper, in order to decode the instruction and call the correct function.

https://ethereum.github.io/yellowpaper/paper.pdf
https://ethereum.org/en/developers/docs/evm/opcodes/

Context

In order to code a stack machine, we need, well, a stack!
The way I see it is to have an in-memory object that gets passed as an implicit argument to opcode functions.

Goal

The goal is to implement the stack. For this, make it work with a simple opcode function, let's say the 01 addition opcode.
If the function is already present in the code thanks to #1, directly use it, otherwise create it it's no big deal.

Expectations

I expect the implemented stack to be usable for more opcode functions than the addition, so don't just put 2 numbers in memory returning the sum :)
Do write some protostar unit tests for this, this is the real backbone for the whole project, we cannot afford bugs on this part.
Important: work with 32-bytes slots! And the max stack size is 1024 in the EVM.

Create a dict to map the different opcodes to functions so that they can be called when reading a contract bytecode.

Functions can then be called with from starkware.cairo.common.invoke import invoke and from starkware.cairo.common.registers import get_label_location

Add some Github action workflows to run the tests and the build for every pull requests.

Add the ability to parse the opcodes defined in the 10s section of the yellow paper, in order to decode the instruction and call the correct function.

https://ethereum.github.io/yellowpaper/paper.pdf
https://ethereum.org/en/developers/docs/evm/opcodes/

Context

pc points at the instruction currently being processed by the EVM, and is represented as a byte offset in the bytecode.

Goal

Have an internal function to read the current opcode at a given pc value. Keep in mind that some opcodes are expressed on several bytes, because they hold a value alongside with the actual opcode value. PUSH1 is one of these for example.

Expectations

• have a function that can be called with a pc value and returns the opcode at the given offset
• this function should be usable by #30 to check that the opcode at a jump destination is actually a JUMPDEST
• find how to deal with variable size of opcodes decoding, one byte for JUMPDEST for example, and two bytes for PUSH1

Add the ability to parse the opcodes defined in the 40s section of the yellow paper, in order to decode the instruction and call the correct function.

https://ethereum.github.io/yellowpaper/paper.pdf
https://ethereum.org/en/developers/docs/evm/opcodes/

Context

This is the first implementation of the EVM storage.
The goal is to be able to store some data in a persistent storage.

Goal

Have two internal functions corresponding to SSTORE and SLOAD. The store should take as an argument a key and a value to store, the load function should take a key to load.
Don't use the stack implementation at this point unless #15 is done.

Expectations

• 100% test covered code
• do use storage var
• store 32 bytes keys and 32 bytes values

Add the ability to parse the opcodes defined in the 90s section of the yellow paper, in order to decode the instruction and call the correct function.

https://ethereum.github.io/yellowpaper/paper.pdf
https://ethereum.org/en/developers/docs/evm/opcodes/

Add the ability to parse the opcodes defined in the 50s section of the yellow paper, in order to decode the instruction and call the correct function.

https://ethereum.github.io/yellowpaper/paper.pdf
https://ethereum.org/en/developers/docs/evm/opcodes/

Context

We want to be progressive with what the interpreter can execute. Luckily for us, EVM bytecode is split between different opcodes, we can then have a incremental support of these opcodes.

Goal

With all the first pieces of the interpreter put together, we will be able to start to execute some EVM bytecode. We need to prepare the first tests we will do: write some simplistic bytecode based on a very reduced set of opcodes. Namely JUMP, ADD, MSTORE for example.

Expectations

• the bytecode is executable by an existing EVM implementation
• it only relies on opcodes that are planned to be supported in this project, either in existing issues or create the missing issues for the opcode you need – be smart, don't add issues for complicated opcodes
• have a test providing this bytecode as a constructor argument if #19 is done

Add the ability to parse the opcodes defined in the 60s & 70s section of the yellow paper, in order to decode the instruction and call the correct function.

https://ethereum.github.io/yellowpaper/paper.pdf
https://ethereum.org/en/developers/docs/evm/opcodes/

Context

Every Imhotep contract will embed an EVM bytecode interpreter. We need to have the bytecode stored somewhere in order to be able to execute it.

Goal

A first and naive approach is to store it in the contract itself, as a storage var. We provide the bytecode at construction time, and we store it.
A more advanced approach, out of the scope of this issue, would be to directly embed the EVM bytecode into the Starknet contract assembly, as if it was "hardcoded" on the Cairo code.

Expectations

• Be able to provide some bytecode in the constructor
• Have a function to read it from the storage