Fix reference tests failing for `JournaledUpdater` and improve BAL compatibility
Because JournaledUpdater shares a single accounts journal across frames, parentUpdater.getTouchedAccounts() currently returns the union of all accounts touched by the child frames. Although the caller can infer which frame created the touched account based on undoMark and filter accordingly, these semantics
- are different from
StackedUpdater's (making the shared interface incoherent), and - unnecessarily offload complexity to the client of
JournaledUpdater.
Moreover, currently, JournaledUpdater#createAccount creates an account in the root updater immediately on updater.createAccount(), even before a commit. This behavior is
- different from the
StackedUpdater, and is - arguably an unexpected side-effect (which is not accounted for properly in case of a revert?).
Finally, JournaledAccount#get returns the latest version of the JournaledAccount across the entire chain of updaters, instead of returning the account in the latest state it was modified into by that specific updater.
This PR reworks JournaledUpdater so it
- keeps deletions and touched semantics coherent across frames by introducing a per-frame tracking of touched accounts, and
- defers account creation in the root updater until commit,
-
getmethod returns an immutable snapshot of the account corresponding to the modifications made in the updater (linear history, i.e. no "updater forking" and no modifications to the parent after creating child, is assumed).
Since the current block-level access list implementation relies on accurate tracking of touched accounts across nested frames and reverts and updater-specific view of account modifications, this PR is a step towards compatibility of BALs with JournaledUpdater. However, the behavior of getUpdatedStorage, which BAL construction relies on, is still different between UpdateTrackingAccount and JournaledAccount.
Additionally, this PR changes MainnetTransactionProcessor so that it applies the "empty account rule" from EIP-158 only in case the transaction processing was successful. This makes sure that empty accounts are not cleared incorrectly if the transaction processing failed - not doing so results in failing ripeMdAccountShouldNotBeDeletedWhenEmptyAndTouchedTransactionFails for JournaledUpdater, because it doesn't delete accounts on reverts, only "undoes" them to a previous state (which for an empty account may get pruned).
These changes make all the reference tests pass for JournaledUpdater (whereas they are failing currently), including pre-shanghai and post-shanghai empty account clearing behavior, thus getting us closer towards making the JournaledUpdater a viable complete replacement for StackedUpdater.
NOTE: This PR doesn't yet fix the mismatch in traces between updaters. This is mainly because JournaledAccount#getUpdatedStorage behaves differently from UpdateTrackingAccount#getUpdatedStorage - it contains modifications made by ancestor updaters.
This pr is stale because it has been open for 30 days with no activity.
sorry for the delay on this, can you rebase?