Context
External monitoring / test tooling needs to confirm, per node, which SSV epoch the Boole fork is scheduled at. The Gloas/ePBS fork already logs this at boot — beacon/goclient/spec.go: gc.log.Info("Gloas (ePBS) fork scheduled", zap.Uint64("epoch", …)) — but there is no equivalent for the SSV Boole fork. The node knows the epoch at boot (networkConfig.SSV.Forks.Boole, used at runtime in cli/operator/node.go, operator/duties/scheduler.go, operator/validator/controller.go, …) but never logs the schedule.
This blocks a clean fork-awareness check in Aetheria's upcoming (boole) fork-transition suite (ssvlabs/aetheria#168): with no boot log, the suite has to infer the fork epoch from the first Boole topic subscription rather than read it directly from each node and cross-check agreement across the fleet (the way the gloas (transition) suite keys on Gloas (ePBS) fork scheduled).
Ask
- Emit a single INFO line at startup, e.g.
Boole fork scheduled with an epoch field (SSVForks.Boole), analogous to the Gloas log. Optionally include the current-vs-next domain types (DomainType / NextDomainType, DomainTypeAtSlot), which are the visible effect of the fork.
- A DEBUG twin for the disabled case (
Boole == math.MaxUint64, i.e. unscheduled — the live-net default) would mirror the Gloas fork not scheduled pattern and flag a misconfiguration on a net where Boole should be scheduled.
Why it helps
- Lets a harness/operator discover and cross-check the Boole fork epoch across the fleet (fork-awareness) instead of inferring it indirectly.
- Symmetric with the existing Gloas boot log, so tooling can treat both forks uniformly.
- Nice-to-have, not a blocker: Aetheria works by taking the epoch as configuration — but a boot log makes the fork-awareness assertion direct, cheap, and robust to config drift, and is generally useful for operators verifying a scheduled fork.
Grounding
networkconfig/ssv.go (SSVForks.Boole), networkconfig/network.go (BooleForkAtEpoch / DomainTypeAtSlot), beacon/goclient/spec.go (the Gloas analog to mirror). Related: ssvlabs/aetheria#168, #2941 (Boole → stage convergence).
Context
External monitoring / test tooling needs to confirm, per node, which SSV epoch the Boole fork is scheduled at. The Gloas/ePBS fork already logs this at boot —
beacon/goclient/spec.go:gc.log.Info("Gloas (ePBS) fork scheduled", zap.Uint64("epoch", …))— but there is no equivalent for the SSV Boole fork. The node knows the epoch at boot (networkConfig.SSV.Forks.Boole, used at runtime incli/operator/node.go,operator/duties/scheduler.go,operator/validator/controller.go, …) but never logs the schedule.This blocks a clean fork-awareness check in Aetheria's upcoming
(boole)fork-transition suite (ssvlabs/aetheria#168): with no boot log, the suite has to infer the fork epoch from the first Boole topic subscription rather than read it directly from each node and cross-check agreement across the fleet (the way the gloas(transition)suite keys onGloas (ePBS) fork scheduled).Ask
Boole fork scheduledwith anepochfield (SSVForks.Boole), analogous to the Gloas log. Optionally include the current-vs-next domain types (DomainType/NextDomainType,DomainTypeAtSlot), which are the visible effect of the fork.Boole == math.MaxUint64, i.e. unscheduled — the live-net default) would mirror the Gloasfork not scheduledpattern and flag a misconfiguration on a net where Boole should be scheduled.Why it helps
Grounding
networkconfig/ssv.go(SSVForks.Boole),networkconfig/network.go(BooleForkAtEpoch/DomainTypeAtSlot),beacon/goclient/spec.go(the Gloas analog to mirror). Related: ssvlabs/aetheria#168, #2941 (Boole → stage convergence).