test(benchmark): implement CREATE2 addressing for bloatnet tests

[gballet]

🗒️ Description

• Add CREATE2 deterministic address calculation to overcome 24KB bytecode limit
• Fix While loop condition to properly iterate through contracts
• Account for memory expansion costs in gas calculations
• Add safety margins (50k gas reserve, 98% utilization) for stability
• Tests now scale to any gas limit without bytecode constraints
• Achieve 98% gas utilization with 10M and 20M gas limits

🔗 Related Issues or PRs

#1986

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

[LouisTsai-Csie]

@CPerezz Thanks for this PR, I review the last commit, for the test_bloatnet_extcodesize_balance test first. If the following suggestion works for you, I could continue review based on the approach.

It deploys many 24kB contracts with unique bytecode, then:
1. Calls BALANCE on all contracts (cold access) to warm them and fill cache
2. Calls EXTCODESIZE on all contracts (warm access) hoping cache evictions force re-reads

Based on the description, I suggest some optimization below. I compare the two versions with the command, using 10M as gas limit:

uv run fill -v tests/benchmark/test_bloatnet.py::test_bloatnet_extcodesize_balance -m benchmark --gas-benchmark-values 10 --clean -s

Based on current implementation, the num_contracts variable is 3454, which equals to the number of operation count, but with some optimization it could increase to 3682. But i am not sure if this implementation still align with the testing scenario for bloatnet, please let me know if something goes wrong here.

Your current approach is (1) create a lot of contract via CREATE2 (2) calling these contract with BALANCE and EXTCODESIZE operation. In step 2, the CREATE2 address is calculated in the attack contract, but since these address are calculated in Step 1 also, we could hardcode these value in the Step 2, thus reducing the cost per iteration.

On the other side, you mention the difficulty of consuming all the gas in the block here. You can pass this value to expected_benchmark_gas_used in blockchain_test, so it would compare the actual gas consumption during execution, and the specified value. No need to consume up to gas_benchmark_value, and no padding is needed. For more explanation, I've posed in our thread in Mattermost, please take a look.

Please let me know what do you think!

[LouisTsai-Csie]

For Hash(pattern), do you expect a keccak256 hashing result? If so, i think this method does not work as expected here. I print out Hash(1) and it turns out to be 0x0000000000000000000000000000000000000000000000000000000000000001.

If this is what you expected, what about simplify this as the following:

deploy_bytecode = Op.STOP + sum(
    (Op.POP(Hash(i)) for i in range(max_contract_size // 4)), Bytecode()
)
deploy_bytecode += Op.JUMPDEST * (max_contract_size - len(deploy_bytecode)) # For padding to max contract size

Although Hash(i) is 32 bytes here, but when pushing to the stack, the immediate bytes would be packed in 1-2 bytes.

PUSH(Hash(0))

1. Hash(0) -> 0x0000000000000000000000000000000000000000000000000000000000000001.
2. PUSH(Hash(0))- > PUSH1 0x01 (1 byte)

PUSH(Hash(1000))

1. Hash(1000) -> 0x00000000000000000000000000000000000000000000000000000000000003E8
2. PUSH(Hash(1000)) -> PUSH2 0x03E8 (2 bytes)

And due to the max contract size limit (0x6000), each iteration could be packed into 4 bytes sequence: PUSH32 values POP

If you want a keccak256-like hashing result, consider something like this (You might need to resolve some typing issue)

deploy_bytecode = Op.STOP + sum(
    (Op.POP(keccak256(i)) for i in range(max_contract_size // len(Op.POP(keccak256(0))))), Bytecode()
)
deploy_bytecode += Op.JUMPDEST * (max_contract_size - len(deploy_bytecode)) # For padding to max contract size

[CPerezz]

e70132b should bring some light on what I'm trying to do with the Hash usage.

If it's not clear still, I can expand more on it.

[LouisTsai-Csie]

I guess your intention here is to make sure all the operation works as expected, no OOG, invalid JUMPDEST or other issue during execution, and the program process until the end.

Using SSTORE is good, but might be too expensive here. What we do now is to calculated the expected usage and pass it to expected_benchmark_gas_used params in blockchain_test.

More explanation can be found in Mattermost:

For instance, if you are benchmarking a block with a 45M gas limit but the execution only consumes 44.9M, then expected_benchmark_gas_used should be set to 44.9M.

This acts as a safeguard to verify the benchmark behaves as intended. For example, if we create a benchmark test using the JUMP operation but the destination is invalid, each transaction would terminate early with an “invalid jump destination” error. In that case, the gas consumed would fall short of what we expected, and the check would catch this problem.

If you remove this SSTORE operation, please also remove the following variable, and update the post storage

# Storage slot for success flag
SUCCESS_FLAG_SLOT = 0
SUCCESS_FLAG_VALUE = 42

[CPerezz]

I'd prefer to avoid using expected benchmark gas used as depending on the gas limit set, it needs to be precisely computed before.

Whereas, with this, we don't have this issue and also:

• We have a nice way to make sure the whole test run correctly and completed execution & state modifications.
• It only accounts for 0.06% of the total gas (in a 10M gas block) so it's negligible.
• Post-state validation passes (empty)

[LouisTsai-Csie]

If the comment above works by hardcoding the address, we no longer need to calculate CREATE2 address, thus no memory expansion needed

[CPerezz]

As mentioned previously. We can't hardcode addresses as this would force us to use CALL chains that would be super deep and consume most of the gas.

The 63/64 Rule:
    - EIP-150 also formalized that CALL operations can only forward 63/64 of remaining gas
    - This prevents deep call stack attacks

Also, on top of that we would have a TON of contract deployments to do that just hold addresses making the tests significantly slower.

[LouisTsai-Csie]

This test run as expected, but I am not very whether this a good approach of using preAlloc. cc @marioevz

[marioevz]

We try to never do pre[address] = account approach because it basically breaks our assumptions and we cannot run it in execute mode.

By the name of the file and test function, I assume running in bloatnet with execute is the goal, so there's a couple of questions:

• Should the factory contract be already in the state of bloatnet?
• Should the contracts deployed by the factory contract also already be deployed in bloatnet before the test starts?

Both cases I feel should be stubbed contracts.

For the factory contract it's already doable and we simply need to add the appropriate label.

For the contracts deployed by the factory contract it's a bit tricky because we: (a) label them all and pre-deploy them to the bloatnet, or (b) find a more automatic way of pre-deploy if these are not already there.

I think this is all pretty new and the discussion is still open on how to handle this!

[CPerezz]

I see the issue.

We can definitely deploy the factory on Bloatnet and hardcode the address here. Though it would be a bit odd. It will be self-contained within this module. So it's not like it pollutes the whole codebase.

I guess this is the best shot we have. But notice that we will need to use stubbed contracts for every single test we do most likely. So we will have a lot of hardcoded addressess.

If that's ok. Then I'm happy to pre-deploy them in Bloatnet and add some pre-test validations that make sure that the factory is available.

Does that work @LouisTsai-Csie @marioevz ?
Otherwise, the alternative is to deploy a factory and all the sub-contracts on each benchmark run (which for bloatnet purposes is benefitial (more load on I/O).

But I'm not sure if that's ok with you guys.

[CPerezz]

From a convo with @gballet :

So my point is: We need to somehow fix this issue. We have various avenues:

1. We move the pre-state filling into the main benchmark body (counts, this will enforce all the deployment for each benchmark which can take a huge amount of time - tons of deployments per benchmark to run -.
2. We generate the pre-state and deploy it in bloatnet and use stubbed contracts as a way to access it. (It's cleaner, but we should just deploy factories, which brigs us again to the deploy problem).
   2.1 We can deploy (all the contracts). But this would mean a lot of hardcoded addresses in our benchmarks. (Maybe not an issue, but any modification will require a re-deployment of the whole stuff).

[CPerezz]

Hey @LouisTsai-Csie thanks for the comments.

In step 2, the CREATE2 address is calculated in the attack contract, but since these address are calculated in Step 1 also, we could hardcode these value in the Step 2, thus reducing the cost per iteration.

As per this, notice that there's a constraint to what you propose which is that a contract is capped at 24kB atm. Thus, we can only fit ~945 addresses in it. Therefore, unless I'm missing something, this should be the best way to do this (otherwise we can have a chain of contracts that calls each one another as a linkedlist, but it's quite complex for the benefit (arround 6%).

[LouisTsai-Csie]

@CPerezz Thanks for clarification, after revisit the suggested changes and re-run the code again, it indeed exceeds the max code size - I did not notice this since it was successful on my computer, but i later realized that our framework does not catch the max code size limit issue for fill command. I am adding sanity check in a separate PR now. Additionally, for the expected_benchmark_gas_used in your comment , i could try to loose the rule for similar scenario.

Since this PR is still based on previous PR, so i could not help you run the CI, but I hope you could verify the test locally through uv run fill -v tests/benchmark/test_bloatnet.py::test_bloatnet_extcodesize_balance -m benchmark --clean --gas-benchmark-values 10, to check if there is anything wrong with the current implementation.