Consensus shouldn't produce blocks when there aren't enough validators for majority consensus

[n-hutton]

For below, >50% is assumed to be required for consensus.

This description regards the network behaviour when node(s) join but do not participate, so there are less participants than required for consensus.

The interpretation of what the committee is for a certain block is slightly incorrect. Currently, if there is a single node N0, and another node N1 requests to join the committee, but is absent, the behaviour is that:

• N0 will produce a block proposal B0 at height H0 which contains {N0, N1} as committee members
• N0 will vote on B0
• B0 needs votes from both N0 and N1 to be validated, this does not occur
• N0 times out
• N0 produces B1 at height H0 (a fork)
• If B1 contains validators {N0, N1} this cycle will continue

However, this isn’t quite correct. There should not be a continuous creation of forks in this scenario, rather, it should be that the chain stops until such a point that N1 comes online.

This has to do with which blocks are considered the first block the committee gets updated and who is needed in order to create an QC.
Correct flow:

• N0 will produce a block proposal B0 at height H0 which specifies N1 will be added to the committee (but is not in, yet)
• N0 will vote on B0
• B0 is ‘accepted’ by N0 -> QC{B0} is created which validates the committee as {N0, N1]
• The head is now B0. QC{B0} is floating around for use.
• If N0 would be the proposer for B1, it proposes this block B1 using QC{B0}
• If N0 was not the proposer, it will time out. It cannot form AggQC with QC{B0} because the block that would be proposed has committee {N0, N1}

The network now enters a steady-state condition: the head either B1 which contains QC{B0} or the head is B0 and N1 holds QC{B0} to itself.

Either way, successive timeouts will occur, but an AggQC will not be able to be formed with just N0 using QC{B0} - the network will not produce blocks until N1 comes online and starts producing NewView{QC{B0}} - it needs to have received the QC{B0} from either seeing B1 or by taking it from N0's NewView messages.

This arrangement is also more convenient for the dev experience because there isn’t continuous block formation and rollback, which means it is more likely to synchronize quickly if everything needs to be turned on and off again.