feat(benchmarks): fix bytecode attack for CALL-like opcodes to work in Osaka

[jsign]

🗒️ Description

This PR fixes the test_xcall benchmarks to work with Osaka. test_xcall has a CALL-like variant of the bytecode attack exploiting unchunkified code, highly relevant for zkVM worst-cases.

I think the solution should feel quite natural — I’ll add some review comments.

I checked this is doing what we want with two independent checks:

1. Hack a bit the Geth codebase to inspect how many distinct bytecodes were accessed during the block execution.
2. Actually running the worst-case block for zkVM execution and inspecting that indeed the witness to be sent to the guest program indeed is blowed up — since bytecode must be part of the input to the guest program.

For 1. and --block-gas-limit 30M, my Geth reports accessing ~260MiB of bytecodes were the upper limit is ~280MiB (30M/2600 — but this isn’t accounting for glue opcodes, intrinsic costs of splitting in txs, etc). So this looks fine.

For 2. and --block-gas-limit 30M, I also confirmed it really blows up the guest program witness, which is prob the best ultimate confirmation this is doing what we wanted. i.e: the json-encoded files have ~524MiB size which makes sense since bytes are hex encoded (with other things).

🔗 Related Issues or PRs

#1695

✅ Checklist

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

  uvx tox -e static

• All: PR title adheres to the repo standard - it will be used as the squash commit message and should start type(scope):.
• All: Set appropriate labels for the changes (only maintainers can apply labels).

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.26%. Comparing base (9e161b6) to head (125cb14).
⚠️ Report is 12 commits behind head on forks/amsterdam.

Additional details and impacted files

@@                 Coverage Diff                 @@
##           forks/amsterdam    #1850      +/-   ##
===================================================
+ Coverage            82.61%   86.26%   +3.64%     
===================================================
  Files                  417      538     +121     
  Lines                26862    34557    +7695     
  Branches              2492     3222     +730     
===================================================
+ Hits                 22193    29809    +7616     
+ Misses                4230     4161      -69     
- Partials               439      587     +148     

Flag	Coverage Δ
unittests	86.26% <ø> (+3.64%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[LouisTsai-Csie]

Huge thanks to the refactor! Leave some comments now but i will add more as i see some failure in execute remote scenario!

[jsign]

@LouisTsai-Csie, addressed all the review comments. I think you wanted to do some remote tests, so LMK if there is any other blocker.

[LouisTsai-Csie]

Please help update the base branch to forks/amsterdam and update the blockchain_test fixture to benchmark_test. Also, please check this comment, thanks!!

#1850 (comment)

[jsign]

Please help update the base branch to forks/amsterdam and update the blockchain_test fixture to benchmark_test. Also, please check this comment, thanks!!

#1850 (comment)

@LouisTsai-Csie, rebased for forks/amsterdam and also changed some things to use tx_gas_limit instead of other calculations as to avoid env.gas_limit.

Reg the blockchain_test, I'm not sure we can use bnechmark_test since in this test we rely on the exclude_full_post_state_in_output=True flag. This flag is used so the post-state isn't include in the fixture (since for this benchmark it would mean putting hundred of megabytes in the fixture). I think this flag isn't available in benchmark_test?

[jochem-brouwer]

Some minor comments, looks very good 😄 👍

[jsign]

Rebased again on top of the forced pushed base.

[LouisTsai-Csie]

Working good for 100M but failing for our 5M CI check. Not sure what's the best way going forward now.

_ test_xcall[fork_Prague-benchmark-gas-value_1M-blockchain_test_engine_x-opcode_CALLCODE] _
[gw4] linux -- Python 3.11.14 /opt/actions-runner/_work/execution-specs/execution-specs/.tox/benchmark/bin/python3
tests/benchmark/compute/instruction/test_system.py:102: in test_xcall
    setup_txs = math.ceil(num_contracts / num_contracts_per_tx)
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
E   ZeroDivisionError: division by zero

[jsign]

@LouisTsai-Csie, yeah, this is tricky.

For Prague they fail, since the tx_gas_limit received as parameter is resolved as 5M (or 1M). A single 24KiB deployment costs more than 5M, which means in both cases the amount of contracts you can deploy is zero.

But for Osaka, both 1M and 5M fill fine because tx_gas_limit is 16M. So the math works out since you have enough room. Although when you do the attack transaction you use 5M (or 1M) and tries to call on "best effort".

I think the way tx_gas_limit is defined in the framework, looks like already assumes in a way that the underlying block gas limit will be at least 16M (for Osaka)? (maybe sounds liek a safe assumption since the 17M number in the EIP was thinking about mainnet when was proposed, not a 1M or 5M chain). And I think you mentioned we can't use env.gas_limit since it might not be a fair representation of remote chains.

I think my conclusion here is (and pushed a commit with this), is if num_contracts_per_tx is zero, then we mark the fixture as skipped. Doing this attack for 1M or 5M targets doesn't sounds like important cases. For example for re-execution the main goal of this attack is to maximize IO on realistic sceanrios, and for zkVMs is to try to blow up the guest program input size (sum of bytecodes) to see if zkVM crash (which they do, but in higher gas limits) and also hashing these bytecodes.

[LouisTsai-Csie]

Thanks for your explanation and the final fix! LGTM