VC does not fallback for sync sigs when primary BN is optimistic

[paulhauner]

Description

When the VC attempts to publish a sync committee signature it will try and get the head block root from the first BN that returns a response, regardless if that BN is optimistic or not:

lighthouse/validator_client/src/sync_committee_service.rs

Lines 177 to 209 in 01e84b7

	// Fetch `block_root` and `execution_optimistic` for `SyncCommitteeContribution`.
	let response = self
	.beacon_nodes
	.first_success(RequireSynced::Yes, OfflineOnFailure::Yes,|beacon_node| async move {
	beacon_node.get_beacon_blocks_root(BlockId::Head).await
	})
	.await
	.map_err(|e| e.to_string())?
	.ok_or_else(|| format!("No block root found for slot {}", slot))?;
	let block_root = response.data.root;
	if let Some(execution_optimistic) = response.execution_optimistic {
	if execution_optimistic {
	warn!(
	log,
	"Refusing to sign sync committee messages for optimistic head block";
	"slot" => slot,
	);
	return Ok(());
	}
	} else if let Some(bellatrix_fork_epoch) = self.duties_service.spec.bellatrix_fork_epoch {
	// If the slot is post Bellatrix, do not sign messages when we cannot verify the
	// optimistic status of the head block.
	if slot.epoch(E::slots_per_epoch()) > bellatrix_fork_epoch {
	warn!(
	log,
	"Refusing to sign sync committee messages for a head block with an unknown \
	optimistic status";
	"slot" => slot,
	);
	return Ok(());
	}
	}

I think the ideal behaviour would be trying to find a BN that has a non-optimistic head block root. At first glance I think this would be pretty easy to achieve by pushing the execution_optimistic checks inside the first_success function.

[clifton]

is ERRO Unable to publish proposer preparation a related issue? I get that when one of my beacon nodes is optimistic and the other is synced.

[michaelsproul]

@clifton Yeah, it is. That also falls under the scope of the tracking issue to improve VC fallback behaviour: #3613