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 24 commits into
base: master
Choose a base branch
from
Draft

params: Config2 #32224

wants to merge 24 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
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