feat(upgrade-signal): wire upgrade-signal support into consensus nodes

[PelleKrab]

Summary

• wires L1 upgrade-signal schedule reads into standalone and integrated consensus startup
• adds consensus runtime admin refresh support for applying upgrade-signal schedules
• applies startup upgrade-signal schedules to both EL and CL runtime views in integrated nodes
• defaults integrated upgrade-signal L1 RPC config from the consensus L1 RPC when no explicit upgrade-signal RPC is provided
• adds separate opt-in EL and CL upgrade-signal metrics with layer and upgrade labels
• routes startup apply and runtime admin refresh through shared upgrade-signal schedule validation/application helpers
• renames public upgrade-signal surfaces from hardfork terminology to upgrade terminology
• narrows base-upgrade-signal exports

Testing

• cargo fmt --check
• git diff --check origin/main..HEAD
• cargo check -p base-upgrade-signal -p base-consensus-node -p base-execution-cli -p base-node-core -p base
• cargo test -p base-upgrade-signal --lib
• cargo test -p base-consensus-cli -p base-execution-cli -p base-node-core --lib upgrade_signal
• cargo test -p base --bin base upgrade_signal
• tested on devnet

[cb-heimdall]

🟡 Heimdall Review Status

Requirement	Status	More Info
Reviews	🟡 -1/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 2 if repo is sensitive 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 0 Sum 1

[refcell]

Is .with_runtime_upgrade_overrides expensive here? We don't want to do any expensive operations here ideally

[PelleKrab]

The most expensive part is a clone, we clone RollupConfig and then we do a pass over to update any timestamp changes. So as it stands its pretty cheap, but we could definitely get this back to a single clone in future. I think it would be good to do this in a separate Dynamic upgrade activation optimization PR, since there are some other changes I would like to make.

[refcell]

Looking very good. Left a few comments that I think are worth addressing before we merge.

[cb-heimdall]

Review Error for refcell @ 2026-06-24 11:38:25 UTC
User failed mfa authentication, see go/mfa-help

[refcell]

I think there is a subtle runtime issue here when upgrade-signal.apply-upgrade-id is configured to a subset of upgrades. Let me walk through what I'm seeing happens.

The runtime refresh path reads the L1 schedule for upgrade_ids, then filters it down to apply_upgrade_ids via application_schedule(). The filtered schedule is then passed into UpgradeSignalRuntimeApplier::apply_schedule(), which creates a fresh RuntimeRegistrySink.

When apply_schedule_to_sink() finishes, it calls staged_sink.finalize(), and RuntimeRegistrySink::finalize() commits by calling RuntimeUpgradeRegistry::replace_overrides(chain_id, updates) or clear_chain() if the filtered updates are empty. So the filtered application schedule is treated as the complete replacement set for the whole chain.

This means a runtime refresh can unintentionally drop existing runtime overrides for upgrades that were not included in apply_upgrade_ids. For example, if the registry currently has {Azul: 100, Cobalt: 300}, and the node is configured to read [Azul, Beryl, Cobalt] but apply only [Beryl], then the L1 read may correctly return all three signals, but application_schedule() reduces it to only {Beryl: 200}. finalize() then replaces the entire chain registry with just {Beryl: 200}, removing Azul and Cobalt even though L1 did not clear them and the user only scoped which upgrade should be applied.

I'm not sure we should allow this behavior.

One option is to just remove apply_upgrade_ids and use upgrade_ids, requiring the applied schedule to be complete. Alternatively, we could support a subset by making the runtime path merge touched IDs instead of replacing the whole registry, e.g. update only the IDs present in the filtered schedule and avoid calling clear_chain() for an empty scoped schedule. If both full replacement and scoped updates are desired, the code probably needs to carry that distinction explicitly so finalize() knows whether it is committing a complete schedule or only a selected subset.

[PelleKrab]

I went for the full schedule apply to keep it simple for now, as we don't gain too much from individual upgrade reads. We may want to add a read full schedule to the smart contract to further simplify it.

[refcell]

Took another look and I think there's a couple issues with how we configure applying upgrades as well as blocking node startup on failure.

[github-actions]

Review Summary

This PR refactors upgrade signal handling across execution and consensus layers, introducing unified startup application (apply_startup_to_sinks), the ConsensusNodeStartOptions builder, and extracting the upgrade signal actor into its own module. The overall design is clean and the refactoring reduces duplication.

No new critical issues found beyond what previous inline comments have raised. The prior findings remain relevant:

Still-relevant prior findings

1. Wire format breaking change (summary.rs, metrics.rs): The field renames (hardfork_id → upgrade_id, label hardfork → upgrade) change the JSON RPC response shape and Prometheus metric names. This should be documented in release notes so operators can update dashboards and tooling in lockstep.

2. Refresher silently dropped when admin RPC disabled (rpc/actor.rs:130): When --upgrade-signal.mode=runtime-admin is set but --rpc.enable-admin is not, the refresher is constructed but never wired into the RPC module. A startup warning or configuration validation would prevent operator confusion.

3. Duplicate info logs on admin refresh (admin.rs + refresher.rs): Both the UpgradeSignalRefresher::refresh() and the previous RPC handler (now removed) logged the same summary fields. The refresher still logs at info! level; verify this is the desired single-log behavior after the handler cleanup.

Resolved prior findings

• The long method name (start_with_overrides_and_cancellation_and_upgrade_signal_startup) has been properly replaced with the ConsensusNodeStartOptions struct and start_with_options method.
• The integrated_upgrade_signal.rs concern no longer applies — the startup validation now goes through apply_startup_to_sinks which calls runtime_validation.validate_schedule().

Architecture notes

• The UpgradeSignalNodeConfig in the consensus service properly resolves to fail-closed validation when no activation admin is provided, which is the right default for standalone consensus nodes.
• The AlreadyApplied startup mode correctly prevents double-application in embedded (rpc/sequencer) commands where execution already applied the schedule.
• The UpgradeSignalMetricsActor uses a proper double-select! pattern for cancellation safety during L1 polling.

[github-actions]

✅ base-std fork tests: all 616 passed

base/base is fully in sync with the base-std spec.

Dependency	Ref	Commit
base-std	main	4658f1b7
base-anvil	0092692587d8d064dd2c6923ce26a682c58f3694	00926925