Streamlining validation logic across proposal lifecycle

[grarco]

Reported by Informal Systems.

Description

Any stateless validation done when adding a transaction to the mempool does not need to be done again in prepare proposal. This is because a proposal from an honest proposer only includes transactions from its mempool. It is then guaranteed that any transaction in such a proposal has passed all those checks.
The same reasoning could be applied to process proposal and finalize block: under the assumption that 2f+1 of
the voting power is controlled by honest validators, CometBFT guarantees that any block in a finalize block call has been validated by at least one honest validator via process proposal. Nevertheless, if a larger set of validators is compromised, this may not be true anymore. In such a case, one may want to replicate any validity checks done in process proposal in finalize block to guarantee the validity of histories under all circumstances.
We have identified one redundant validity check in prepare proposal and one in finalize block.

Problem Scenarios

• Redundant signature check in mempool validate code and prepare proposal code
• Redundant signature check in process proposal code and finalize block code

Recommendation

We recommend removing the duplicated signature check from prepare proposal. Regarding the checks in finalize block, we recommend proceeding differently depending on whether the team wants to guarantee the validity of histories under all circumstances:

• If required, we recommend making sure that all validity checks in process proposal are replicated in finalize block.
• If not required, we recommend removing the duplicated checks from finalize block.