Add extra storage read & write benchmark cases

[LouisTsai-Csie]

SSTORE -> #1774 @LouisTsai-Csie

• Add a variant in the existing test that warms all storage slots via the Access List (AL).
• In the existing benchmark PR, include different contract sizes: just created, small, medium, and XEN-sized.
• Perform SLOAD on 1–200 storage positions before writing to each of them, covering all possible transition variants.
• Deploy multiple contracts (1–5 parametrized instances) and perform cold storage writes on each.

SLOAD -> #1769 @jochem-brouwer

• Repeated SLOAD on the same slot range (1–200) for four contract sizes (just created, small, medium, XEN), both with and without Access List, and with existing vs non-existing values.
• SLOAD on non-existing keys (1–200) for the same four sizes, tested with and without Access List.
• SLOAD on existing keys (1–200) for the same four sizes, tested with and without Access List.

[jochem-brouwer]

I'm adding the SLOAD cases here. (Will link PR)

I think there is a feature being added to execution-specs which is a num_opcodes CLI argument - right? We should add this functionality directly to these tests, and also to the linked PR in the description (https://github.com/ethereum/execution-specs/pull/1734/files). I am building on top of that PR.

[jochem-brouwer]

There is a practical problem with the small/big contracts here which we should address. I might raise an issue which we have discussed before here, if that is the case, sorry about this.

It is about this: pointing to:

(just created, small, medium, XEN)

contract sizes.

I just realized (and maybe someone else realized this before) we can use 7702 for this. Here is the takeaway:

We can setup 4 7702 accounts with the desired storage size

If we then want to execute specific code or operations which need to run on different sized contracts (so (just created, small, medium, XEN) sizes) we instead delegate the 7702 account to that code and then run the test.

Here is the gotcha: in the cleanup phase of the test, iff the test used an SSTORE this SSTOREs should be reset to the original values, such that we can re-run tests on top of exactly the same contract in storage. (This applies to situations where we run tests using uv run execute i.e. against remote networks, and where we cannot pre-fill / reset contracts in the genesis).

We can also create a setup script which creates these specific EOAs with this storage. Note that we can thus change code of 7702-delegated accounts, but we will not reset the storage there - we can thus reuse this storage.

[jochem-brouwer]

The practical problem with using 7702 is that we cannot use pre.deploy_contract where we already set storage. We should instead use some kind of pointer (a stubbed address?) to instead use that storage. (This is a concern for the testing framework / writing the test itself, and the differences between uv run fill and uv run execute).

Let me know if something is unclear 😄 👍