-
Notifications
You must be signed in to change notification settings - Fork 809
Move EIP Integration to Common #869
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
…thod in Common, changed param() semantics, updated EIP2537 VM integration
Codecov Report
Flags with carried forward coverage won't be shown. Click here to find out more. |
Ah, too many VM API tests still failing, will look into that later. |
…ge.json test:state script skipping some tests on selected operating systems
Fixed that remaining failing tests. This is now ready for review. 😄 |
docs: add closing backtick
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, good stuff!
Follow-up on #856 and #863
This PR moves EIP integration from the VM to Common to be able to spawn EIP implementations across different libraries touched (as currently possible along hardfork lines). Upon this base integration it updates the EIP2537 integration in the VM.
The Common integration is hopefully somewhat future proof. I already added an additional check for
minimumHardfork
requirements where Common initialization will throw if not met (EIP2537 is currently set to chainstart, let me know if this is too low for some reasons).Not yet integrated is a possible EIP dependency, e.g. when one EIP depends on one or several others. This could be implemented by adding a parameter
EIPdependencies
or the like to theEIP*.json
files. Since this comes with some mild extra complexity - e.g. on the param() functionality - I didn't want to integrate directly and eventually overload the PR. Think this can be added once this case occurs.I also decided to change the semantics of the
param()
function and add changed demarcation lines to the existingparamByEIP()
and a newly addedparamByHardfork()
function.param()
removes thehardfork
parameter and is now the function which just "does the right thing" [tm] - which means it either takes the parameter from the latest hardfork or - if present - from an EIP set. If an EIP is set and contains the parameter, this setting always takes precedence (which I think makes sense and would be expected e.g. on the VM instantiated with a certain HF and an additional EIP changing gas costs e.g.).paramByEIP()
andparamByHardfork()
can now be used to explicitly demand for an EIP respectively HF-specific parameter.This makes use of the
param()
function - especially in the VM - completely transparent and avoids code such as:Instead the current
param()
usage can stay completely "as is" and the parameter is chosen correctly based on the chain setup in Common.