Discard attestations with wrong target after 5 slots

[potuz]

Attestations with wrong target after 5 slots are useless in Altair and thus should be ignored.

See

https://github.com/ConsenSys/teku/issues/4412

[lyzs90]

I do believe this is already implemented: https://github.com/prysmaticlabs/prysm/blob/develop/beacon-chain/core/altair/attestation.go#L290-L291

[potuz]

I do believe this is already implemented: https://github.com/prysmaticlabs/prysm/blob/develop/beacon-chain/core/altair/attestation.go#L290-L291

The quoted check just checks for the correct source, did you mean something else?

[lyzs90]

Correct me if I'm wrong: this participation flag is false if the delay is > 5 slots, hence the attestation will not be processed.

Or were you looking to filter prior to this, say OnAttestation?

[potuz]

Correct me if I'm wrong: this participation flag is false if the delay is > 5 slots, hence the attestation will not be processed.

That participation flag is false but that doesn't mean that the attestation won't be processed. An attestation can have false timely source (as is the case of the check you highlighted) but have true timely target. The point of the issue is that any attestation that has wrong target after 5 slots will have false all timely flags and therefore it only occupies space in blocks if included.

[lyzs90]

Thanks for clarifying. I think I got the gist of it: these flags are for facilitating reward accounting. By the time the attestation reaches this stage, it's bound to be included in the block.

[terencechain]

@Iyzs90 I'm going to close this but feel free to reopen if there's any questions

[lyzs90]

@terencechain isn't the issue still relevant?

[potuz]

This issue is very much still open

[lyzs90]

Cool, I think I'm getting close. Similar to the Teku implementation, the filter can be placed prior to block proposal: https://github.com/prysmaticlabs/prysm/blob/develop/beacon-chain/rpc/prysm/v1alpha1/validator/proposer_attestations.go

[potuz]

Cool, I think I'm getting close. Similar to the Teku implementation, the filter can be placed prior to block proposal: https://github.com/prysmaticlabs/prysm/blob/develop/beacon-chain/rpc/prysm/v1alpha1/validator/proposer_attestations.go

I'd support if there's an earlier path for this. Any delay in packing attestations hurts block proposals and may affect broadcast timing. If we could get rid of those attestations in the pool earlier it would be best I think.

[lyzs90]

@potuz Do let me know if that MR is on the right track, I think this is as early as it gets for filtering during block proposal. An alternative is while pruning the attestation pool, we could check the head and attempt filtering there?