Operator Doppelgänger Protection

[dknopik]

A operator doppelgänger is the duplicate use of a single operator key in multiple SSV client instances.

This causes equivocation in QBFT instances, which will be punished by message validation and can cause general mayhem in the P2P layer.

In the worst case, when there are multiple doppelgängers in a committee, this can even lead to slashing of the validators associated with it.

We should introduce a feature that lets Anchor listen to the P2P layer for a configurable while (e.g. for one epoch) before commencing duties, and quit if it finds a signature that originates from its own private key.

This can e.g. implemented by await-ing something during startup, or by extending the is_synced mechanism:

anchor/anchor/client/src/lib.rs

Lines 560 to 566 in 544dece

	info!("Waiting for sync to complete before starting services...");
	is_synced
	.clone()
	.wait_for(|&is_synced| is_synced)
	.await
	.map_err(|_| "Sync watch channel closed")?;
	info!("Sync complete, starting services...");

[diegomrsantos]

Operator Doppelgänger Protection proposal

Scope
This feature is operator-only: detect if our OperatorID is already active elsewhere and avoid running alongside it. Validator DP is out of scope for this issue. SSV messages carry a signed wrapper that includes a signer list (OperatorIDs), which we use for detection.

Behavior
• Monitor mode on startup (read-only). Subscribe to SSV topics; don’t publish.
• Self-ID kill-switch. If any validated SSV message lists our OperatorID in its signer list → fatal exit (operator twin detected).
• Fixed wait window. Remain silent for ~2–3 epochs, then start normal operation if the kill-switch never fired. (Validator clients commonly use a 2–3 epoch window for DP; SSV operator docs describe a ~3-epoch DG window.) 

Why no “quorum fast-path” for operator DP?
The fast-path is a validator DP optimization in SSV: if the committee reaches a post-consensus quorum (“Decided”) for the validator, the node marks that validator safe immediately (it’s already running inside the SSV committee) instead of waiting the full window. That logic proves validator activity inside SSV, not the absence of an operator twin. We keep operator DP minimal: wait + self-ID.

Config & UX
• --operator-dg=true (default), --operator-dg-wait-epochs=2|3.
• Logs: “Operator DP: monitoring…”, “Twin detected (our OperatorID on gossip) — exiting”, “Operator DP window elapsed — starting”.

References
• SSV message structure (signed wrapper with signer list).
• Teku DP waits ≤ 2 epochs; Lighthouse recommends 2–3 epochs.
• SSV docs: DG window ~3 epochs; SSV releases describe validator DP fast-path (“Decided” quorum → safe immediately).

[dknopik]

--operator-dg=true (default)

I am not sure if we should have it be enabled by default, does SSV do it?

Otherwise this seems reasonable. Note that for the decided messages, we need to NOT trigger operator doppelganger protection, as those can be constructed by any node

[diegomrsantos]

Operator Doppelgänger Protection — proposal (operator-only)

Scope

This feature is operator-only: detect if our OperatorID is already active elsewhere and avoid running alongside it. Validator DP is out of scope.

Detection rule (simple & strict)

• Self-ID kill-switch: while in monitor mode, if we receive any validated, single-signer SSV message (consensus or partial) whose signer is our OperatorID, we treat it as evidence of a live twin.
• Do not use aggregates (e.g., Decided/aggregated commit) as evidence. A Decided message is a quorum certificate built from many operators’ commits; it can legitimately include our ID from past activity and doesn’t prove a current twin.

Guard against stale replays (after restart)

Newly restarted peers can briefly re-send recent messages via the GossipSub IHAVE/IWANT exchange. To avoid false positives, apply a freshness floor: only consider a self-ID hit if msg.height >= (recent_max_height − K) (e.g., K = 3).

Behavior

• Monitor mode on startup (read-only). Subscribe to SSV topics; do not publish.
• Wait window: remain silent for ~2 epochs (configurable; 2–3 is common in the ecosystem).
• During monitor mode:
  • Update recent_max_height from any valid consensus traffic.
  • If a fresh, single-signer message with our OperatorID arrives ⇒ twin detected (see Open decision below).
• When the wait window elapses without a twin signal: start normal operation.

Open decision (please confirm one)

What should the node do when a twin is detected?

1. Fatal shutdown (validator-style). Exit immediately with a clear error so operators can investigate and ensure the other instance is stopped.
2. Stay up but extend monitor mode. Keep the process running, do not publish, raise loud/structured alerts, and keep re-checking; also enforce a hard max wait cap to avoid waiting indefinitely.

Current codebase preference leans toward avoiding intentional crashes; option (2) aligns with that, while (1) mirrors common validator behavior. Let’s decide which UX we want for operators.

Configuration (minimal)

• --operator-dg=true (default)
• --operator-dg-wait-epochs=2|3 (default: 2)
• --operator-dg-fresh-k=3 (heights considered “fresh”)

Notes

• This proposal intentionally does not use the “post-consensus quorum / Decided fast-path.” That shortcut is a validator DP optimization (ending a validator’s mute early when its SSV committee is already running it), not proof about operator twins.

Tiny state machine

state:
  recent_max_height[committee] = 0
  K = 3  # instances to keep as "fresh"

on_start:
  mode = MONITOR
  wait_until = now_epoch + OP_DG_WAIT_EPOCHS  # 2–3

on_gossip(msg):
  if !valid(msg): return
  recent_max_height[msg.committee] = max(recent_max_height[msg.committee], msg.height)

  # Only single-signer messages can prove a live twin
  if msg.signers == [my_operator_id]:
    baseline = recent_max_height[msg.committee].saturating_sub(K)
    if msg.height >= baseline:
      // twin detected: choose action (shutdown OR extend monitor mode)
      handle_twin_detected()

on_epoch_tick:
  if current_epoch >= wait_until:
    mode = ACTIVE  # enable QBFT & partials