Attestations for blocks from incorrect slots

[djrtwo]

@paulhauner Brought up an interesting scenario in which an attestation votes for a beacon block root from a future slot.

With respect to the state transition, it doesn't really matter. It just looks like an incorrect head root and thus won't be rewarded for the head vote. This operates the same way as though the head voted on was from a different fork.

The fork choice on the other hand currently handles this in a degenerate manner. The only check currently when inducting an attestation into latest messages is that the target_epoch is greater than the previous latest message for the validator and that the slot of the attestation is not in the future. We make no checks wrt beacon_block_root, but we store the beacon_block_root into the latest_messages store for that validator.

This results in a case in which the validator can successfully influencing the fork choice of a head block later than their assigned slot and can even use an attestation from a past epoch to cast a vote on a block from a future (wrt to the attestation slot) epoch.

I haven't fully assessed the attack domain here, but the simple solution to simply remove this case from the attack surface is to make these attestations invalid wrt the fork choice.

[nrryuya]

an attestation from a past epoch to cast a vote on a block from a future (wrt to the attestation slot) epoch

IMO the validity condition that any attestation must not attest to a future block is must-have in any slot-based approach. Otherwise, the saving strategy becomes much easier; an attacker can do saving and then start decoy-flip-flop attack without network failure. If we add this condition, an attacker must wait or manually cause a network failure to prevent the convergence for saving.
I just published a more detailed post here.

block from current epoch casting a vote for a block older than the attestation slot.

This should be allowed because the sender of the attestation might have failed to receive the block from the slot?

[djrtwo]

This should be allowed because the sender of the attestation might have failed to receive the block from the slot?

Yep! wasn't thinking. good catch!