Make attestation consensus threshold configurable

[eth2353]

It may make sense not to use the default "majority" threshold for attestation consensus in some cases:

• running 2 beacon nodes

Taking one of the beacon nodes offline for a client update/maintenance will make the validator stop attesting. This is also mentioned in the docs.

Some users may instead prefer to set the consensus threshold to 1 and have Vero work with the beacon nodes in a fallback mode - if one of them goes down, it keeps attesting using the second beacon node. The important drawback of making the threshold 1 out of 2 is that Vero would no longer be cross-checking the head of the chain against multiple nodes.

• running many beacon nodes

At the other end of the spectrum, professional operators may run 10 beacon nodes with a diverse set of client combinations. In this case it may make sense to attest as soon as a certain amount of beacon nodes agrees on the head of the chain, e.g. 3 out of 10, since even at a lower than a majority threshold the validators would already be protected against single-client bugs. This would allow them to attest more quickly than having to wait for a full majority of beacon nodes.

For a setup like this:

flowchart TD

%% VC<->CL
Lighthouse --> Vero
Lodestar --> Vero
Nimbus --> Vero
Prysm --> Vero
Teku --> Vero

%% CL<->EL
Besu <--> Lighthouse
Erigon <--> Lodestar
Geth <--> Nimbus
Nethermind <--> Prysm
Reth <--> Teku

Loading

the node operator could set the consensus threshold to 2 and be protected against single-client bugs.

---

There's already a TODO in the code for this:

vero/src/providers/multi_beacon_node.py

Line 90 in f07cd0f

self._majority_threshold = len(self.beacon_nodes) // 2 + 1