Skip to content

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

Merged
merged 5 commits into from
Dec 15, 2024
Merged

Conversation

OlivierBBB
Copy link
Collaborator

No description provided.

@OlivierBBB OlivierBBB self-assigned this Dec 15, 2024
if (isDeployment) {
selfdestructorNew = selfdestructorNew.deploymentStatus(false);
selfdestructorNew.code(Bytecode.EMPTY);
}
Copy link
Collaborator Author

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;
Copy link
Collaborator Author

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

@OlivierBBB OlivierBBB merged commit dfebb97 into arith-dev Dec 15, 2024
7 checks passed
@OlivierBBB OlivierBBB deleted the SELFDESTRUCT-various-fixes branch December 15, 2024 08:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant