feat: override genesis chain config

[ryanmorphl2]

1. Purpose or design rationale of this PR

Override the config of genesis.

2. PR title

Your PR title must follow conventional commits (as we are doing squash merge for each PR), so it must start with one of the following types:

• build: Changes that affect the build system or external dependencies (example scopes: yarn, eslint, typescript)
• ci: Changes to our CI configuration files and scripts (example scopes: vercel, github, cypress)
• docs: Documentation-only changes
• feat: A new feature
• fix: A bug fix
• perf: A code change that improves performance
• refactor: A code change that doesn't fix a bug, or add a feature, or improves performance
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
• test: Adding missing tests or correcting existing tests

3. Deployment tag versioning

Has the version in params/version.go been updated?

• This PR doesn't involve a new deployment, git tag, docker image tag, and it doesn't affect traces
• Yes

4. Breaking change label

Does this PR have the breaking-change label?

• This PR is not a breaking change
• Yes

Summary by CodeRabbit

• New Features

  • Introduced a new command-line flag that lets users manually override the Morph203 fork timestamp during genesis block initialization.
  • Enhanced configuration options to adjust chain initialization parameters and improve error reporting for compatibility issues.

• Tests

  • Expanded test coverage to validate the new timestamp override functionality and ensure accurate compatibility checks during chain setup.

[coderabbitai]

Walkthrough

This pull request introduces a new command-line flag (OverrideMorph203TimeFlag) that permits users to manually override the Morph203 fork timestamp during genesis block initialization. The flag is integrated into several modules: it is parsed in the CLI (in cmd/geth/chaincmd.go, cmd/geth/config.go, cmd/geth/main.go, and cmd/utils/flags.go), and its value is passed to a new genesis block setup function in the core package. Additionally, a new type (ChainOverrides) handles the override in the genesis creation process, with corresponding adjustments in the Ethereum backend, LES client, configuration structures, and compatibility tests.

Changes

File(s)	Change Summary
cmd/geth/chaincmd.go, cmd/geth/config.go, cmd/geth/main.go, cmd/utils/flags.go	Introduced new flag OverrideMorph203TimeFlag to allow manual specification of the Morph203 time override. Integrated flag parsing into node initialization and genesis block setup.
core/genesis.go, core/genesis_test.go	Added new type ChainOverrides with a Morph203Time field and an apply method; updated genesis block setup to use SetupGenesisBlockWithOverride, and renamed compatibility error fields for clarity.
eth/backend.go, les/client.go	Modified backend and LES client genesis initialization to use the new Morph203 override via SetupGenesisBlockWithOverride, and updated block head management to use the renamed parameter (RewindToBlock).
eth/ethconfig/config.go, eth/ethconfig/gen_config.go	Added a new configuration field OverrideMorph203Time (and CheckCircuitCapacity in the gen_config) with proper TOML marshalling/unmarshalling, expanding the Ethereum configuration options.
params/config.go, params/config_test.go	Updated compatibility checks to include an additional timestamp parameter; modified the ConfigCompatError struct fields (renaming and adding timestamp fields) and introduced new test cases for timestamp-based compatibility checks including Morph203Time.

Sequence Diagram(s)

sequenceDiagram
    participant U as User
    participant CLI as Command-Line Interface
    participant Node as Geth Node
    participant Core as Genesis Setup

    U->>CLI: Provide OverrideMorph203Time flag value
    CLI->>Node: Parse CLI arguments (including override)
    Node->>Core: Call SetupGenesisBlockWithOverride (with ChainOverrides)
    Core->>Core: Apply ChainOverrides to genesis config
    Core-->>Node: Return genesis block configuration
    Node-->>U: Initialize genesis block with override

Loading

Poem

I'm a rabbit on a lively run,
Hopping through code under the digital sun.
A new flag in my burrow brings a twist so bright,
Morph203Time now shines in genesis light.
With every override, I smile and delight! 🐇✨

---

📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 30e16ee and b383f15.

📒 Files selected for processing (12)

• cmd/geth/chaincmd.go (2 hunks)
• cmd/geth/config.go (1 hunks)
• cmd/geth/main.go (1 hunks)
• cmd/utils/flags.go (1 hunks)
• core/genesis.go (6 hunks)
• core/genesis_test.go (1 hunks)
• eth/backend.go (2 hunks)
• eth/ethconfig/config.go (1 hunks)
• eth/ethconfig/gen_config.go (4 hunks)
• les/client.go (2 hunks)
• params/config.go (5 hunks)
• params/config_test.go (1 hunks)

🧰 Additional context used

🧬 Code Definitions (8)

cmd/geth/main.go (1)

cmd/utils/flags.go (1)

• OverrideMorph203TimeFlag (270-273)

cmd/geth/config.go (1)

cmd/utils/flags.go (1)

• OverrideMorph203TimeFlag (270-273)

eth/backend.go (1)

core/genesis.go (3)

• ChainOverrides (147-149)
• SetupGenesisBlockWithOverride (179-301)
• Genesis (50-67)

les/client.go (1)

core/genesis.go (3)

• ChainOverrides (147-149)
• SetupGenesisBlockWithOverride (179-301)
• Genesis (50-67)

core/genesis_test.go (1)

core/types/block.go (1)

• NewBlock (270-300)

cmd/geth/chaincmd.go (2)

cmd/utils/flags.go (1)

• OverrideMorph203TimeFlag (270-273)

core/genesis.go (2)

• ChainOverrides (147-149)
• SetupGenesisBlockWithOverride (179-301)

params/config_test.go (1)

params/config.go (5)

• ChainConfig (515-555)
• ConfigCompatError (980-993)
• AllEthashProtocolChanges (331-360)
• NewUint64 (30-30)
• Rules (1059-1065)

core/genesis.go (3)

eth/ethconfig/gen_config.go (2)

• Config (20-67)
• Config (120-167)

eth/ethconfig/config.go (1)

• Config (119-217)

les/client.go (1)

• New (81-208)

🔇 Additional comments (42)

cmd/geth/main.go (1)

74-74: Cleanly adds the new Morph203 time override flag.

The flag is properly added to the nodeFlags array, allowing users to override the Morph203 fork timestamp via CLI. This follows the same pattern as existing override flags like OverrideArrowGlacierFlag.

eth/ethconfig/config.go (1)

215-216: Well-structured addition of the Morph203 time override setting.

The OverrideMorph203Time field is added as a pointer to uint64 with the omitempty TOML tag, which correctly handles the case where no override is specified. This follows the same pattern as the existing OverrideArrowGlacier field (line 207).

cmd/utils/flags.go (1)

270-273: Good implementation of the Morph203 time override flag.

The flag is properly defined with a clear name and descriptive usage text. The implementation as a pointer to cli.Uint64Flag is consistent with other similar override flags in the codebase.

cmd/geth/config.go (1)

161-164: Properly handles Morph203 time override from command line.

The implementation correctly checks if the flag is set and passes the value to the configuration. This follows the same pattern as the existing OverrideArrowGlacier flag handling, maintaining consistency in the codebase.

core/genesis_test.go (1)

133-137: Field name changes improve clarity and consistency.

The field names in ConfigCompatError have been updated to be more explicit about their purpose:

• StoredBlock instead of StoredConfig
• NewBlock instead of NewConfig
• RewindToBlock instead of RewindTo

These changes clarify that the values represent block numbers rather than configuration objects.

eth/backend.go (2)

132-137: Implementation of Morph203 time override is correct.

The code properly initializes a ChainOverrides struct and conditionally sets the Morph203Time field when the configuration includes an override value. This implementation allows for flexible configuration of the genesis block setup while maintaining backward compatibility.

---

209-209: Field name update maintains consistency with ConfigCompatError changes.

The change from compat.RewindTo to compat.RewindToBlock aligns with the field renaming in params.ConfigCompatError, ensuring consistency throughout the codebase.

les/client.go (2)

91-96: Morph203 time override correctly implemented in LES client.

The implementation correctly handles the override in the light client, ensuring that the same configuration capabilities are available in both full and light nodes. This maintains feature parity between the different node types.

---

170-170: Field name update maintains consistency with ConfigCompatError changes.

The change from compat.RewindTo to compat.RewindToBlock aligns with the field renaming in the ConfigCompatError struct, ensuring consistency throughout the codebase.

cmd/geth/chaincmd.go (3)

53-53: LGTM: New flag added for Morph203 time override

The addition of the OverrideMorph203TimeFlag to the initCommand flags makes the new override capability available in the CLI, aligning with the PR objective.

---

212-216: Implementation for the override feature looks good

This code correctly handles the CLI flag by creating a core.ChainOverrides struct and populating the Morph203Time field when specified. The conditional check ensures the override is only applied when explicitly requested by the user.

---

223-223: Function updated to use the new override parameter

The function call has been appropriately updated to use the new SetupGenesisBlockWithOverride function, passing the overrides parameter. This completes the implementation of the override feature in the CLI.

eth/ethconfig/gen_config.go (4)

64-66: LGTM: New configuration fields added

The CheckCircuitCapacity and OverrideMorph203Time fields have been added to the Config struct in the MarshalTOML method. The OverrideMorph203Time field is properly marked with omitempty which is appropriate for an optional override.

---

112-114: LGTM: Fields correctly initialized in encoding structure

The new fields are properly initialized in the encoding structure, copying values from the original Config object.

---

164-166: LGTM: Fields added to UnmarshalTOML struct

The same fields are correctly added to the Config struct in the UnmarshalTOML method with appropriate types and tags.

---

301-309: LGTM: Unmarshal logic for new fields properly implemented

The code that handles the new fields during unmarshalling follows the same pattern as other fields, checking if they are not nil before assigning their values to the actual Config object.

core/genesis.go (8)

145-149: LGTM: New ChainOverrides type with clear documentation

The ChainOverrides struct is well-defined with a clear comment explaining its purpose. Using a pointer to uint64 for Morph203Time allows it to be nil when no override is specified, which is appropriate for an optional configuration override.

---

151-160: LGTM: Well-implemented apply method for chain overrides

The apply method correctly handles the application of overrides to a chain configuration. It has appropriate nil checks and calls CheckConfigForkOrder to ensure the resulting configuration is valid after applying overrides.

---

179-179: LGTM: Function signature updated for overrides

The signature of SetupGenesisBlockWithOverride has been updated to accept a pointer to the new ChainOverrides type, allowing for more flexibility in the types of overrides that can be applied.

---

192-194: LGTM: Overrides correctly applied to new genesis block

The overrides are properly applied to the genesis configuration when creating a new genesis block, with appropriate error handling.

---

256-258: LGTM: Overrides applied to existing chain configuration

Overrides are correctly applied to the existing chain configuration with proper error handling.

---

263-266: LGTM: Overrides applied to stored chain configuration

Overrides are correctly applied to the stored chain configuration with proper error handling.

---

291-297: Ensure compatibility with head header check

The updated head header check and compatibility error handling is a good improvement. Having a check for a nil head header provides better error messages for troubleshooting issues.

---

317-320: LGTM: Added case handling for Morph networks

The configOrDefault method has been updated to include cases for Morph networks, ensuring the appropriate chain configuration is used when the genesis block matches one of these networks.

params/config.go (7)

763-784: Great addition of time-based rewinding logic.
The new parameter time and the fallback to btime vs. bhead neatly handle both block-based and timestamp-based rewinds.

---

952-976: Timestamp-based fork checks look correct.
The helper functions properly mirror the block-based logic for determining invalid fork rescheduling.

---

983-993: New fields in ConfigCompatError align with the expansions for timestamp forks.
Storing both block and timestamp details here appears consistent and clear.

---

995-1015: No issues in block-based rewind logic.
The logic for determining the appropriate block to rewind (or none) remains intact, with proper checks against underflow.

---

1017-1037: Timestamp-based rewind logic looks good.
The approach of using the lesser or nil-less timestamp and subtracting one to rewind is consistent with the block-based approach.

---

1040-1052: Enhanced error representation is clear.
Including block- or timestamp-specific mismatch details in the error message will help users debug configuration incompatibilities promptly.

---

853-917:

✅ Verification successful

Ensure all callers provide correct timestamp values.
The revised checkCompatible method now depends on headTimestamp for Morph203 checks. Please verify that all invocations pass the correct timestamp.

---

🏁 Script executed:

#!/bin/bash
# Locate calls to checkCompatible and ensure the third parameter is set properly.
rg -A 3 "checkCompatible\(.*\)"

Length of output: 643

---

Timestamp parameter usage verified in checkCompatible invocations

The search shows that the call in params/config.go—err := c.checkCompatible(newcfg, bhead, btime)—correctly passes btime as the third parameter. Please confirm that btime indeed represents the proper timestamp value throughout the codebase.

params/config_test.go (11)

20-24: New import for time-based test coverage.
Importing "time" is appropriate for verifying timestamp-based forks.

---

31-34: Struct refactor to separate block and timestamp is logical.
Splitting headBlock and headTimestamp improves clarity of test conditions.

---

37-39: Added test cases for zero vs. current timestamp.
These scenarios ensure no regressions when dealing with time-based forks.

---

41-45: EIP150Block test remains correct with separate block-based logic.
No concerns regarding this scenario.

---

58-67: Homestead block mismatch tests revised appropriately.
Confirming correct detection and rewind logic for older vs. new Homestead blocks.

---

69-78: Combined fork scenario.
Blocks are checked in ascending order, ensuring correct detection of EIP150 changes even when Homestead also differs.

---

97-101: Morph203Time test with earlier head timestamp.
Properly verifies that no error occurs if the head precedes both old and new fork times.

---

103-111: Morph203Time test with head past the new schedule.
Correctly expects an error and an appropriate rewind to one timestamp before the smaller fork time.

---

116-118: CheckCompatible call uses new parameters.
Ensures that both headBlock and headTimestamp are tested for configuration mismatches.

---

123-140: TestConfigRules covers timestamp-based forks.
Replacing the old time-fork test with a broader Rules check is a solid approach for verifying IsMorph203.

---

142-158: New test for timestamp-specific errors.
The thorough coverage of edge cases shows that error messages are correct for nil vs. numeric timestamps and ensures consistent rewinding.

✨ Finishing Touches

• 📝 Generate Docstrings

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai generate docstrings to generate docstrings for this PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai plan to trigger planning for file edits and PR creation.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.