Do not apply proposer boost to equivocated blocks in Gloas - #5535
Conversation
|
discussed again with @nflaig and figured out it's not really an issue 
the notes in the p2p could be helpful anyway (lodestar actually missed that, it's handled in ChainSafe/lodestar#9805) |
| # Note: Implementations SHOULD still pass this block to `on_block` so both blocks enter | ||
| # `store.blocks` and `is_proposer_equivocation()` can observe the equivocation. | ||
| proposer_slot_key = (block.slot, block.proposer_index) | ||
| if proposer_slot_key in seen.proposer_slots: | ||
| raise GossipIgnore("block is not the first valid block for this slot and proposer") |
There was a problem hiding this comment.
the executable gossip spec could do this now, ie. add equivocating blocks to fork choice store, this is required in several places in fork choice, eg. should_apply_proposer_boost or get_proposer_head
but doing this here seems wrong to me, so the comment says first block with valid signature but at that point, there was no signature check yet
the signature check is done further below on line 651 and also noticed we do the signature check before the proposer check itself, it seems same in lodestar but need to double check why that is
but if we wanna add a equivocating block via on_block it probably has to be done at the end of gossip validation unless we are fine with skipping some gossip checks
cc @jtraglia
2 participants
Motivation
glamsterdam-devnet-7, there are 2 blocks from the same proposer at slot 182523, lodestar received the orphaned first and boosted it. Nodes were stuck for a while then some slots later, this node built on this orphaned block. I think in this case, node should make a fair computation to know which block is head based on attestation scores only (not on proposer score).Description
should_apply_proposer_boost()should returnfalseif proposer is equivocationRelated to #3352