-
Notifications
You must be signed in to change notification settings - Fork 788
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
Common: Add new isActivatedEIP() method #1125
Conversation
@@ -4,7 +4,7 @@ | |||
"comment": "Simple subroutines for the EVM", | |||
"url": "https://eips.ethereum.org/EIPS/eip-2315", | |||
"status": "Draft", | |||
"minimumHardfork": "berlin", | |||
"minimumHardfork": "istanbul", |
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 fix, EIP can technically be applied earlier than berlin
, this would otherwise not allow to instantiate the VM with istanbul and just activate this single EIP.
Codecov Report
Flags with carried forward coverage won't be shown. Click here to find out more. |
return true | ||
} | ||
for (const hfChanges of HARDFORK_CHANGES) { | ||
const hf = hfChanges[1] |
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.
Had to do a double take here, this is a bit hard to read (but is due to how these hardforks are exposed). But yeah, this looks fine.
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.
Yup, great!
This PR adds a new method
Common.isActivatedEIP()
. This method is meant to replace manual calls likethis._vm._common.eips().includes(2929)
(see e.g. here) which will break once such an EIP moves to a HF.After merging all these calls - particularly in the VM - should be replaced with the functionality from here.
Note that the current terminology around the term "active" in the
Common
library is very unfortunate (I once introduced myself). Other methods likeactiveHardforks()
take "active" as "being a part of the chain" - if activated or not. I therefor for now used the terminology "activated" to differentiate here at least a bit. I will add a note to the major-release-note planning, these old "active" names should be replaced with something less ambiguous.For now all this should work out.