-
Notifications
You must be signed in to change notification settings - Fork 48
Various SELFDESTRUCT
related fixes
#1661
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
if (isDeployment) { | ||
selfdestructorNew = selfdestructorNew.deploymentStatus(false); | ||
selfdestructorNew.code(Bytecode.EMPTY); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unexceptional SELFDESTRUCT
's in deployment contexts trigger an empty deployment. Thus we reset the byte code (from init code to Bytes.EMPTY
.)
There is a subtle point with selt-targeting SELFDESTRUCT's: for the two "doing" account-rows the HUB_STAMP remains the same. We therefore cannot use the following definition markedForSelfDestruct = hubStamp > selfDestructTime since the second time we inspect the account, this time as the "recipient", the flag ought to be true. Instead we must differentiate according to the DOM_STAMP which reads - row 1: hubStamp * MULTIPLIER___DOM_SUB_STAMPS + 0 - row 2: hubStamp * MULTIPLIER___DOM_SUB_STAMPS + 1 This is what we fix here
@@ -173,7 +174,8 @@ public void resolvePostTransaction( | |||
new EphemeralAccount(oldState.address(), oldState.deploymentNumber()); | |||
if (effectiveSelfDestructMap.containsKey(ephemeralAccount)) { | |||
final int selfDestructTime = effectiveSelfDestructMap.get(ephemeralAccount); | |||
markedForSelfDestruct = hubStamp > selfDestructTime; | |||
markedForSelfDestruct = | |||
domSubStampsSubFragment.domStamp() > MULTIPLIER___DOM_SUB_STAMPS * selfDestructTime; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a subtle point with respect to self-targeting SELFDESTRUCT
's. For the two "doing" account-rows the HUB_STAMP
remains the same. We therefore cannot use the following definition
markedForSelfDestruct = hubStamp > selfDestructTime; // won't work on the 2nd row
markedForSelfDestructNew = hubStamp >= selfDestructTime;
since the second time we inspect the account, this time as the "recipient", the flag ought to be true
yet the parameters of this equation haven't changed. Instead we now differentiate according to the DOM_STAMP
.
markedForSelfDestruct = domSubStampsSubFragment.domStamp() > MULTIPLIER___DOM_SUB_STAMPS * selfDestructTime;
markedForSelfDestructNew = hubStamp >= selfDestructTime;
This achieves the following result, for
// self-targeting SELFDESTRUCT's
- row 1: hubStamp * MULTIPLIER___DOM_SUB_STAMPS + 0 => markedForSelfDestruct ≡ false
- row 2: hubStamp * MULTIPLIER___DOM_SUB_STAMPS + 1 => markedForSelfDestruct ≡ true
This is what we fix here
No description provided.