feat: sload opcode

[enitrat]

• Implements the sload opcode
• Tests for sload
• Introduces a pop_sba stack method to convert a u256 stack value to StorageBaseAddress upon retrieval
• Tests for pop_sba
• Implements journal methods allowing to retrieve, write, and finalize values
• Tests for journal methods

Pull Request type

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]

beautiful PR! I like the layers of abstraction and the general direction

My main question is:

• do we need local and global changes in journal? My understanding is that having only global_changes is enough,
• we'd call finalize global changes at the end of each execution context (one storage syscall)

=> if the tx reverts, all sstores revert
=> if the tx does not revert, then writing directly from global_changes into storage multiple times at the same slot won't be charged in the L1 calldata, so it's merely a storage syscall cost tradeoff vs. maintaining 2 dicts instead of 1 and doing many dicts writes/accesses between each execution contexts

[Eikix]

can you add logic in machine.revert() to wipe the current local changes?

[Eikix]

Update: after thinking about it for a while, I guess the debate between having local and global vs. only global can be summarized as:

• is it more expensive to hold two dicts and write from one into the other at every sub context finalization
• or is it more expensive to hold just one dict, and write into storage at every sub context finalization

Essentially in my challenge I wonder about the flow:

• just one global change dict
• at every end of sub context: write into storage and clean keys
• inside any context, can use global_changes dict as cache layer
• at the end, in root context, can just write into storage global_changes as if it were any sub context
• if a sub context reverts, then have to clear entries drop keys in the array of key

ERRATUM: this is not so good as in case of sub context reverting, we can't recover the past state of global_changes

OKPM pour local + global

We just need to implement what happens on revert -> clear keys but also overwrite local_changes dict by a fresh empty one

[enitrat]

can you add logic in machine.revert() to wipe the current local changes?

Wouldn't it be for another PR ? I can add a todo

[Eikix]

can you add logic in machine.revert() to wipe the current local changes?

Wouldn't it be for another PR ? I can add a todo

fine with me

[Eikix]

lgtm

[Eikix]

lgtm