[MegaRedHand]

🗒️ Description / Motivation

Our built-in Sepolia config is eth-clients/sepolia's metadata/config.yaml byte for byte, but two upstream changes since the copy had not been picked up:

• eth-clients/sepolia#130: schedule a 200M gas limit at the Glamsterdam upgrade.
• eth-clients/sepolia#120: set the TERMINAL_BLOCK_HASH override Sepolia's merge used.

What Changed

bin/ethlambda/assets/sepolia/config.yaml is copied again from eth-clients/sepolia at 7b1b9d9 (main today; the file last changed in ddd2eb06):

Key	Before	After
TERMINAL_BLOCK_HASH	0x00…00	0xd07cce97…a37bc1
TERMINAL_BLOCK_HASH_ACTIVATION_EPOCH	18446744073709551615	3599
GAS_LIMIT_SCHEDULE	absent	200M gas at epoch 353024 (GLOAS_FORK_EPOCH)

bin/ethlambda/src/main.rs: the comment on first_config_difference's transition group said every shipped network leaves these keys at their defaults, which Sepolia no longer does. It now gives the reason they are left out regardless.

bootstrap_nodes.yaml already matches upstream.

Correctness / Behavior Guarantees

Key	Effect
TERMINAL_BLOCK_HASH + activation epoch	Only validate_merge_block reads them, and only for the merge transition block, which Sepolia passed in 2022. /eth/v1/config/spec now reports the published override instead of the zero hash
GAS_LIMIT_SCHEDULE	Not a Config field, so it is listed in the ignored-keys warning at startup, next to the Gloas keys already there

Existing Sepolia data directories still resume: first_config_difference leaves the transition keys out, and a resume that passes writes the file's config over the stored one (Store::replace_config).

Tests Added / Run

No new tests: nothing pins Sepolia's transition keys.

cargo fmt --all --check
cargo test -p ethlambda --profile release-fast --bins

✅ Verification Checklist

• Ran make fmt — clean
• Ran make lint (clippy with -D warnings) — not run; the only Rust change is a comment
• Ran make test — ran cargo test -p ethlambda --profile release-fast --bins only, which holds the network/config tests

[github-actions]

🤖 Kimi Code Review

I'll review this PR which updates Sepolia's configuration for the merge transition terminal block hash and adds gas limit scheduling.

Review

Configuration Changes (bin/ethlambda/assets/sepolia/config.yaml)

Lines 28-29: TERMINAL_BLOCK_HASH and TERMINAL_BLOCK_HASH_ACTIVATION_EPOCH changes

The update from default values to Sepolia's actual merge parameters looks correct:

• TERMINAL_BLOCK_HASH: 0x0000...0000 → 0xd07cce9785d39c0dd2409b7d8e69d6bff26a69a0fa5308ac781c63ffe2a37bc1
• TERMINAL_BLOCK_HASH_ACTIVATION_EPOCH: 18446744073709551615 (u64::MAX) → 3599

These match the documented Sepolia merge values. The previous default values effectively disabled the terminal block hash override mechanism.

Lines 219-223: New GAS_LIMIT_SCHEDULE section

This adds a gas limit schedule entry at epoch 353024 with limit 200,000,000. This appears to be for the Sepolia Pectra upgrade configuration.

Potential issue: The GAS_LIMIT_SCHEDULE field is not a standard Ethereum consensus spec field. Verify this is:

1. Actually consumed by your client's configuration parser
2. Not confused with execution-layer gas limit (this is consensus config, but gas limit is typically an execution payload field)

If this is a custom extension, document it clearly. Standard consensus specs use gas_limit in execution payloads, not a schedule in config.

Comment Update (bin/ethlambda/src/main.rs)

Lines 1595-1603: Updated comment in first_config_difference

The comment expansion correctly explains why these fields are excluded from chain-identity comparison. The reasoning is sound: post-merge networks don't execute validate_merge_block on new imports.

Minor suggestion: The comment says "Sepolia's file does set the TERMINAL_BLOCK_HASH override" — this is now true after this PR, but the comment structure suggests it was written anticipating this change. The grammar is slightly awkward ("its merge used" → "used for its merge"). Consider:

// Sepolia's file does set the `TERMINAL_BLOCK_HASH` override that
// was used for its merge, but no block a node imports today is checked
// against it.

Summary

Aspect	Assessment
Correctness	✅ Values appear correct for Sepolia
Security	✅ No vulnerabilities; this is config data
Consensus safety	✅ Terminal block hash override is post-merge, no live fork choice impact
Code quality	⚠️ Minor grammar in comment; verify GAS_LIMIT_SCHEDULE parser support

No blocking issues found. The configuration update is straightforward and safe.

---

Automated review by Kimi (Moonshot AI) · kimi-k2.6 · custom prompt

[github-actions]

🤖 Claude Code Review

Review of PR 693: refresh Sepolia config from eth-clients

The PR is small and low risk. I found nothing blocking.

What changed

• bin/ethlambda/assets/sepolia/config.yaml has new TERMINAL_BLOCK_HASH and TERMINAL_BLOCK_HASH_ACTIVATION_EPOCH values, plus a GAS_LIMIT_SCHEDULE block.
• The comment in first_config_difference (bin/ethlambda/src/main.rs) is reworded to match.

Checks

• TERMINAL_BLOCK_HASH and TERMINAL_BLOCK_HASH_ACTIVATION_EPOCH are only read in fork_choice.rs:1894, in the merge-block validation. Sepolia is long past its merge, so the new values affect no block imported today. This matches the new comment.
• GAS_LIMIT_SCHEDULE is already listed as a known-but-ignored key in config_file.rs:149. The new block therefore parses without a hard error. It adds an entry to the ignored-keys startup warning. That is expected, and the warning only exists to flag such keys.
• The file stays a byte-for-byte copy of the eth-clients file, as CLAUDE.md requires.
• The asset's SHA is not pinned by a test. The only parse-level pin I know of is the_built_in_network_derives_what_it_always_did, which covers mainnet. Please confirm CI passes the Sepolia built-in parse tests. I did not run them.

Minor notes

• The new comment says "no block a node imports today is checked against it". That is accurate for a follower that starts from a checkpoint. A node that re-syncs from before Sepolia's merge would never get that far, because built-in networks have no genesis-sync path. The wording is fine.
• Nothing else in the repo references 3599 or the old u64::MAX activation epoch. No test expectations need updating.

The change is correct and consistent with the codebase. LGTM.

---

Automated review by Claude (Anthropic) · sonnet · custom prompt

[github-actions]

🤖 Codex Code Review

• Potential consensus bug: first_config_difference now explicitly ignores terminal_total_difficulty, terminal_block_hash, and terminal_block_hash_activation_epoch as “not chain identity” in bin/ethlambda/src/main.rs:1596. That looks unsafe for resumed/replayable directories that may still import or re-validate Bellatrix merge-transition blocks. validate_merge_block still enforces these config values in live block processing at crates/blockchain/state_transition/src/beacon/fork_choice.rs:1884, and Bellatrix blocks hit that path at crates/blockchain/state_transition/src/beacon/fork_choice.rs:2491. A node resuming an old or partial store could therefore accept a config change that alters merge-block validity without refusing startup. I’d keep these fields in chain-identity checks, or at minimum gate the exemption on processed_through being strictly past the network’s Bellatrix transition window with a stronger proof than “shipped network is past merge.”

• Config evolution mismatch: the new Sepolia values in bin/ethlambda/assets/sepolia/config.yaml:28 are justified by the comment, but the code path that swaps persisted config on resume (store.replace_config(config.clone())) still updates the store-wide config used by validation for any subsequent replay/import, see bin/ethlambda/src/main.rs:1866 and crates/storage/src/store.rs:1715. That makes the “no block a node imports today is checked against it” assumption broader than the implementation actually guarantees.

• Everything else in this PR looks fine: the GAS_LIMIT_SCHEDULE addition in bin/ethlambda/assets/sepolia/config.yaml:223 is config-only here, with no obvious performance or memory impact in this diff, and the comment update itself is readable and maintainable.

---

Automated review by OpenAI Codex · gpt-5.4 · custom prompt