Apply proposer boost to first block in case of equivocation

[michaelsproul]

This PR modifies on_block so that it awards the proposer boost to the first block processed rather than the last block processed. This would cleanly mitigate the RPC unbundling attack described in this post: https://lighthouse-blog.sigmaprime.io/mev-unbundling-rpc.html

Because clients already exhibit a variety of behaviours in this case due to their attestation strategy and handling of RPC blocks, we might be able to roll this change out without a hard fork. If some clients implement the change while others do not, the worst case is that views may be split in the case of an equivocation, which can happen anyway.

Alternatives:

• Headlock: https://ethresear.ch/t/equivocation-attacks-in-mev-boost-and-epbs/.
• A scheme to remove attestation weight from equivocating blocks. The naive version of this is broken and exploitable by the attacker, but a restricted version might work. Something like: if the head block is an equivocation, set its weight to 0 and/or do not allow it to become head. In most cases we want to choose the parent of the equivocating head instead, but specifying this might be complicated.

TODO:

• Add tests
• Consider whether on_block should be idempotent if called again with the same block

[ppopth]

I haven't read the attack yet and I'm not an expert in this field, but it's quite cleaner to set proposer_boost_root only once per slot.

@adiasg what do you think?

[dapplion]

While other existing solutions may provide a better long term fix, this patch is way better than status quo

[adiasg]

I agree with setting the proposer_boost_root only once per slot. This change fixes a bug the proposer boost design -- should have been how we spec-ed proposer boost to begin with.

[hwwhww]

Hey @michaelsproul @adiasg

I added a test case today to verify the modification.

What's the status of this PR? Do we need a security analysis to verify if clients can update it uncoordinatedly or not?

[adiasg]

This change does not need coordination. If a malicious proposer makes multiple proposals, it may cause attesters from that slot to be split between those blocks - but as long as the next proposer is honest, everyone's fork choice will converge again. For a prolonged attack, the attacker needs to control many proposers in a range of slots.

Additionally, exploiting this requires the attacker to bear some slashing.

[michaelsproul]

@hwwhww I agree with Aditya that this is safe to roll out gradually. Thank you for writing the test 😊

I also think the idempotence concern from my OP is taken care of by the current impl: if the same block is re-applied to fork choice then it won't set the proposer boost again, but the proposer boost should already be set to this block from the first time it was applied.

[hwwhww]

This adjustment looks good to me. What do you think about bringing it to ACDC so we can merge it properly?

[dapplion]

Any reason to not merge this PR? All clients have this logic incorporated for multiple months, spec should reflect reality unless there's a strong security consideration

This was brough up on ACDC 115, with notes ethereum/pm#844 (comment)

FC proposer boost equivocation fix to "last call"

• no objection, will merge this PR by end of the week

[michaelsproul]

@dapplion I agree we should merge!