Implement profit comparison/maximization features

[zah]

A validator client can be configured to talk to multiple beacon nodes at the same time (i.e. one instance of Nimbus, Prysm, Teku and Lighthouse). When it's time to propose a block, the client can contact all of the beacon nodes, obtaining a possible proposal from all of them. It can then compare these proposals and select the most profitable one (this is done by examining the selection of attestations in the block). A similar logic can be applied when selecting the best attestation aggregate, the best sync committee contribution or even for regular attestations where the client can try to determine the correct head vote by seeing that the majority of the nodes are in agreement.

Similarly, a stand-alone Nimbus beacon node can act as a validator client in order to make sure that its own actions are optimal when compared to the actions proposed by other beacon nodes.

[zah]

@cheatfate, we have some code for calculating the proposer rewards of a block which was developed for the reward analysis Jupyter notebooks here:

https://github.com/status-im/nimbus-eth2/blob/039bece9175104b5c87a8c2ff6b1eafae731b05e/ncli/ncli_common.nim#L383

Perhaps this code needs to be partially duplicated or refactored further because for the current feature we only need the calculated proposer_outcome for the block (you can search all references of this field in the linked file above).

[arnetheduck]

we have some code for calculating the proposer rewards

The VC doesn't have access to (and shouldn't have access to) the state, thus it cannot use the fait-accompli algorithm that the rewards notebooks use - also, working with actual rewards would make it unnecessarily complex - it's enough that we heuristically maximise the coverage of attestations in the block, giving more weight to recent attestations: basically, every validator votes once per epoch and during block proposals, the block with the most recent, and most diverse set of attestations, wins.

Each attestation contains a list of attesters - overlapping attesters should only be counted once.

https://github.com/status-im/nimbus-eth2/blob/unstable/beacon_chain/consensus_object_pools/attestation_pool.nim#L504= is more suitable as a source of inspiration - it relies on the state to "pre-fill" the list of validators that have already voted and therefore won't bring a reward - practically this doesn't matter that much because it's the votes from the most recent slot that give the most rewards, and these are never part of the state.

Another source of inspiration would be vouch.

[tersec]

This has been done.