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.

@@                 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     

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

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

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?

Rebased again on top of the forced pushed base.

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

@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.