[SEC] Nbc nodes have unnecessary delay when broadcasting attestations

[montyly]

Severity: Low
Difficulty: Low

Description

The nbc node does not broadcast attestations as soon as they are ready, as specified in the eth 2.0 spec. Nbc node will always wait for a delay period. As a result, the nodes will be slower and will have more difficulty to catch up in case of delay.

The eth 2 specification states than:

A validator should create and broadcast the attestation to the associated attestation subnet when either (a) the validator has received a valid block from the expected block proposer for the assigned slot or (b) one-third of the slot has transpired (SECONDS_PER_SLOT / 3 seconds after the start of slot) -- whichever comes first.

The nbc nodes always wait for (SECONDS_PER_SLOT / 3 seconds after the start of slot) (b):
https://github.com/status-im/nim-beacon-chain/blob/c76305f824fbc6a61eca5bbb9d21002eb6c515e3/beacon_chain/validator_duties.nim#L529-L530

https://github.com/status-im/nim-beacon-chain/blob/c76305f824fbc6a61eca5bbb9d21002eb6c515e3/beacon_chain/validator_client.nim#L158-L159

As a result, the node will wait unnecessary time if they received a valid block. This will lead to delay the sent of attestations and reduce the likelihood for a node of having its attestations present in a block.

Additionally, in the case of the validator client split, the validator will require more time to catch up in case of delay.

Exploit Scenario

Bob uses both a nbc node, and a third-party node. Bob notices that the attestations from the third-party node are more frequently added to the block. Bob receives more rewards from the third-party node and stops using nimbus.

Mitigation Recommendation

Short term, follow the specification and implement a waiting mechanism that will wake up if the node received a valid block

Long term, thoroughly review the eth 2 specification and ensures nbc follows the spec closely. Consider benchmarking nbc with third party implementations to identify areas that could be improved

[mratsim]

This is something we are aware of #966. We had a tentative fix in May #1014 but delayed work on that but it was deprioritized.

[tersec]

This should also take into account ethereum/consensus-specs#2101.

[montyly]

Fixed in #1995