Zero `max_fee_per_blob_gas` test is ineffective

[marioevz]

Test test_invalid_tx_max_fee_per_blob_gas is passing even when there is an issue in the verification logic as in this commit here: ethereum/go-ethereum@5f39342

The reason is that the state root included in the test is not the same as the one calculated by geth with the faulty verification logic, because the transaction is executed, and t8n, when there is an invalid transaction in the list of transactions, simply skips the execution and outputs an state root as if the transaction was never executed, but this will almost never be the case if there is a faulty verification, and therefore the block will be still rejected, and the test will pass and won't detect the issue.

There are multiple things that we can do to improve this:

• Better check the error that the client returns when the blockchain test is executed, and verify that the client detected the invalid transaction
• Include the test type TransactionTest in execution-spec-tests for this kind of tests, and also StateTest

[marioevz]

PR where this issue was highlighted: ethereum/go-ethereum#28470

[danceratopz]

• Better check the error that the client returns when the blockchain test is executed, and verify that the client detected the invalid transaction

This check could be performed either in:

1. blocktest directly, or
2. In a wrapper to blockest (like consume?) that inspects the fixture for expected exception behavior and checks that this matches the log/stderr output from evm blocktest.

Option 1. is perhaps achievable, but could be tricky, as it requires re-ordering the test execution logic by checking exceptions, if specified in the test, before checking state/transaction roots. This may be out of the question, as some checks which happen within the EVM itself can't simply be re-ordered.

Adding 2. could be a helpful check that gives us more confidence in our tests and assures us that we're not seeing false positives. However, it seems a poor approach to depend on this entirely if the blocktest command can't detect fails directly and requires external tooling.

• Include the test type TransactionTest in execution-spec-tests for this kind of tests, and also StateTest

This seems to be the approach to focus on for invalid txs as we don't need the additional data and checks.

[marioevz]

Running the corrected fixture against faulty-geth and fixed-geth yields an unexpected result (I expected to only see the state root mismatch):

Fixed geth:

########## BAD BLOCK #########
Block: 1 (0x10f6e56581d45416420f2e4b4604fbc843d48d0fde3b48d972d0631975c05c85)
Error: could not apply tx 0 [0x1fa8a76ca36772db403565286e21b752256abfe3fae514e5ab368f705a8910e1]: max fee per blob gas less than block blob gas fee: address 0xa94f5374Fce5edBC8E2a8697C15331677e6EbF0B blobGasFeeCap: 0, blobBaseFee: 1

Faulty geth:

########## BAD BLOCK #########
Block: 1 (0x10f6e56581d45416420f2e4b4604fbc843d48d0fde3b48d972d0631975c05c85)
Error: invalid gas used (remote: 0 local: 21000)

What's happening here is that, since t8n was not able to execute the transaction, it did not "correctly" populate the following fields:

• The state root is incorrect
• The tx root hash is incorrect
• The block gas used is incorrect
• The receipt hash is incorrect

The tx root we can calculate ourselves, but the other three I think it would be very difficult for us to calculate, plus, we can have multiple combinations of these values, depending on how the faulty client executes the faulty block.

I think the core distinction we need to make in the invalid blocks is, instead of only checking the stateroot, was the client able to execute all transactions or not.