Allow same-slot attestations to affect the fork choice

[casparschwa]

Problem

The fork choice rule does not consider attestations from the same slot. Apart from the fact that some attacks may benefit from this, it's unclear why the fork choice rule should not consider same-slot attestations.

An attacker may strategically release attestations from previous slots in such a way that it could tip over honest attestors from the current slot to vote for a different head of the chain. There may be scenarios where this only works because the fork choice is disregarding attestations from the current slot.

Proposed solution

Allow attestations from the current slot to be considered by the fork choice.

---

EDIT: Read some counterarguments to this PR in a comment below. Summary: While in optimistic scenarios this PR intuitively makes sense, it seems that in adversarial conditions there may be strong reasons to not consider same-slot attestations.

---

Special thanks to @adiasg and @barnabemonnot for discussions/help.

[hwwhww]

This change looks correct to me. 👍

Side note for myself, not an issue:

1. In on_attestation docstring:

   An attestation that is asserted as invalid may be valid at a later time, consider scheduling it for later processing in such case.

2. In the networking spec: https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/p2p-interface.md#beacon_attestation_subnet_id

   • [IGNORE] attestation.data.slot is within the last ATTESTATION_PROPAGATION_SLOT_RANGE slots
     (within a MAXIMUM_GOSSIP_CLOCK_DISPARITY allowance) --
     i.e. attestation.data.slot + ATTESTATION_PROPAGATION_SLOT_RANGE >= current_slot >= attestation.data.slot
     (a client MAY queue future attestations for processing at the appropriate slot).

Due to (2), the future attestations (current_slot < attestation.data.slot) should have been ignored in the networking layer, so the client should not need to consider scheduling the future attestations.

[casparschwa]

Some (strong) counterarguments to the proposal of this PR:

• An adversary who controls many nodes across the topology of the p2p layer may abuse same-slot attestations: Say the adversary hears about an honest block proposal very early on in the propagation process. The adversary could then flood the network with alternative blocks or attestations using all the nodes it controls in the p2p network. Using sophisticated flooding strategies can make the adversary's attestations "more powerful", i.e. being heard relatively more when they can still tip a close race between different blocks into a desired direction. While the adversary can still use the tactics described above with attestations from previous slots, enabling same-slot attestations gives the attacker more room to pull this off successfully. This is based on gossiping strategies described by @joachimneu in this ethresear.ch post.

• It should be noted that this PR would affect the power of proposer score boosting (Proposer LMD Score Boosting #2353): Allowing same-slot attestations implies that it is easier for an adversarial actor to "over-power" the score boost by using saved up attestations as well as attestations from the current slot (especially if the adversary uses sophisticated flooding strategies on the p2p layer).

In optimistic scenarios this PR intuitively makes sense: Assuming honest majority committees, same-slot attestations should see honest validators outpace adversary validators. In other words, here the power of parallel attestations should create stickiness for the honest proposal, yay! However, when investigating adversarial conditions (as above) there seem to be strong reasons to not consider same-slot attestations.

Thanks to @joachimneu, @adiasg and @barnabemonnot for continued discussions.

[djrtwo]

I think that we want to move to only considering new attestations in batches at slot boundaries regardless of from this or previous slots. This combined with the proposer boost is a promising avenue to shore up the fork choice prior to a deeper redesign

Closing this for now