Improve ToyAccount management in BytecodeRunner and ToyExecutionEnvironmentV2

[lorenzogentile404]

Currently, when we write tests, we explicitly create accounts in the test itself and then pass them to BytecodeRunner:

public void run(Wei senderBalance, Long gasLimit, List<ToyAccount> additionalAccounts) {
    ...

    List<ToyAccount> accounts = new ArrayList<>();
    accounts.add(senderAccount);
    accounts.add(receiverAccount);
    accounts.addAll(additionalAccounts);

    toyExecutionEnvironmentV2 =
        ToyExecutionEnvironmentV2.builder()
            .transactionProcessingResultValidator(
                TransactionProcessingResultValidator.EMPTY_VALIDATOR)
            .accounts(accounts)
            .zkTracerValidator(zkTracerValidator)
            .transaction(tx)
            .build();
    toyExecutionEnvironmentV2.run();
  }

In this way, the ToyExecutionEnvironment receives the accounts we want to be available and potentially containing some bytecode associated to them.

However, this may be not convenient when the same account is used to send more than one transaction within the same test, as the nonce has to be increased manually in test itself.
Ideally, we want the ToyExecutionEnvironment to take care of it for us. For this reason, we want the test to have the possibility to handle addresses (and potentially bytecode associated to them) only and let the ToyExecutionEnvironment do the rest of the work.

[OlivierBBB]

to handle addresses (and potentially bytecode associated to them) only and let the ToyExecutionEnvironment do the rest of the work.

What you really want is to

• initialize a world using a List<ToyAccount> accounts = List.of(...); with each account defined in terms of an address (or a private key), bytecode, value, nonce etc ... (and why not storage while we're at it ?)
• when defining the transactions only use Addresses to refer to accounts
• have the world deal with everything in between (nonce updates, deployments, balance changes, ...)

To be 100% clear: the initial value of world would only serve to initialize the world. And beyond that we (i.e. test writers) shouldn't have to interact with it any longer.

[lorenzogentile404]

Example of test where the nonce is raised manually:
#1572
test : arithmetization/src/test/java/net/consensys/linea/zktracer/instructionprocessing/createTests/failure/Create.java

[amkCha]

After digging a bit, we will look to add the nonce update at the GeneralStateReferenceTestTools.java level, after Besu MainnetTransactionProcess has executed the transaction associated. The retrieval of the account can be done at that stage too and the transaction can be instanciated with an address at the test level