feat(tests): add first few single-opcode test for state access in BloatNet

[gballet]

🗒️ Description

Add a test required as part of the BloatNet effort. This is the

🔗 Related Issues or PRs

Not an issue, but a test plan is described here.

✅ Checklist

• All: Ran fast tox checks to avoid unnecessary CI fails, see also Code Standards and Enabling Pre-commit Checks:

  uvx --with=tox-uv tox -e lint,typecheck,spellcheck,markdownlint

• All: PR title adheres to the repo standard - it will be used as the squash commit message and should start type(scope):.
• All: Considered adding an entry to CHANGELOG.md.
• All: Considered updating the online docs in the ./docs/ directory.
• All: Set appropriate labels for the changes (only maintainers can apply labels).
• 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.
• Ported Tests: All converted JSON/YML tests from ethereum/tests or tests/static have been assigned @ported_from marker.

[LouisTsai-Csie]

Hello @gballet ! Thanks for adding this case.

This is the issue tracker for bloatnet test cases, could you please help me (1) add the PR to the issue tracker PR description (like this) (2) link this PR to the issue, this would help us better track the progress, thank you!

For benchmark test, we now add new cases under tests/benchmark, and I think test_worst_stateful_opcodes.py best fit in your test.

I also add some review below, please feel free to let me know if you have any issue! If you want some reference for benchmark test, maybe you can take a look at this This is a similar case for this benchmark! You can take a look at this structure!

[gballet]

Hey @LouisTsai-Csie thanks for the feedback.

This is the issue tracker for bloatnet test cases, could you please help me (1) add the PR to the issue tracker PR description (like this) (2) link this PR to the issue, this would help us better track the progress, thank you!

I tried to do this, but this looks like it's very involved. I did my best effort but since I don't know what you're expecting, and also that I don't have all the time in the world, I'll leave it in your court to comment on that. #2064

For benchmark test, we now add new cases under tests/benchmark, and I think test_worst_stateful_opcodes.py best fit in your test.

if I do that, how do I run the test? it seems to ignore them after I moved it to the directory. I have pushed it to this PR for your consideration.

I also add some review below, please feel free to let me know if you have any issue! If you want some reference for benchmark test, maybe you can take a look at this This is a similar case for this benchmark! You can take a look at this structure!

Thanks for the reference.

[LouisTsai-Csie]

@gballet Appologies. I forgot to link the issue tracker for you. We've created an issue tracker based on your documentation.

I help you link this PR to the SSTORE — Fill block with SSTORE(0 → 1) to maximize new storage slot creation, please let me know if this does not fit in the category.

Also, it would be great if you can help me review if there is anything missing / wrong in our issue tracker!

[gballet]

I'll need to have a closer look, but it seems fine as a first pass. Do you know what the problem is with moving my file to benchmarks?

[LouisTsai-Csie]

Our documentation is incomplete (I will fix them ASAP), for running the test, you will need to add a flag -m benchmark to run the test under the benchmark/ folder. By default, these tests are ignored to avoid some overhead in the CI/release process

This is the command on our documentation:

fill -v tests/benchmark/test_worst_blocks.py::test_block_full_of_ether_transfers --fork Osaka

But I would add some flag to run it:

uv run fill -v tests/benchmark/test_worst_blocks.py::test_block_full_of_ether_transfers --fork Osaka -m benchmark --clean

• uv run: we use uv as package manager
• -m benchmark: We need this flag or benchmark test will be ignored by default
• --clean: you will need this if you already fill test before.

Please let me know if there is anything unclear to you!

[fselmo]

Hey @gballet. I did a first pass at this strictly just from setup. I didn't dig into the actual test case to make sure it's doing what we want it to do. I am going to take a deeper look at the logic.

[fselmo]

I just wanted to add a bit more context on the gas_benchmark_value. This allows us to run something like:

uv run fill --fork=Prague -m benchmark --gas-benchmark-values 1,10,30,45,100,150 --clean -k bloatnet

This allows us to test against the different gas limit values specified for the block, not transaction gas cap (1 = 1 Mgas). I am looking a bit deeper into the PR next but wanted to provide some better context.

[jsign]

We already have covered cold and warm SSTORE/SLOAD with same and different values.

Are these tests different in some way?

[fselmo]

Hmm yeah, good observation. The biggest question I suppose is whether those worst case scenarios are the same as the ones in the bloatnet doc here? If they are, maybe creating a marker on existing relevant tests, so we don't have to redefine them, would be a good approach. Then, instead of trying to run only the tests in this file, we could use a marker like -m bloatnet and if we mark those existing, relevant, param cases with this marker, they get included in all the tests you want to run. We could then mark this whole file (test_bloatnet.py) with the appropriate marker for your use so that you get all the test cases relevant to you in one command, whether they are defined here or elsewhere.

Just a thought.

[gballet]

Let's not conflate two different things together, the objectives are clearly different:

• BloatNet looks for the performance of regular execution
• the zk benchmarks are benchmarking zkevms, a widely different environment

Adding an extra coupling here is causing more work for no benefit, since these tests are maintained by different sets of people.

Regarding the worst case, the tests are doing different things since the code itself is different. The goal of the bloatnet test it to measure the sole performance of SSTORE in client, whereas when I read the zkvm-specific code, it is doing extra stuff like jumps. It's normal, you wouldn't be able to load so much code as in our test inside a zkvm. But we can.

[jsign]

@gballet, the tests in benchmark are not specific to zkvms. (They are even used for PerfNet).

The test I linked are executing blocks where the full gas limit is used to do cold or warm reads, or to write slots to existent or non-existent storage slots. There's nothing specific to zkvms there, thus why I ask how these tests are different -- mainly to avoid duplication or explain better what different variant is trying to be benchmarked.

[marioevz]

This needs to be addressed before merging!

[gballet]

I consider it has already been addressed by my first comment: it's not the same bytecode, not the same objectives (worst case vs perf), and not the same constraints. Ignacio's tests might not be specific to zkvms, but we do need something specific for us.

[LouisTsai-Csie]

There is some refactoring for the code, please help update them, thanks!

Let's wait for the answer of the execute mode for bloatnet scenario.

[marioevz]

LGTM, just one comment that was making the test fail when using small --gas-benchmark-values values.