feat: unified hardfork upgrade system with CollectUpgrades registry

[0xmhha]

Summary

• Introduce ChainConfig.CollectUpgrades() as the single source of truth for hardfork registration, replacing scattered manual append patterns
• Add block-0 hardfork overlay in InjectContracts so mainnet genesis correctly includes all hardforks activated at genesis (e.g., Boho GovMinter v2)
• Refactor GetSystemContractsStateTransition to merge multiple upgrades at the same block height
• Separate system contract initialization (initialize*) and upgrade (upgrade*) paths
• Fix genesis-updater tool to preserve block-0 hardforks in stripHardforkConfig

System Contract Versioning

System contracts follow a strict versioning protocol:

• Version v1 is mandatory as the initial version. The initialize*() functions (e.g., initializeValidator, initializeMinter) are only invoked when Version == "v1". These functions set up the required storage layout (owner, quorum, members, etc.). Starting with any other version will skip initialization, leaving the contract in an uninitialized state.
• Subsequent versions must increase monotonically (v2, v3, ...) in ascending block order. A higher version at a lower block followed by a lower version at a higher block (e.g., v3 at block 100, v2 at block 200) is invalid — downgrades are not supported.

Initialize vs Upgrade

Path	Trigger	Behavior
initialize*()	Version == "v1"	Full storage initialization with all required parameters
upgrade*()	Version != "v1" (v2, v3, ...)	Partial state migration — only keys present in Params are written; missing keys preserve on-chain state

When Params is nil, only the contract bytecode is replaced and no state changes are made. This is the standard hardfork upgrade scenario where code is swapped but existing governance state is preserved.

Genesis Hardfork Overlay

When a hardfork activates at block 0 (e.g., mainnet BohoBlock=0), InjectContracts applies it as an overlay on top of the baseline v1 contracts:

InjectContracts()
  Phase 1: Deploy Anzeon baseline (v1) — all system contracts initialized
  Phase 2: Apply block-0 hardfork overlays from CollectUpgrades()
           → e.g., Boho replaces GovMinter v1 bytecode with v2 (Params=nil → code only)

Hardforks with Block > 0 are skipped during genesis — they are applied at runtime via processFinalize → GetSystemContractsStateTransition.

Adding a New Hardfork

Adding a new hardfork requires only:

1. Standard go-ethereum fields in ChainConfig (CForkBlock, CFork, IsCFork(), etc.)
2. One entry in CollectUpgrades() — genesis and runtime paths are handled automatically

No changes needed in InjectContracts, SetConfigFromChainConfig, or processFinalize.

Changed files

Area	Files	Change
Registry	params/config.go	CollectUpgrades() method, updated genesis hash
Genesis	core/genesis.go	InjectContracts block-0 overlay via applyUpgradeOverlay
Runtime	consensus/wbft/config.go	Merge-based GetSystemContractsStateTransition
Engine	eth/ethconfig/config.go	SetConfigFromChainConfig uses CollectUpgrades()
Contracts	systemcontracts/*.go	initialize*/upgrade* split, Params nil guard
Tooling	scripts/cmd/genesis-updater/main.go	Preserve block-0 hardforks in stripHardforkConfig
Tests	*_test.go (10 files)	Comprehensive tests for all upgrade paths

Test plan

• go test ./params/ — CollectUpgrades ordering, Boho at block 0 and block N
• go test ./core/ — Genesis hash consistency, SetupGenesis, Anzeon init, Boho overlay
• go test ./consensus/wbft/ — Merge-based state transition, multi-upgrade at same block
• go test ./systemcontracts/ — initialize/upgrade routing, Params nil guard, partial params
• go test ./eth/ethconfig/ — Engine config setup
• go vet and gofmt pass on all modified packages

[colinkim]

LGTM

[hominlee-wemade]

LGTM

[eomti-wm]

LGTM