fix: BlockCapturer for Created Accounts #1291
Conversation
The block capturer had an issue capturing accounts which were created during the execution of the conflation being captured. The problematic scenario required an account to exist at the beginning of the conflation, but which was then the subject of a CREATE/CREATE2 contract creation. This is permitted in certain situations, such as when the account only has a balance (but no storage). To resolve this case, we have to be a little more careful when creating storage snapshots. Specifically, when an account only partially exists (i.e. has no storage, but only a balance) then we never create storage snapshots. Finally, this also adds a debugging mode to ReplayExecutionEnvironment to assist debugging the BlockCapturer.
DavePearce
requested review from
letypequividelespoubelles
and removed request for
letypequividelespoubelles
arithmetization/src/main/java/net/consensys/linea/blockcapture/snapshots/StorageSnapshot.java
Show resolved
Hide resolved
| // for accounts which are created *during* the conflation. Such accounts may have technically | ||
| // existed before the conflation (e.g. they had a non-zero balance) but could still have been | ||
| // "created" during the conflation. In such case, this snapshot would be simply assigning 0x0 | ||
| // to the given storage locations. However, we don't want to create a storage snapshot in such |
There was a problem hiding this comment.
Does taking a storage snapshot insert a storage value ?
There was a problem hiding this comment.
Also, at least according to the current EYP, storage does not matter when it comes to checking the possibility of doing a CREATE2
There was a problem hiding this comment.
Also, at least according to the current EYP
Yeah, but at the end of the day, we are not measuring against the EYP. We are comparing against execution on MAINNET using BESU. What I'm looking at is what BESU does. If that deviates from the EYP ... well, we still have to follow BESU.
However, I agree that it does seem wierd and I can follow up with BESU to see why they do it that way (or even it could be a bug).
There was a problem hiding this comment.
Does taking a storage snapshot insert a storage value ?
Yes, in the replay environment it does. See ReplayExecutionEnvironment.initWorld(). One option might be to drop StorageSnapshots which assign 0x0 at the beginning of the conflation. It has the same effect. Maybe you prefer this?
There was a problem hiding this comment.
But does taking a storage snapshot change the world state ? If so that is a massive problem.
There was a problem hiding this comment.
In any case we do want to define storage snapshots even if the target account has empty storage or doesn't even exist yet. Simply because it's possible in Ethereum and we will want to test that, see #1205, but it should be side-effect free
| } | ||
| } | ||
|
|
||
| private static boolean accountExists(final Account account) { |
There was a problem hiding this comment.
AFAIU the EYP defines for an account
-
existenceas existence in the state, i.e.$\sigma[a] \neq \varnothing$ -
EMPTYas having nontrivial nonce, balance or code -
DEADas either not existing or being empty - prohibited from being deployed at as existing and either having nontrivial nonce, code or storage
along with EIP-7610
So maybe a more accurate name would be accountMayNotBeDeployedAt / deploymentIsProhibitedAt or so.
DavePearce
deleted the
fix/issue-1289/fix-blockcapturer-handling-of-contract-creation
branch
The block capturer had an issue capturing accounts which were created during the execution of the conflation being captured. The problematic scenario required an account to exist at the beginning of the conflation, but which was then the subject of a CREATE/CREATE2 contract creation. This is permitted in certain situations, such as when the account only has a balance (but no storage).
To resolve this case, we have to be a little more careful when creating storage snapshots. Specifically, when an account only partially exists (i.e. has no storage, but only a balance) then we never create storage snapshots.
Finally, this also adds a debugging mode to ReplayExecutionEnvironment to assist debugging the BlockCapturer.