specs: consensus leader selection & fork choice

[liamsi]

Summary

Currently, the specs do not define the concrete Leader selection and the Fork Choice rule: https://github.com/celestiaorg/celestia-specs/blob/06be92043f8ec39bab4222708c0fb44eb7fbca60/src/specs/consensus.md#fork-choice

IMO, these could be very short paragraphs (one or two sentences) that give an overview and refer to tendermint for the details. If there is anything LL specific to consider here (e.g. any difference that stems from the minority assumption), it should also be mentioned somewhere.

Sub-Tasks

We also need to consider:

• [x] timeouts
• [x] data becoming available after the fact
• [ ] erasure coding fraud proofs
• [x] fork choice with DAS (ref: https://github.com/celestiaorg/lazyledger-core/issues/321, celestiaorg/celestia-specs#179)

partly includes: celestiaorg/celestia-node#1134

[liamsi]

Actually, wouldn't the fork-choice rule be more nuanced depending on what kind of nodes are trying to "choose forks"? This is certainly something we have to think carefully about. With an honest majority assumption things are easy: actual forks do not really exists, as nodes only accept block that were committed to by > 2/3 of the validators. This can be mentioned with a reference to tendermint. But things get much more complicated, especially the edge-cases, if we do not assume an honest majority. I think this is something the @informalsystems team can likely help with, too.

[adlerjohn]

For now referencing the Tendermint fork choice rule and leaving it at that is probably sufficient. But you're right that the full specification of this is non-trivial, and I'm not sure Tendermint has a full written specification for its fork choice rule at this time.

[adlerjohn]

Also see: https://github.com/lazyledger/lazyledger-core/issues/321

[adlerjohn]

We also need to consider:

1. timeouts
2. data becoming available after the fact
3. erasure coding fraud proofs

[rootulp]

Can link to Tendermint docs