aggregator committee: improve pre-consensus completeness

[nkryuchkov]

ssvlabs/ssv-spec#604

[greptile-apps]

Greptile Summary

Updated ssv-spec dependency and improved pre-consensus completeness tracking in aggregator committee runner. Added two new tracking mechanisms: (1) seen signers to detect when all committee members have responded, and (2) duties checked for selection to track which validator-root pairs have been verified with the beacon node. Enhanced termination logic to exit early when consensus has started, when all signers have been seen, or when all duties have been checked for selection, preventing unnecessary waiting.

Key changes:

• Early exit when consensus has already started to avoid redundant processing
• Track which operators have sent pre-consensus messages
• Track which (validator, root) pairs have been checked for aggregator/contributor selection
• Terminate duty when either all duties are checked OR all operators have responded, whichever comes first
• Properly initialize tracking maps in StartNewDuty and constructor

Confidence Score: 4/5

• Safe to merge with minor risk from timing-dependent logic
• The implementation correctly tracks pre-consensus completeness with proper initialization and termination conditions. The logic is sound and follows expected patterns. Score is 4 (not 5) due to the complexity of the termination conditions and the timing-sensitive nature of consensus protocols, which would benefit from comprehensive integration testing to verify all edge cases work correctly.
• Pay close attention to protocol/v2/ssv/runner/aggregator_committee.go - the new termination logic involves multiple interacting conditions that should be thoroughly tested

Important Files Changed

Filename	Overview
go.mod	Updated ssv-spec dependency to newer version (v1.2.3-0.20260216172009)
go.sum	Updated checksums for ssv-spec dependency
protocol/v2/ssv/runner/aggregator_committee.go	Added pre-consensus completeness tracking with signer and duty selection markers, improved early termination logic

Flowchart

flowchart TD
    A[Receive Pre-Consensus Message] --> B{Has Consensus<br/>Started?}
    B -->|Yes| C[Return Error:<br/>Ignore Message]
    B -->|No| D[Mark Signer as Seen]
    D --> E[Process Message<br/>basePreConsensusMsgProcessing]
    E --> F{Has New<br/>Quorum?}
    F -->|No| G{Seen All<br/>Signers?}
    G -->|Yes| H[Finish Duty]
    G -->|No| I[Wait for More Messages]
    F -->|Yes| J{Any Aggregator<br/>Selected?}
    J -->|No| K{All Duties Checked<br/>OR All Signers Seen?}
    K -->|Yes| L[Finish Duty]
    K -->|No| M[Wait for More Messages]
    J -->|Yes| N[Mark Duties as Checked]
    N --> O[Fetch Aggregates/<br/>Contributions]
    O --> P[Start Consensus]

Loading

_{Last reviewed commit: ac78bee}

[greptile-apps]

_{3 files reviewed, no comments}

_{Edit Code Review Agent Settings | Greptile}

[iurii-ssv]

LGTM, just minor suggestions

[iurii-ssv]

LGTM, with minor comment

[iurii-ssv]

I believe we don't need to add any of: fields.Slot(vDuty.Slot), fields.ValidatorIndex(vDuty.ValidatorIndex), fields.Root(root) here:

• the fields.Slot(vDuty.Slot) is already propagated with the logger itself (true for every p2p-message-handling func such as ProcessPreConsensus, true for every runner)
• the fields.ValidatorIndex(vDuty.ValidatorIndex), fields.Root(root) are already added to the logger in the code above

[iurii-ssv]

We should also log & record all the data here too, similar to how it's done in other places with .Finished = true:

		r.state().Finished = true
		r.measurements.EndDutyFlow()
		recordTotalDutyDuration(ctx, r.measurements.TotalDutyTime(), spectypes.RoleAggregatorCommittee, 0)
		const dutyFinishedNoAggregators = "✔️successfully finished duty processing (no validator is aggregator or sync committee contributor)"
		logger.Info(dutyFinishedNoAggregators,
			fields.PreConsensusTime(r.measurements.PreConsensusTime()),
			fields.TotalDutyTime(r.measurements.TotalDutyTime()),
		)
		span.AddEvent(dutyFinishedNoAggregators)
		return anyErr

[iurii-ssv]

Since we couldn't have had the consensus phase (if we ended up here), we shouldn't be logging fields.TotalConsensusTime(r.measurements.TotalConsensusTime()), at all (otherwise its value will be 0 which is confusing) ... so I would remove this field from this log-line.

[iurii-ssv]

We should also add these here right before the r.measurements.EndDutyFlow() call, to make sure we log the correct value (and actually record the metric) when terminating duty like that:

	r.measurements.EndPreConsensus()
	recordPreConsensusDuration(ctx, r.measurements.PreConsensusTime(), spectypes.RoleAggregatorCommittee)