add emerald configs

[FletcherMan]

1. Purpose or design rationale of this PR

...

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
  • Added the --override.emeraldtime command-line flag enabling manual specification of the Emerald fork timestamp. Users can now override bundled default settings to customize chain configuration. The override is applied during genesis block initialization across both full nodes and light client implementations.

[coderabbitai]

Walkthrough

This pull request adds support for an EmeraldTime override throughout the codebase—a new CLI flag, configuration field, and integration into the genesis block setup path for both full and light clients, following the existing override patterns.

Changes

Cohort / File(s)	Summary
CLI Flag Definition cmd/utils/flags.go	Adds new exported OverrideEmeraldTimeFlag of type *cli.Uint64Flag with name "override.emeraldtime" to specify Emerald fork timestamp, aligned with existing override flags.
Command-line Integration cmd/geth/chaincmd.go, cmd/geth/main.go	Registers the EmeraldTime flag in the init command's Flags and adds it to the nodeFlags slice for CLI exposure.
Configuration Reading cmd/geth/config.go	Adds logic in makeFullNode to read the EmeraldTime flag and assign its uint64 value to cfg.Eth.OverrideEmeraldTime.
Config Struct & TOML Handling eth/ethconfig/config.go, eth/ethconfig/gen_config.go	Adds new field OverrideEmeraldTime *uint64 to Config struct and updates MarshalTOML/UnmarshalTOML to handle serialization/deserialization.
Backend Integration eth/backend.go, les/client.go	Applies config.OverrideEmeraldTime to chain overrides in both full node and light client initialization before genesis setup.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Highly consistent, repetitive pattern applied across multiple files
• No complex logic, error handling, or control flow changes
• Straightforward field additions and flag wiring following established patterns
• Key areas for verification:
  • Consistency of flag name and usage across all integration points
  • Correct TOML serialization/deserialization in gen_config.go
  • Proper override application in both eth/backend.go and les/client.go

Possibly related PRs

• Add emerald upgrade #216 — Implements Emerald fork support with EmeraldTime override/field additions to genesis and chain configuration.
• feat: override genesis chain config #186 — Adds fork timestamp override support through ChainOverrides, flags, config fields, and SetupGenesisBlockWithOverride integration.

Suggested reviewers

• Web3Jumb0
• curryxbo

Poem

🐰 Emerald sparkles join the chain,
Override flags added, no refrain,
From CLI to genesis, the flow runs true,
Fork timestamp magic, through and through! ✨

Pre-merge checks and finishing touches

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Title check	❓ Inconclusive	The title 'add emerald configs' is vague and does not follow Conventional Commits format specified in PR guidelines. It lacks specificity about what the Emerald configuration entails and does not clearly communicate the main change.	Consider updating the title to follow Conventional Commits format (e.g., 'feat: add EmeraldTime override configuration') to be more specific and informative about the actual changes.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch emerald_patch_1

---

📜 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 5297e55 and bff4939.

📒 Files selected for processing (8)

• cmd/geth/chaincmd.go (2 hunks)
• cmd/geth/config.go (1 hunks)
• cmd/geth/main.go (1 hunks)
• cmd/utils/flags.go (1 hunks)
• eth/backend.go (1 hunks)
• eth/ethconfig/config.go (1 hunks)
• eth/ethconfig/gen_config.go (4 hunks)
• les/client.go (1 hunks)

🧰 Additional context used

🧬 Code graph analysis (3)

cmd/geth/config.go (1)

cmd/utils/flags.go (1)

• OverrideEmeraldTimeFlag (282-285)

cmd/geth/main.go (1)

cmd/utils/flags.go (1)

• OverrideEmeraldTimeFlag (282-285)

cmd/geth/chaincmd.go (1)

cmd/utils/flags.go (1)

• OverrideEmeraldTimeFlag (282-285)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: Analyze (go)

🔇 Additional comments (9)

eth/ethconfig/config.go (1)

224-226: LGTM!

The OverrideEmeraldTime field follows the established pattern for time-based fork overrides, consistent with the existing OverrideMorph203Time and OverrideViridianTime fields.

cmd/utils/flags.go (1)

282-285: LGTM!

The flag definition is consistent with the existing fork override flags. The naming convention follows the established pattern and the usage description is clear.

eth/ethconfig/gen_config.go (1)

68-68: LGTM!

The TOML marshal/unmarshal implementation correctly handles the new OverrideEmeraldTime field in both directions, maintaining consistency with the existing override fields.

Also applies to: 118-118, 171-172, 316-321

cmd/geth/config.go (1)

169-172: LGTM!

The flag handling correctly reads the CLI value and assigns it to the config, following the exact pattern used for other fork time overrides.

cmd/geth/main.go (1)

76-76: LGTM!

The flag is correctly added to the node flags, making it available for CLI usage.

les/client.go (1)

99-101: LGTM!

The light client correctly propagates the OverrideEmeraldTime configuration to the genesis override mechanism, maintaining consistency with the full node implementation.

cmd/geth/chaincmd.go (2)

55-55: LGTM!

The flag is correctly exposed in the init command, allowing genesis initialization with the EmeraldTime override.

---

224-227: LGTM!

The initGenesis function correctly reads the EmeraldTime override flag and applies it to the genesis setup, following the established pattern for fork time overrides.

eth/backend.go (1)

140-142: LGTM!

The backend correctly propagates the OverrideEmeraldTime configuration to the genesis override mechanism, completing the end-to-end integration of the new fork time override.

Warning

There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure.

🔧 golangci-lint (2.5.0)

Error: can't load config: unsupported version of the configuration: "" See https://golangci-lint.run/docs/product/migration-guide for migration instructions
The command is terminated due to an error: can't load config: unsupported version of the configuration: "" See https://golangci-lint.run/docs/product/migration-guide for migration instructions

Tip

📝 Customizable high-level summaries are now available in beta!

You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.

• Provide your own instructions using the high_level_summary_instructions setting.
• Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
• Use high_level_summary_in_walkthrough to move the summary from the description to the walkthrough section.

Example instruction:

"Divide the high-level summary into five sections:

1. 📝 Description — Summarize the main change in 50–60 words, explaining what was done.
2. 📓 References — List relevant issues, discussions, documentation, or related PRs.
3. 📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.
4. 📊 Contributor Summary — Include a Markdown table showing contributions:
   | Contributor | Lines Added | Lines Removed | Files Changed |
5. ✔️ Additional Notes — Add any extra reviewer context.
   Keep each section concise (under 200 words) and use bullet or numbered lists for clarity."

Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.

---

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

_{Comment @coderabbitai help to get the list of available commands and usage tips.}