[Bug]: VE Persistence Not Reliable on Replay

[alexanderbez]

Summary of Bug

Due to the current design of CometBFT v0.38, in order for canonical VE from H to be provided to all validators at H+1, the proposer of H+1 "injects" the VE directly into the proposal as a "pseudo" tx, i.e [VEs, Tx1, TX2,...,TXn].

There are cases where computation of VE produces some state that the app wishes to persist to module(s). In ABCI++ 2.0 ADR, we proposed that we allow the app to have access to finalizeBlockState, so that it can write state that it wishes to be committed.

However, the solution falls short since during replay, CometBFT will NOT call ProcessProposal, thus putting the application in an incomplete view of state.

Version

v0.50.x alphas

Proposals

Instead of allowing the app access to finalizeBlockState to write state during ProcessProposal, we:

• Remove GetFinalizeState
• Define PreFinalizeBlockHook = func(ctx sdk.Context, req abci.RequestFinalizeBlock) error
• Call PreFinalizeBlockHook first thing in FinalizeBlock, i.e before BeginBlock

This will allow the app to persist computed VE state while also working gracefully during replay!

cc @facundomedica