Hard forks: summit cannot change its code as one network

[samlaf]

⚠️ I have not thought through this very seriously. Stumbled upon this while analyzing #447, so got Claude to write this out as a separate independent issue.

Problem

Summit's fork story has two halves, and only one exists.

Detection is free and fail-closed. chain_domain (types/src/lib.rs) folds PROTOCOL_VERSION + config_digest into the domain every consensus signature and p2p handshake lives under, so nodes running divergent rules can't even peer — stronger than pre-forkid Ethereum, which needed EIP-2124 retrofitted after years of mixed-fork peering problems.

The upgrade half is structurally absent. PROTOCOL_VERSION (types/src/lib.rs) is a compile-time constant, and checkpoint verification reconstructs domains using the running binary's version. So shipping code with a bumped version doesn't fork the network — it breaks it: the new binary computes new domains and rejects every signature and checkpoint the chain has ever produced, and mixed-version nodes can't handshake during rollout. Today, any consensus behavior change is not a fork; it's a network split with amnesia.

Why ProtocolParams doesn't cover this

ProtocolParams.sol governs values that existing code reads — stakes, epoch length, caps — and does it well (parameter changes that cost Ethereum EIP-7251-class hardforks are a transaction here). But three things are outside any parameter's reach:

1. New behavior can't be parameterized into existence. A withdrawal-credential rotation operation means new request types, validation logic, and state transitions. invalid_deposit_tax's value is a param; the formula applying it is code. There is no param_id for logic that doesn't exist yet.
2. Coordinated activation. New rules must switch on at an agreed epoch, not whenever each operator restarts — otherwise the cohort splits at the boundary. (The activation trigger could itself ride ProtocolParams — "rules v2 at epoch E" as a governed value — but only if binaries carry both rule sets and consult it. That dual-rules machinery is what Ethereum clients ship for every fork; summit has none.)
3. Domain and verification continuity — the structural blocker above. The domain scheme itself has to become fork-aware.

What Ethereum's history says will ride it

Ethereum precedent	summit analogue
Capella retrofitted bls_to_execution_change — withdrawal-credential rotation didn't exist at launch	a withdrawal_credentials rotation operation (worth deciding the interim story now: immutable-and-documented, or a designed rotation path — not a gap discovered when a founder loses a withdrawal key)
Altair reworked the reward/penalty formulas wholesale	summit's tax/treasury values are governed, but changing the formulas they feed is code — a fork
Shanghai and Cancun changed the Engine API payload shape (withdrawals, blob fields) — every such EL fork forces a coordinated CL fork	the forcing function: when the execution layer hardforks (upstream reth merges alone guarantee it will), summit must fork in lockstep to understand the new payload — so forkability is not optional long-term, only its arrival date is

The known shape of the fix (eth2's)

Per-epoch fork versions: a fork schedule of (epoch, version) pairs anchored at the genesis version; domains computed with the version active at the message's epoch, so history verifies forever under old domains while new messages use the new one; binaries carry the rule sets on both sides of a boundary and switch at the scheduled epoch. Designing summit's version of this is the (eventual) content of this issue.

The decision worth making now

Pre-mainnet, only a placeholder: consensus-code changes are defined to go through a future epoch-versioned fork mechanism — never through "everyone swaps the genesis file" or uncoordinated binary rollouts. That single sentence prevents the accumulation of designs that assume identity re-issuance is an acceptable upgrade path.