-
Notifications
You must be signed in to change notification settings - Fork 38
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
Fix selfdestruct for EIP-6780 with non-empty balances #493
Conversation
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.
LGTM, thanks!
@@ -209,6 +211,28 @@ fn process_nonce( | |||
}) | |||
} | |||
|
|||
/// Processes the self destruct for the given account state. | |||
fn process_self_destruct( |
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.
nit: returning an Option is a bit cryptic - could you document what it means?
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.
Also you never return Some(false)
, which feels odd
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.
to be fair I just brought back what had been removed from a previous PR, but I can change it
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.
I believe it's done that way to easily skip serde from serializing None variants, without having to provide a custom fn
to deal with false
values, given that these are 99% of the cases encountered. But I could be wrong.
The issue actually lied in the application of #461, that claimed to change only the native tracer behavior but actually removed the notion of self destructed accounts from jerigon payloads as well.
This was also incorrect, following the EIP specification of still considering as contract creation accounts with non-empty balances.
I've added a new test case from the previously failing payload b20472570 (cf #475).
closes #475