Attestations With Different Target Roots Can Be Dropped

[nisdas]

In Altair,

process_attestation is modified as linked: https://github.com/ethereum/eth2.0-specs/blob/dev/specs/altair/beacon-chain.md#modified-process_attestation

Rewards for proposers are now dependant on the participation flags of the attestation. This is determined according to the snippet below:

 # Participation flag indices
    participation_flag_indices = []
    if is_matching_source and state.slot <= data.slot + integer_squareroot(SLOTS_PER_EPOCH):
        participation_flag_indices.append(TIMELY_SOURCE_FLAG_INDEX)
    if is_matching_target and state.slot <= data.slot + SLOTS_PER_EPOCH:
        participation_flag_indices.append(TIMELY_TARGET_FLAG_INDEX)
    if is_matching_head and state.slot == data.slot + MIN_ATTESTATION_INCLUSION_DELAY:
        participation_flag_indices.append(TIMELY_HEAD_FLAG_INDEX)

Using these flags, the rewards for an attestation are determined for both proposer and attester. However the introduction of this condition for TIMELY_SOURCE_FLAG_INDEX may lead to issues:

    if is_matching_source and state.slot <= data.slot + integer_squareroot(SLOTS_PER_EPOCH):

With the current mainnet SLOTS_PER_EPOCH being 32, integer_squareroot(SLOTS_PER_EPOCH) of it is 5. This only gives a threshold of 5 slots for an attestation to be processed for its timely source reward. The initial reason given was that it incentivizes proposers to pack in attestations faster. While this makes sense this also introduces a corresponding disincentive. If a proposer receives an attestation with a matching source but dissimilar target, then this creates a tight boundary for the attestation to be included. Some situations in which target roots can be different:

• There is an ongoing network fork, so there is a larger split between different groups of validators on what the target root is at a certain epoch. During this period you can start assuming that attestation aggregation is imperfect, so blocks might actually end up being packed. A validator(different target root) could very well likely end up with an inclusion distance larger than 5. In the event that happens, their entire attestation will be dropped as the proposer receives no reward for including it.

• A validator is assigned to attest during an epoch transition. However, the validator ends up receiving the block much later than expected( as has been observed in mainnet during slot 0). Due to local network/peering issues a validator is only able to broadcast its attestation to a small set of peers. This ends up leading to its inclusion distance with being larger than 5. In this case this particular validator's attestation is completely dropped.

The former is unlikely to happen in mainnet , however the latter has a much higher likelihood of occurring. Currently in mainnet attesters already get a smaller reward due to an incorrect target root being voted for( due to late blocks). However with this change it is likely that an attester could end up losing their whole reward and be penalised if it ever has a late broadcast of its attestation.

[ralexstokes]

in general, the tighter the specification, the less attack surface there is. obviously this has to be balanced w/ real world conditions as we can't finalize a chain we can't build :)

i'd say to keep an eye on these sorts of metrics in altair testnets and as always a close eye on them as we move to mainnet. but it is worth having some "performance pressure" as it incentivizes client implementations to do things like minimize the "lagging slot 0" phenomena you mention (and i'm sure there are or will be others like it in the future...)

[nisdas]

i'd say to keep an eye on these sorts of metrics in altair testnets and as always a close eye on them as we move to mainnet. but it is worth having some "performance pressure" as it incentivizes client implementations to do things like minimize the "lagging slot 0" phenomena you mention (and i'm sure there are or will be others like it in the future...)

Fair enough, although there will be times where it is a localized network issue for the validator and the conversation goes from 'why is my reward less' to 'why am I being penalised'. Early Altair testnets will give us a good gauge of how likely we think this might happen.

[potuz]

The thing that worries me about this issue is that Altair may not be a good gauge at all. There is no reason to expect more forking while the network is pure consensus. There are more chances however after the merge, and since this is scheduled to be implemented in a previous fork, if it actually becomes an issue we will only find out later and may need to be reverted.

[djrtwo]

EDIT: I was mixing up source and target time limits. All of the below is inaccurate

~~Right, it’s potentially bad for network health to tightly couple target correctness and timeliness in this flag because we use it in process_justification_and_finalization to select the set for finality https://github.com/ethereum/eth2.0-specs/blob/dev/specs/altair/beacon-chain.md#justification-and-finalization~~

~~So if latency is 5+ slots, we can't get onchain finality even if there are >2/3 correct targets~~

~~I would argue we need to have an additional flag for TARGET_CORRECT_FLAG to independently track this for finality. Don't think we need to add a particular incentive for that flag~~

[leolara]

I am closing this issue because it seems stale. Please, do not hesitate to reopen it if this is a mistake