refactor: update bloatnet benchmark cases

[LouisTsai-Csie]

Background

The fill command creates the full state by generating a genesis file containing all accounts and contracts. In contrast, the execute command connects to a client on given network and sends txs to deploy the required contracts and accounts.

For bloatnet, the state and contracts can be extremely large, making fill operation infeasible. In this case, using execute with stubs is a better approach (see docs). All required contracts in bloatnet can be deployed with a seed, and by reusing the same seed and stubbed contracts, the tests remain reproducible.

Description

Bloatnet-related tests were first introduced in PRs ethereum/execution-spec-tests#2040 and ethereum/execution-spec-tests#2090. While PR ethereum/execution-spec-tests#2090 included a deployment script for the CREATE2 factory and other contracts. It would be better to split this functionality into a separate PR to follow the EEST framework.

The goal is to explore the existing framework and identify the best way to integrate deployment functionality, for example, by adding a specific CLI tool or extending the execute command. The current source script is here, and here

Proposed Solution

1. Add a new deploy_create2_targets method for pre_alloc

cc @jochem-brouwer @CPerezz

[jochem-brouwer]

I am not 100% sure if this is the intended use, but I would indeed suggest to use a fixed CREATE2 factory. To deploy this you would use "Nick's method" (https://medium.com/patronum-labs/nicks-method-ethereum-keyless-execution-168a6659479c), this should target a tx-0 type transaction without EIP-155 replay protection. The reason for this is that this is chain-agnostic so you can deploy this on any chain. The caveat is that although the pkey of this account is unknown (we just construct a valid signature but with some constructed values (Nick's method)), this fixes the params (otherwise the sender changes, and thus also the CREATE2 factory address), in particular this fixes the gas price which could be problematic on some chains (for instance, it is lower than the base fee and the tx can thus not be included).

For the pre-deployment (and the specifics of this CREATE2 factory) one would thus send the initcode to the contract, as well as the seed(s).

For the pre-deployment to be used here, we thus need to verify that all contracts are deployed. We can do so, we can "just" check every contract address which is supposed to have code. If it does not have code, then deploy the contract, otherwise skip the deployment because it is already there.

So deploy_create2_targets would need initcode, and seeds (which is a list of seeds to use). Note that changing the initcode, but not changing the seeds, will change the addresses which the CREATE2 factory deploys (one can thus be sure that an address created via CREATE2 by a particular contract has thus been initialized by a specific initcode).

If something is unclear or needs some further explanation let me know 😄 👍

It is indeed necessary, especially for live networks, to deploy these contracts once and not redeploy those for each test, because this is indeed infeasible for certain tests. (The tests which thus target the same contracts should thus indeed use this new pre_deploy method so that we can skip this unnecessary re-deployment)

[LouisTsai-Csie]

Thanks @jochem-brouwer , i like this idea!