Prover tests for empty blocks

[OlivierBBB]

Note

Adds empty-block test scenarios and updates Besu execution tooling to model empty blocks (null txs) and trace correct block ranges; minor Osaka import fix.

• Tests:
  • Add EmptyBlockTests with multiple empty/non-empty block patterns (EENENE, NEEN, NEEE, ENNE, EEEE, EEEN, E) using Besu-backed execution, shared BlockType enum, and a builder helper.
• Testing Tooling:
  • BesuExecutionTools:
    • Support null transactions to represent empty blocks; handle leading/all-empty sequences.
    • Compute correct [firstBlockNumber, finalBlockNumber] for tracing; add precondition/state checks.
    • Keep tracing and execution-proof generation aligned with computed ranges.
  • MultiBlockExecutionEnvironment:
    • Add runWithBesuNode option; when enabled, translate empty blocks to null txs and execute via BesuExecutionTools with MAINNET_TESTCONFIG(fork).
• Osaka Txn:
  • Use TraceOsaka.EIP_7825_TRANSACTION_GAS_LIMIT_CAP import.

^{Written by Cursor Bugbot for commit b477825. This will update automatically on new commits. Configure here.}

[cursor]

Bug: Null Transaction Handling Bug

When oneTxPerBlock is false, the executeTest method attempts to send all transactions without checking if they are null. This leads to a NullPointerException when calling .encoded() on a null transaction, a check that is present in the oneTxPerBlock true path.

 

[cursor]

Bug: Transaction List Nulls Cause Block Number Errors

The firstBlockNumber calculation is off when oneTxPerBlock is true and the transactions list includes nulls. The current logic subtracts numberOfLeadingEmptyBlocks from an already adjusted firstBlockNumber, which can lead to invalid block numbers (like zero or negative) and an incorrect tracing range.

 

[cursor]

Bug: Block Number Calculation Incorrect for Non-Standard Genesis Blocks

When blockNumbers.isEmpty() is true (all transactions are null), firstBlockNumber is set to 1 and finalBlockNumber is set to transactions.size(). This assumes the starting block number is 1, but blocks may start at a different number. The calculation should use the genesis block configuration or track the actual block numbers created, not hardcode 1.

 

[cursor]

Bug: Null Transaction Handling Mismatch

The else branch, which sends all transactions in a single block, doesn't filter out null transactions from the transactions list. This causes a NullPointerException when txs.next() returns null and encoded() is called, unlike the if branch which correctly handles these null entries.

 

[cursor]

Bug: Test Initialization Order Causes Null References

Instance fields (senderKeyPair, receivingAccount, storingNumber, logging, storing, reading) are initialized with references to chainConfig, but chainConfig is only initialized by the test framework after instance field initialization. This will cause these fields to use a null or uninitialized chainConfig, leading to NullPointerException or incorrect bytecode compilation. These fields should either be initialized lazily in a @beforeeach method or moved into the test methods themselves.

 

[amkCha]

You can use the variable testsChain, it's the ChainConfig set in this class when we build the MultiBlockEnv

[amkCha]

I think the way it's going to go, is that when we run our unit tests, this env variable RUN_WITH_BESU_NODE will be at false, as usually we don't run the tests with a besu node. Maybe what can work is to use a property like in ToyExecEnvV2 like so

  @Builder.Default private final Boolean runWithBesuNode = false;

replace the if with if (runWithBesuNode || System.getenv().containsKey("RUN_WITH_BESU_NODE"))

and then when you run a multi block test

final MultiBlockExecutionEnvironment env = builder.build()
              .runWithBesuNode(true)

[OlivierBBB]

Done (I believe)

[amkCha]

Yes, perfect 👌

[amkCha]

Thanks for fixing the daily ref tests !!

[cursor]

Bug: NullPointer on Null Transactions in Else Branch

NullPointerException when oneTxPerBlock is false and transactions list contains null values. The else branch (lines 216-223) attempts to call .encoded() on txs.next() without checking if the transaction is null first. When a null transaction is encountered (representing an empty block), this will throw a NullPointerException. The if branch (lines 207-214) correctly handles null transactions with a null check, but the else branch is missing this protection.

 

[cursor]

Bug: Early Exit Prevents Tracer Initialization

When runWithBesuNode is true, the run() method returns early without initializing the tracer field, leaving it null. Tests that call getHub() after running with Besu node will encounter a NullPointerException since getHub() returns tracer.getHub() and tracer is null.