Simplify the consensus module: Move the calls to the BN out of the consensus module

[saltiniroberto]

Currently, the consensus module of a node is expected to communicate with the BN to retrieve the data to propose when the node becomes the leader of the current consensus instance. This creates a dependency between the consensus engine and the BN.

This issue proposes to remove such a dependency by moving the call to the BN asking for the data to propose out of the consensus engine.

In this case, the distributed consensus module would

• be parametrised by a validity function valid
• take as input a value vi by each of the nodes participating in the protocol
• ensure that any agreed upon value vo is such that:
  • valid(vo) = True
  • if all the nodes are honest, then vo corresponds to one of the values vi provided in input to one of the nodes participating in the protocol.

Pros

• Reduced complexity of the consensus module which imply
  • Reduced complexity in developing pluggable consensus protocols that can be used by the DVC

Cons

• Increased number of API calls to the BNs when using leader based consensus protocols. This is because the DVC will need to communicate with the BN to retrieve the data that the node will need to propose if they become the leader as opposed to communicating with the BN only when the node is actually the leader.

[saltiniroberto]

Another

Pros

is

• Increased decoupling of the software components

[OisinKyne]

I agree that coming to consensus on a duty separate to a BN is much cleaner, however I think Aditya has gone down the route proposed due to sometimes needing a BN to be able to decide on what should be the consensus block, hinted at here.

The implication is, in a simple BFT game, whatever the leader proposes that gets the required number of approvals from others should be the consensus/correct pick, however, it might not objectively be the correct pick in real life, it's just what the leader proposed and most people agreed to, the actual 'correct' choice for a duty would involve applying LMD-GHOST to the candidate duty, and rejecting the proposal if the candidate is not the fork with the heaviest weight. (However this has latency issues so it's not included in scope as mentioned in the above link)

If we didn't cross check candidate duties against a BN to see if it follows the fork choice rule correctly, we could unwittingly enable a balancing attack on the main network, because our DVs could be convinced to vote on things that are valid, but not the most correct as per LMD-GHOST, potentially enabling a sophisticated attacker to pull off short re-orgs with our support due to DVs not being able to include LMD-GHOST into our consensus algorithm.

[saltiniroberto]

Thanks @OisinKyne for raising this point. In my original proposal, I (wrongly) assumed that the validity check could have been performed without requiring communication between the DVC and the BN.

In this document, I have started exploring some of the possible design solutions for checking that the block proposed is on the correct fork.