Proposer LMD Score Boosting

[adiasg]

Edit: Renamed from "Fix LMD balancing attack" to "Proposer LMD Score Boosting"

This PR implements a fix for the LMD balancing attacks, as described here.

Proposer Score Boost

A new "proposer score boost" has been introduced, which boosts the LMD score of blocks that are received in a timely manner. The boost increases the score of the block by committee_weight // 4 for that slot. If a block for slot X is received in the first SECONDS_PER_SLOT // ATTESTATION_OFFSET_QUOTIENT (= 4) seconds of the slot, then the block receives the boost for the duration of slot X. After slot X is over, the boost is removed and the usual LMD score calculations from only attestations are done.

The boost is not applied to blocks that are not received in the first SECONDS_PER_SLOT // ATTESTATION_OFFSET_QUOTIENT seconds of their slots, and this PR does not affect LMD score calculations for such blocks.

In the above example:

• block B is received in a timely manner and qualifies for the boost. B's score is boosted for only slot X.
• block C is not received in a timely manner and does not qualify for the boost.

Summary of Changes

• Parameters:
  • Added new parameter ATTESTATION_OFFSET_QUOTIENT, which is used to specify the time at which attestations are produced within a slot
• Store:
  • Added new field store.proposer_score_boost, which is a special LatestMessage that stores the boost
• Fork Choice:
  • Updated get_latest_attesting_balance to take into account store.proposer_score_boost
  • Updated on_block & on_tick to appropriately set/reset store.proposer_score_boost
• Testing:
  • Added test for store.proposer_score_boost accounting
  • Updated existing tests to work correctly after introducing proposer score boosting

[adiasg]

Note: First merge PR #2292 into dev, then merge this into dev

[joachimneu]

Following the general approach of balancing, a recent attack dispenses with adversarial network delay and can be found in Appendix I of this manuscript.

[adiasg]

This fix makes the synchrony assumption of latency < SECONDS_PER_SLOT // ATTESTATION_OFFSET_QUOTIENT (= 4) seconds, and hence prevents the new variant of the attack under synchronous network conditions.

In general, this fix prevents attacks that rely on balancing different forks by utilizing the LMD fork choice score. This is because a few consecutive honest proposers are able to force a single winner from such balanced forks.

[joachimneu]

If I am not mistaken, then the analysis here misses two aspects:

• The adversary only needs to release sway votes for honestly led slots, not for adversarially led slots.
• Adversarial votes can affect a 2x change in score, due to LMD.

If this is so, then an adversary controlling 1/9 = ~0.11 fraction of stake can attack the protocol with the fix for Wp = 1/4*W.

[michaelsproul]

I think the boost also incentivises proposers to orphan late blocks which they've seen, which could be beneficial as late blocks continue to cause issues on mainnet.

In the case where the proposer for slot X publishes their block late, the proposer at slot X + 1 might want to orphan it, even if they've received it and their fork choice selects it as the head. If block X has <W/4 votes then the proposer for slot X + 1 can propose a (timely) block of their own with the same parent as block X, which will then outrank block X thanks to the W/4 boost. If they do this they stand to gain extra rewards from the inclusion of attestations from slot X.

I'd argue that this ability to aggressively orphan late blocks is actually a good thing because it sends a clear signal to the previous proposer that their block was low quality. At the moment we often see late blocks without many votes making it into the canonical chain because they are seen by the next proposer before the start of the next slot. In the pathological case consider a block published 8 seconds into the slot which receives no attestations but still arrives at all nodes before the next slot.

Late blocks hamper consensus and penalise attesters as they invalidate head (and sometimes target) votes for slot X, due to honest attesters voting for X's parent. If we orphan them then at least we improve agreement on target (if X % 32 == 0), and reward the correct-target attesters. Post-Altair there's no way to salvage the head vote rewards for the slot X attesters, as they either voted for a skipped slot and failed the timeliness condition (if block X is orphaned), or voted for the wrong head (if block X is not orphaned).

My hope is that if clients adopt the orphaning logic then it will pressure late block publishers into getting their act together. I suspect that at the moment their metrics don't detect the late blocks they're publishing because late blocks are still rewarded when they make it into the chain. The philosophical question is whether or not it's worth explicitly going against what fork choice says the head should be in order to implement the aggressive orphaning, or whether fork choice should be extended with a notion of a "proposer head" that allows us to count this behaviour as honest.

[adiasg]

Closed in favor of #2730. This PR was based on # #2292 and had major conflicts with dev.
#2730 now does not have the (block, epoch)-fork choice from #2292.