In the current implementation of ProcessProposal (and spec?), it is called just after doing Comet-level validations on the received proposal block.

However, there are some cases where the local node can conclude that the received proposal has already been processed and accepted by another correct node's ProcessProposal.

Since ProcessProposal's main goal is to detect and drop bad proposals from byzantine validators, calling ProcessProposal on a proposal that we know has passed ProcessProposal elsewhere is, at minimum, suboptimal.

These are the cases where we know ProcessProposal has already accepted the proposal at some correct node:

• If the proposal's POLRound is -1 and the proposed block matches the one locally locked (part of line 23 of the arXiv algorithm)
• If the proposal's POLRound is not -1 and less than the current round, and
  • we have received 2f+1 (worth of voting power) valid prevotes for the proposed block in POLRound, and
    • either POLRound is greater than or `LockedRound?
    • or the proposed block matches the one locally locked
    • (line 29 of the arXiv algorithm)
• If the proposed block matches our ValidBlock

In the arXiv algorithm, this is equivalent to removing $valid(v)$ from line 29, and changing line 23 as follows:
if $(lockedRound_p = −1 ∧ valid(v)) ∨ lockedValue_p = v$ then.
Also, we assume that $valid(v)$ does not include ProcessProposal in lines 36 and 50 (do we really need to call $valid(v)$ at all there?).

This is a similar reasoning to the one followed to minimize calls to timely in the Proposer-Based Timestamp (PBTS) specification.

@hvanz @lasarojc @BrendanChou