nonce changed is not reverted in journal if fail due to insufficient balance

[gftea]

Problem

In pre_execution.rs, between L144 nad L181

1. The nonce is incremented by not recorded in journal
   https://github.com/bluealloy/revm/blob/main/crates/handler/src/pre_execution.rs#L144

2. Before record the nonce changed in journal, if any error return between, the nonce will not be reverted because journal has no record of nonce change.
   https://github.com/bluealloy/revm/blob/main/crates/handler/src/pre_execution.rs#L181

[rakita]

This is indeed the bug, as you said max_balance_spending can return error and journal entry will not be made. Fortunately, this does not affect reth or any use case of validation.

Use case where this would be problematic is with executing multiple tx and, after failure, trying to execute them again without clearing the journal.

[gftea]

@rakita is there plan to release a fix on release v26? or only fixed in later major release?

Note that this bug will cause significant issues, even clear the journal at failures.

let's assuming the failure tx at the middle called badtx, and 1st half txs before badtx and 2nd half txs after badtx are valid.

Executing a block of txs, due to journal cleared after badtx failure, it lost the state changes of previous half of txs, and if continue to execute 2nd half of txs in the block, the state will not be correct if there are inter dependencies between these 2 halves of txs.

Examles:

• if there are 2 duplicate transfer tx in same block, one at 1st half, another at 2nd half, they will both succeed to produce outputs and state changes in same block because journal is cleared due to badtx in the middle, which call result in confusion in upper application assumiing 2nd duplicate one should fail

• if there are 2 txs from same account with expected nonce N, and 2nd one with N+1, executing N succeed, but N+1 will fail because journal is clear due to badtx before executing 2nd one, so account state still expect nonce N and reject N+1, which is also incorrect behavior.

Wonder why reth is not a problem?

[rakita]

@gftea changes between v26 and v27.1.0 are not that big and would recommend bumping revm to the newest version. Reth still doesn't use transact_many APIs.