core/state: clear out cached state data when reset occurs #27376
Conversation
core/state/statedb.go
Outdated
| if s.snapAccounts != nil { | ||
| account = s.snapAccounts[prev.addrHash] | ||
| delete(s.snapAccounts, prev.addrHash) | ||
| } | ||
| if s.snapStorage != nil { | ||
| storage = s.snapStorage[prev.addrHash] | ||
| delete(s.snapStorage, prev.addrHash) | ||
| } |
There was a problem hiding this comment.
These storages are otherwise only manipulated at transaction boundaries: finalize and commit. It does not seem correct to me to modify them on the fly like this, in the middle of a transaction.
What I most of all want to ensure that we avoid: changing the evm semantics in a way which fixes a theoretical corner-case but causes a break in something which can be triggered in practice.
There was a problem hiding this comment.
snapAccount, snapStorage are essentially equivalent with stateObjectsDestruct.
snapAccount,snapStoragecache the state datastateObjectsDestructcaches the destruction event
Because in the case of ResetAccount, the original one is replaced with the new one,
it's the only correct place to manipulate these three maps, otherwise the destruction
event will be lost.
We can run a full sync to ensure nothing is broken.
|
@karalabe PTAL |
…7376) * core/state: remove cached snap data if reset occurs * core/state: address comment from peter * core/state: skip revert in case data is nil
…hereum#27376)" This reverts commit f60b50e.
…hereum#27376)" This reverts commit f60b50e.
It's a following PR based on #27339
Before byzantium fork, state root will be computed for each transaction. Specifically,
IntermediateRootwill be called at the end of transaction processing. Inside of it,account/storage data will be cached if snapshot is available.
However, whenever account reset occurs, these cached state data should be cleared
out, otherwise we have no way to distinguish whether these data belongs to the
original one or the new one.
This PR fixes it by handling destruction at
CreateAccountfunction.