There is an issue with our filling of the account/DEPLOYMENT_NUMBER in the case of undoing an account operations. The main issue is that:
for a given address 0xaddr its DEPLOYMENT_NUMBER is monotonic over time and doesn't get reverted
on account-rows corresponding to undoing operations we always have constraints à la
account/DEPLOYMENT_NUMBER_NEW[i] = account/DEPLOYMENT_NUMBER[i] // <- a 'future undoing' row
we fill the corresponding DEPLOYMENT_NUMBER at the time of the original account operation
but we do not know then what DEPLOYMENT_NUMBER will be the right one at that point in time
Concrete issue
The issue is real in particular for operations that
can be called on an account that is yet to undergo deployment
are revert-sensitive
These instructions include (all variants of) CALL / BALANCE / EXTCODEXXX. Here is a concrete scenario where we may go from a deployment number of 0 to (e.g. 1 but the transition could be, with sufficiently nested REVERT's to any positive deployment number)
// CONTEXT_WILL_REVERT = 1
PUSH20 0xaddr
BALANCE // will have to be reverted (warmth) when the current context reverts
POP
// various pushes
CREATE(2) // deployment happens at address 0xaddr
// a's account/DEPLOYMENT_NUMBER does 0 ↑ 1
// execution of CREATE(2) init code
// ...
// execution halts (successful or not)
// execution of root context resumes
REVERT
Note. The same issue does not arise when writing undoing operations for storage. The deployment number can't change in that setting (and if it does the storage undoing was alredy done before the next deployment.
Solution stub
We require a method to make an account fragment at a specific point in time so that we can extract the correct DEPLOYMENT_STATUS and DEPLOYMENT_NUMBER. In other words we need a
where ??? is a reference to the reverter context or something similar, and maybe a snapshot of the two fields above at that point in time. Concretely to make this smooth we would benefit from being able to have a defer registry like so
deferToChildContextEnd:
register actions to be done at the precise point in time right after the child context terminates and re-enters the current one
deferToRollback
register actions to be done at the precise point in time right after the current context is rolled back
Main point
There is an issue with our filling of the
account/DEPLOYMENT_NUMBERin the case of undoing an account operations. The main issue is that:0xaddritsDEPLOYMENT_NUMBERis monotonic over time and doesn't get revertedDEPLOYMENT_NUMBERat the time of the original account operationDEPLOYMENT_NUMBERwill be the right one at that point in timeConcrete issue
The issue is real in particular for operations that
These instructions include (all variants of)
CALL/BALANCE/EXTCODEXXX. Here is a concrete scenario where we may go from a deployment number of 0 to (e.g. 1 but the transition could be, with sufficiently nested REVERT's to any positive deployment number)Note. The same issue does not arise when writing undoing operations for storage. The deployment number can't change in that setting (and if it does the storage undoing was alredy done before the next deployment.
Solution stub
We require a method to make an account fragment at a specific point in time so that we can extract the correct DEPLOYMENT_STATUS and DEPLOYMENT_NUMBER. In other words we need a
where ??? is a reference to the reverter context or something similar, and maybe a snapshot of the two fields above at that point in time. Concretely to make this smooth we would benefit from being able to have a defer registry like so