Chain Selection (consensus) #201
Description
This is the core of the Praos consensus algorithm: You will receive multiple candidate blocks from upstream peers, and need to choose the 'best' to represent the current ledger state and become the base for block production, if this happens. 'Best' is defined in the Praos consensus rules.
Part of this selection is validation of proposed blocks from upstream. We will validate only blocks which would extend our current favoured tip (TBD!). Validation will be requested downstream by setting a new 'intent.validate' flag, as well as 'intent.store' since we will want them to store the result on the optimistic assumption this block will stick.
Validation will work on an "Apollo Flight Control" (Go/No-Go) model. The Consensus module will have a list of topics to expect ValidationResult messages on, and will proceed only when it has received a message on all of them (hence there is a positive as well as negative acknowledgement). If any topic indicates failure then the block will be rejected.
We will maintain only a single current ledger state, on the assumption that deep fork switches are relatively infrequent and we can replay state quickly, so there's no reason to optimise for them. Hence we need to store all blocks on each potential fork, and if a rollback happens, signal this downstream with BlockInfo.rolled_back, replaying all blocks from the fork point.
Once a fork point has reached 'k' blocks deep, any unadopted blocks attached to the unsuccessful branch should be deleted.
- get chainsync from upstreams
- fetch blocks from upstream (Multi-peer with consensus #205)
- run validation process (send out go/no-go requests) and wait for all "go". Any "no" is no (Consensus Validation Coordination / Flight Control #227)
- if we do a chain switch, recover other blocks and replay to get new tip (Handle Rollbacks #226)
How will we test this? (new ticket)