feat(vm): Memory variable

[marioevz]

🗒️ Description

Introduces the MemoryVariable abstraction to make contracts more readable when there's heavy use of the EVM memory as variable storage location.

To use, simply declare a variable with an unique offset that is not used by any other variable, and then the variable can be used in-place to read the value from memory:

v = MemoryVariable(128)

bytecode = Op.ADD(v, Op.CALLDATASIZE())

The previous example is equivalent to:

bytecode = Op.ADD(Op.MLOAD(offset=128), Op.CALLDATASIZE())

The variable also contains methods to generate bytecode to modify the variable in memory.

v = MemoryVariable(128)

bytecode = (
    v.store(0xff)
    + v.add(1)
    + v.return_value()
)

The previous example is equivalent to:

bytecode = (
    Op.MSTORE(offset=128, value=0xff)
    + Op.MSTORE(offset=128, value=Op.ADD(Op.MLOAD(offset=128), 1))
    + Op.RETURN(offset=128, size=32)
)

🔗 Related Issues

✅ Checklist

• All: Set appropriate labels for the changes.
• All: Considered squashing commits to improve commit history.
• All: Added an entry to CHANGELOG.md.
• All: Considered updating the online docs in the ./docs/ directory.
• Tests: All converted JSON/YML tests from ethereum/tests have been added to converted-ethereum-tests.txt.
• Tests: A PR with removal of converted JSON/YML tests from ethereum/tests have been opened.
• Tests: Included the type and version of evm t8n tool used to locally execute test cases: e.g., ref with commit hash or geth 1.13.1-stable-3f40e65.
• Tests: Ran mkdocs serve locally and verified the auto-generated docs for new tests in the Test Case Reference are correctly formatted.
• Tests: For PRs implementing a missed test case, update the post-mortem document to add an entry the list.

[marioevz]

@winsvega I thought of this when reading the code to make_gas_hash_contract and I thought that the hardest part of following the logic was mentally tracking the memory offsets and what they meant, so I modified the python code in that function to use this to see if it makes it more readable.

Let me know what you think.

[winsvega]

To be honest I read plain evm opcodes much better. The fact that I don't know what's going on in this optimisations makes me go back and forth in defenitions.

Let me read it again tomorrow

[winsvega]

I prefer not to subfunc the code for readability

[winsvega]

This makes it less readable

[winsvega]

I was thinking the other night. maybe it will be even better for readability if Op will support memory variables?
so you can call it like

call(gas, address, balance,    input_var,  output_var) 
add(variable_name,  variable_name)
add(variable_name, value) 

[winsvega]

32, -1 magic numbers?

[marioevz]

It was 63 before, we were putting it in the last byte of the variable.
So the offset, plus its size (32), minus the one byte.

[winsvega]

I think it can be made more readable.
maybe Op.Mstore(var, value) can be supported?

but the most important. is to have some unit test for this logic.
to check that before and after refactoring it perfroms the same result.

and if you find it usefull it can be moved to a global namespace so we can reuse it in other tests.