config: load networking overrides from RuntimeConfig

[SyedMuhamadYasir]

Summary

Make a small set of networking parameters available through Nimbus's existing typed RuntimeConfig path instead of requiring compile-time overrides:

• EPOCHS_PER_SUBNET_SUBSCRIPTION
• SUBNETS_PER_NODE
• MAXIMUM_GOSSIP_CLOCK_DISPARITY
• MAX_REQUEST_BLOCKS

This is a network-agnostic runtime-config alternative to the compile-time intdefine approach in #7618, which helped scope the compatibility gap. It does not add custom-network-specific branches, names, chain IDs, or magic values.

TERMINAL_BLOCK_HASH is no longer consumed by Nimbus, so it is treated as an ignored legacy config value rather than adding generic Hash32 parsing behavior for an inert field.

Design

The change keeps Nimbus's existing boundary between behavioral runtime configuration and structural/type-level limits.

Runtime consumers use direct typed RuntimeConfig fields; there is no dynamic registry or string lookup in protocol hot paths, and stock defaults remain unchanged.

In particular, modern Deneb sync continues to use compile-time MAX_REQUEST_BLOCKS_DENEB. Runtime MAX_REQUEST_BLOCKS is accepted, stored, and exposed through the config API; Nimbus does not consume it for sync.

MAXIMUM_GOSSIP_CLOCK_DISPARITY is propagated to the relevant gossip/validation consumers, including the proposer-duties v2 path added in #8963.

Subnet stability behavior uses the configured EPOCHS_PER_SUBNET_SUBSCRIPTION and SUBNETS_PER_NODE values. These values are explicit at ActionTracker initialization; the subscription period is converted once and stored in UInt256 form for the subnet calculation.

Tests

Permanent tests cover:

• custom networking values and ignored legacy TERMINAL_BLOCK_HASH
• preservation of compiled networking defaults
• runtime networking guardrails for consumed behavioral values, while unused MAX_REQUEST_BLOCKS accepts any uint64
• runtime stability-subnet parameters

The generated AllTests-mainnet.md inventory is updated accordingly.

Review validation after rebasing onto unstable at fb921544be650d846cdccfca22b1a4b128c710fc:

• focused runtime-config tests passed under mainnet, minimal, and gnosis presets
• action-tracker tests passed
• full nimbus_beacon_node build passed with -d:disableMarchNative -d:disableLTO

An earlier revision also passed the broad make test gate with 14,302 tests, 0 failures, 0 errors.

Upstream CI remains authoritative for the normal build matrix.

[github-actions]

Unit Test Results

       12 files  ±  0    2 892 suites  +4   1h 6m 14s ⏱️ + 3m 56s
11 462 tests +  4    8 270 ✔️ +  4  3 192 💤 ±0  0 ❌ ±0 
57 204 runs  +16  51 377 ✔️ +16  5 827 💤 ±0  0 ❌ ±0 

Results for commit 31d9c26. ± Comparison against base commit 7acd211.

[tersec]

Having epochsPerSubnetSubscription and subnetsPerNode be optional parameters isn't really correct given the premise of this PR.

Also, epochsPerSubnetSubscription is only used in UInt256 form, so it's better to convert once and store that UInt256 in action_tracker than a uint64 which keeps having to be converted at each use (node_id mod epochsPerSubnetSubscription.u256).

[SyedMuhamadYasir]

Agreed. Updated in f1ec4bd. epochsPerSubnetSubscription and subnetsPerNode are now required parameters rather than optional defaults. ActionTracker converts the subscription period once during initialization and stores it as UInt256, so the subnet calculation consumes that directly instead of converting it on each use. I also updated the affected call sites and tests.

[tersec]

Extra newline/empty line

[SyedMuhamadYasir]

Fixed in f1ec4bd.

[tersec]

This does a lot of validation on TERMINAL_BLOCK_HASH which hasn't been used in years:

• remove TTD monitoring #4486
• stop calling exchangeTransitionConfiguration #5889
• rm non-runtimeconfig NUMBER_OF_COLUMNS from local testnet settings #8589

At this point

$ rg TERMINAL_BLOCK_HASH beacon_chain/ research/ tests/
beacon_chain/spec/presets.nim
105:    TERMINAL_BLOCK_HASH*: Hash32
106:    TERMINAL_BLOCK_HASH_ACTIVATION_EPOCH*: Epoch  # Not actively used, but part of the spec
259:    TERMINAL_BLOCK_HASH:
478:    TERMINAL_BLOCK_HASH:
692:    TERMINAL_BLOCK_HASH:

beacon_chain/rpc/rest_config_api.nim
178:          TERMINAL_BLOCK_HASH:
179:            $cfg.TERMINAL_BLOCK_HASH,
180:          TERMINAL_BLOCK_HASH_ACTIVATION_EPOCH:
181:            Base10.toString(uint64(cfg.TERMINAL_BLOCK_HASH_ACTIVATION_EPOCH)),

is all that's left, that is, it's a configuration stub. My inclination actually would be to add an explicit ignoredValues entry for something like this and get it removed from the configurations as well as the one sort-of-user, the config API which reports a value that neither Nimbus nor almost any other CL client these days can do much with.

I recently checked for other purposes and even support for running pre-Pectra has been removed from all but a couple CLs.

This is akin to the MAX_REQUEST_BLOCKS case -- from a Nimbus perspective it's a garbage value which can float freely and there's no real validation to be done.

[tersec]

So there's no reason to actually "parse" this thing, really. It's just a black box string which is read in and then regurgitated for the config endpoint (and even that might be removable).

[SyedMuhamadYasir]

Agreed. In f1ec4bd I dropped the generic quoted-Hash32 parsing change and its parser-specific tests. TERMINAL_BLOCK_HASH is now treated as an ignored legacy config value, so Nimbus accepts the key without parsing or validating it and retains the default runtime value. I left removal of the dormant RuntimeConfig field/config-API output out of this PR to keep the networking change focused, but I can fold that cleanup in here if you would prefer.

[tersec]

Another MAXIMUM_GOSSIP_CLOCK_DISPARITY reference was added in:

• implement getProposerDutiesV2 #8963

[SyedMuhamadYasir]

Thanks for the #8963 heads-up. I rebased through it and updated the newly added proposer-duties v2 path to use node.dag.cfg.gossipClockDisparityDuration in f1ec4bd.