Attestation source and target vote consensus

[KaloyanTanev]

🎯 Problem to be solved

In the Holesky Pectra fork. Two clients (who made up a supermajority) chose the wrong fork. All nodes using these BNs voted incorrectly. This crossed the 66% threshold, resulting in them justifying the wrong block and ultimately getting slashed (or being offline forever more). This is the worst case scenario for eth staking. Unfortunately, charon was not able to save any of its DVs either, because we don’t have a halting feature and we were unanimously on the bad versions too, so halting wouldn’t have worked.

🛠️ Proposed solution

We have 2 options on Charon's side:

1. No charon node signs an attestation if one charon node has different source and target roots.
2. A charon node does not sign an attestation if it has different source and target roots.

While the second option will be ideally what will help us prevent the case from above, it will be:

• harder to implement, as it will require overriding the cluster's thresholds;
• an easy way of DoS-ing the whole cluster, which is a big no.

Hence, for first iteration, we are considering only the first option. While it may not prevent such extreme scenarios as the one experience during Pectra, it might be really beneficial for beacon nodes on wrong minority forks.

In the future, a separate feature for "tighter attestation control" might be considered that will override option 1 to option 2 (potentially enabled only for specific time-frame, i.e.: during ethereum hardforks).

🧪 Tests

• Tested by new automated unit/integration/smoke tests - force a beaconmock to supply different attestation source and target roots
• Manually tested on core team/canary/test clusters
• Manually tested on local compose simnet