Add disableAttesting flag to vc

[ensi321]

Problem description

Inspired by Lighthouse, to disable vc attesting via a flag.

The original intent of this flag is to reduce burden on CL and EL when they are struggling to sync, and subsequently remove the flag to start attesting upon synced.

However this feature is also deemed useful during Holesky fallout where we want to keep proposing blocks but not attesting. Currently we rely on slashing protection db which do not stop us completely from attesting but only those attestations that would cause slashing.

Solution description

Add disableAttesting flag to vc

Additional context

No response

[nflaig]

The original intent of this flag is to reduce burden on CL and EL when they are struggling to sync

I was thinking about this a bit more but in general this should not add a lot of burden to the beacon node, the validator client just checks the syncing status of the beacon node, and tries to get duties but the beacon node just throws an error early in case it is syncing

I would like that we first define what we wanna the prevent here that is causing a burden for the beacon node

Currently we rely on slashing protection db which do not stop us completely from attesting but only those attestations that would cause slashing.

hmm not sure about this either, what is the use case here? the only reason we didn't want the validator client to not attest but propose was becasue it would be slashed if it submits an attestation and this would cause it to no longer be able to produce blocks which was critical to ensure liveness in Holesky

another case I can think of is if the beacon node is following a wrong chain (like we saw after Holesky forked to electra) but in this case you want to shut down the validator client altogether, even producing blocks on top of that wrong chain would be harming the network

A very useful feature would be to configure the beacon node to only submit proposals to the network and not attestations, the use case for this is DoS protection, because it is quite easy to figure out the beacon node that are connected to a specifc validator by observing attestations on p2p, this allows an attacker to target your beacon node right before it has to propose a block, until we have implemented proposer privacy like whisk, this seems like the best approach prevent this attack because if the beacon node only becomes active when it proposes it is not leaking information about what validators are connected to it. I can see this being useful for people that run multiple nodes and connect their validator client to all of them.