docs: evm-machine design doc

[enitrat]

Pull Request type

In this design document, we dive into a refactor of the Kakarot's EVM-Machine implementation, compatible with Cairo's limitations raised in starkware-libs/cairo#4032.
The accepted proposed design will need to:

• Be easily refactorable
• Have a low overhead cost compared to the one originally planned
• Not introduce development complexity in other parts of the code

I believe that the proposed one performs well in all the points mentioned above. Please discuss it extensively!

Please check the type of change your PR introduces:

• Bugfix
• Feature
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no API changes)
• Build-related changes
• Documentation content changes
• Other (please describe):

What is the current behavior?

Resolves: #

What is the new behavior?

Does this introduce a breaking change?

• Yes
• No

[Eikix]

What are the limitations of this approach?

[enitrat]

What are the limitations of this approach?

It's a bit more expensive as we need to track each stack/memory's context-related segment length in a dict instead of as a simple variable.
Also, this imposes a limit on the maximum amount of memory space a context can allocate.

[Eikix]

What are the limitations of this approach?

It's a bit more expensive as we need to track each stack/memory's context-related segment length in a dict instead of as a simple variable.

Also, this imposes a limit on the maximum amount of memory space a context can allocate.

Let's discuss it in our weekly
What is the limit on memory space per context?

[enitrat]

the gas costs required to have a memory containing
125000 words is above the 30M gas limit. We will use this heuristic to bound the
maximum size of the memory to 125000 256-bits words. Therefore, we will bound
the maximum size of the memory to 125000 256-bits words.

[enitrat]

@Eikix If you're okay with it I propose to merge the current design proposal, and to apply any modifications from SW's feedback in a new PR

[enitrat]

@Eikix Reworked this:

• Changes brought to the ExecutionContext docs
• The Storage section has been entirely reworked

[enitrat]

@Eikix Changes applied

[Eikix]

lgtm 🔥

[Eikix]

mb just noticed this PR does not have mentions of "dirtyStorage"?
is dirtyStorage the equivalent of local_changes?
should we modify the other pr #360

[enitrat]

mb just noticed this PR does not have mentions of "dirtyStorage"?
is dirtyStorage the equivalent of local_changes?
should we modify the other pr #360

dirtyStorage is a name that is unique to Geth. For us, it's the combination of local_changes and global_changes.