fix: add Prysm v7 config keys to the mainnet chain config

[inf-1oop]

Problem

networks/mainnet/config.yml declares PRESET_BASE: mainnet, so every key it does not define is inherited from Ethereum mainnet. Prysm v7 added three settings this config never overrides, and each inherited default breaks a Vana node in a different way — two of them silently.

Key	Inherited value	Failure
FULU_FORK_VERSION / GLOAS_FORK_VERSION	0x06000000 / 0x07000000	Node refuses to start: version 0x06000000 for fork fulu in config vana conflicts with existing config named=mainnet
SLOT_DURATION_MS	12000	Preferred over SECONDS_PER_SLOT for all slot timing → 12s/slot arithmetic on a 6s chain → FATAL invalid payload timestamp
BLOB_SCHEDULE	Ethereum BPO forks at epochs 412672 / 419072	Gossip allowlist truncated → every gossip topic refused

On BLOB_SCHEDULE specifically

A BPO entry only receives a distinct fork digest when its epoch is at or after FULU_FORK_EPOCH. Fulu is disabled here, so Ethereum's BPO entries instead reuse the preceding fork's digest — and since 412672/419072 fall between Bellatrix (epoch 2) and Capella/Deneb (503609), they carry Bellatrix's digest.

Prysm's allTopics() walks the fork schedule terminating on next.ForkDigest != last.ForkDigest, so the repeated digest halts the walk before Capella/Deneb. The allowlist ends up with 221 topics and no 78ba1733 (the live Deneb digest), so pubsub refuses everything with topic is not allowed by the subscription filter.

This one is the nastiest to diagnose: the node still starts and follows the chain by range sync, so it looks alive. It just participates in nothing — no gossip, and a sync distance that drifts instead of sitting at 0.

Verification

Tested on a live Vana mainnet node running Prysm v7.1.8:

• Before: FATAL at startup, then (after the fork keys) FATAL invalid payload timestamp, then (after SLOT_DURATION_MS) a running-but-gossip-dead node with sync distance drifting 2→17 and block arrival at 7–13s.
• After all three: sync distance 0 sustained, head advancing 2 slots / 12s (correct 6s cadence), 0 subscription-filter rejections, 0 payload-timestamp errors, 17 peers.

Consensus-safety checks:

• genesis_validators_root unchanged: 0x7a2ee1f3a4332b8a3229efd4cba0903049bc8b1e7cd1fe46052e320cf3f6d184
• Fork unchanged: current_version 0x20000093, head block version deneb
• Fulu/Gloas do not enter the fork schedule (far-future epochs are truncated), so the resulting schedule is still exactly Phase0 → Deneb and the Deneb digest is still 0x78ba1733
• MaxBlobsPerBlockAtEpoch() at the current epoch is 6 both before and after — the inherited BPO entries were superseded by Deneb, so emptying the schedule changes no blob limit

Backward compatible with Prysm v5.1.0: it logs the six new lines as unknown fields (field FULU_FORK_VERSION not found in type params.BeaconChainConfig, etc.) and continues normally. Operators who have not upgraded are unaffected apart from that one log line.

Not included: networks/moksha/config.yml

Moksha is missing all four keys too and will hit the same class of problem on v7. I have deliberately left it out because I could not test it, and it is not a copy-paste of this change:

• Its fork-version numbering differs (ELECTRA_FORK_VERSION: 0x60000038, not the 0x2000009x series), so Fulu/Gloas versions need a deliberate choice.
• All its forks are at epoch 0, so the inherited BPO entries land after Deneb rather than before it — the topic-walk truncation may not bite the same way.

Worth a follow-up from someone who can run a Moksha node.