Skip to content

params: Config2 #32224

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

Draft
wants to merge 32 commits into
base: master
Choose a base branch
from
Draft

params: Config2 #32224

wants to merge 32 commits into from

Conversation

fjl
Copy link
Contributor

@fjl fjl commented Jul 16, 2025

This is a refactoring of the fork configuration system. The design goals for this change are as follows:

  • Forks

    • Eth mainnet forks and their progression should be defined in one place only. At the moment, adding a new fork requires lots of additions in package params, defining new methods, updating validation rules, etc. I wanted
      to make this simpler, so that ideally a new enum value has to be added and that's it.
    • I want to enable defining forks in other packages. For certain changes, such as RIP implementations, a fork should be more like a feature flag that can be enabled.
    • For eth mainnet, forks are ordered by their activation, but a key insight from this change is that defining a total order among forks is not possible generally. So in the new system, we have to explicitly define dependencies between forks, establishing partial order. Our reliance on total fork order needs to be lessened across the codebase, to ensure we only depend on the partial ordering as defined.
    • Some forks are optional. This includes difficulty adjustment forks from before the merge, and the new BPO forks. The defined dependencies reflect this.
    • Finally, it should be possible to make one fork auto-activate another. This is to handle certain special cases, e.g. Constantinople/Petersburg activation, and to allow for extensibility in L2 downstream repositories, which have their own forks and progression but want to activate upstream forks as well.
  • Parameters

    • Some protocol parameters can be set through the chain config. With the proposed system, parameters are
      handled by a global registry, and can be implemented across different packages. For example, the EIP-1559 configuration can be implemented in the eip1559 package, where the config is ultimately used.
    • Parameters have a validation function which is called during config validation.
    • There should also be a way to handle chain compatibility checks for each parameter. For example, we should check that blob schedule configuration is not modified in an incompatible way.
  • Config/Rules object

    • The chain configuration should be immutable. Note it may not be possible to ensure this for parameters, since they can have an arbitrary Go type.
    • 'Rules' are a way to resolve all active forks at a given block. The existing Rules implementation has some special cases related to the merge and Verkle. I want to remove these. Rules should just be a map[Fork]bool.

@fjl fjl marked this pull request as draft July 16, 2025 13:04
@lightclient lightclient mentioned this pull request Jul 18, 2025
fjl added 8 commits August 4, 2025 16:56
It's not great to call scheduleAtTime so many times. The function is much more
expensive now since it has to establish the fork order every time.
A later refactoring needs to turn it around to compute the order only once.
Copy link
Member

@lightclient lightclient left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is looking really good, just catching up a bit on the changes. Saw a TODO for the TTD and BPOs for checking compatible - are there other major todo items?


var ConfigParam = params.Define(params.T[Config]{
Name: "clique",
Optional: true, // optional says
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

missing part of the comment here?

param map[int]any
}

func NewConfig2(activations Activations, param ...ParamValue) *Config2 {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

doc

return ok
}

// SetActivations returns a new configuration with the given forks activated.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// SetActivations returns a new configuration with the given forks activated.
// SetActivations returns a new configuration with the given forks activations.

I think it should say "activations" since the way it currently reads is that that it will make the new config have the passed in forks be active.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This method is a little confusing to me in general though, it seems like it should set the forks for the current Config2 object (even overwriting the existing) but instead it returns a new object that has both the existing activations and the new activations.

Comment on lines +28 to +33
func (cfg *Config2) Rules(blockNum uint64, blockTime uint64) Rules2 {
r := Rules2{
active: make(map[forks.Fork]bool, len(cfg.activation)),
}
return r
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like this still needs to fill in the active map?

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.

2 participants