feat(tests): add worst-case block test for 7702 set code

[LouisTsai-Csie]

🗒️ Description

Add blockchain test for EIP-7702 set code transaction.

🔗 Related Issues

Issue #1453

✅ Checklist

• All: Set appropriate labels for the changes.
• All: Considered squashing commits to improve commit history.
• All: Added an entry to CHANGELOG.md.
• All: Considered updating the online docs in the ./docs/ directory.
• Tests: All converted JSON/YML tests from ethereum/tests/tests/static have been assigned @ported_from marker.
• Tests: A PR with removal of converted JSON/YML blockchain tests from ethereum/tests have been opened.
• Tests: Included the type and version of evm t8n tool used to locally execute test cases: e.g., ref with commit hash or geth 1.13.1-stable-3f40e65.
• 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.

[marioevz]

We probably need to pre-set these to an authorization for the reset to do something.

Suggested change

	sender = pre.fund_eoa()
	sender = pre.fund_eoa(delegation=Address(0x1))

[jsign]

Agree, but sounds it would only have effects for the first tx of the list. Starting with the second and further txs, the delegation will be considered a noop, no? So most tx won't be doing any real work.

I wonder if this test should probably:

• Try calculating the maximum number of delegations possible for gas_limit (and remove the iteration_count parameter).
• Create N different accounts as suggested by @marioevz code suggestion.
• Create the N different delegations for target T in a single tx (to save as much intrinsic gas as possible? But not sure this will have a limit reg tx size)
• Let T in the bullet above be parametrizable, i.e.: 0x00 for testing as many resets, and non-0x00 for testing real delegations.

[jsign]

Is this missing a defined parametrization?
(Edit: see also my message below)

[jsign]

Agree, but sounds it would only have effects for the first tx of the list. Starting with the second and further txs, the delegation will be considered a noop, no? So most tx won't be doing any real work.

I wonder if this test should probably:

• Try calculating the maximum number of delegations possible for gas_limit (and remove the iteration_count parameter).
• Create N different accounts as suggested by @marioevz code suggestion.
• Create the N different delegations for target T in a single tx (to save as much intrinsic gas as possible? But not sure this will have a limit reg tx size)
• Let T in the bullet above be parametrizable, i.e.: 0x00 for testing as many resets, and non-0x00 for testing real delegations.

[LouisTsai-Csie]

Some test cases idea:

• 7702 contract code loads
• 7702 signature bombs
• 7702 call bombs
• 7702 tx from delegated account reads code and has to parse the delegation

[CPerezz]

A couple of things since this is something we have explored in BloatNet:

• Contract code loads: The worst case will be achieved by having as many accounts as possible delegating to different addresses with contracts with 24kB (or whatever the max is at the time). Each, triggering a fn that does close to nothing (min gas spenditure).

Anyways, EIP 7702 says:

If a code executing instruction accesses a cold account during the resolution of delegated code, add an additional [EIP-2929](https://eips.ethereum.org/EIPS/eip-2929) COLD_ACCOUNT_READ_COST cost of 2600 gas to the normal cost and add the account to accessed_addresses. Otherwise, assess a WARM_STORAGE_READ_COST cost of 100.

This means we are spending the same as if we called EXTCODESIZE for example. So unsure we can actually get any benefits.
One much cooler idea would be the following: You check BALANCE of the contract. That marks it warm (and BALANCE is cheap). Then, you can do EXTCODESIZE or this and you can read the bytecode much cheaply (this is @jsign 's idea btw that he commented to me some time ago).

• Signature bombs: This scenario is already coded in spamoor (with the worst conditions possible to make as cheap as possible to introduce the max num of delegations in a single block). See: https://github.com/CPerezz/spamoor/pull/1/files#diff-8a6c873f5cc48bd187c1722ae57f8a54ee8fbcf7465d2872594cf6873ab8d3cb