Design doc: Improve consensus bandwidth with asynchronous broadcast

[dB2510]

🎯 Problem to be solved

QBFT currently uses more bandwidth in p2p networking for full block proposals than in other duties. This is due to large size of data transferred in full block proposals.

🛠️ Proposed solution

The aim is to optimise bandwidth requirements in the QBFT protocol by decoupling data transfer from the consensus step. This can be achieved by removes the actual value from QBFT messages and performing consensus solely on the value root.

Proposed changes

1. QBFT Wire Format:
   • Define the structure for transmitting the value root instead of the entire value in QBFT messages.
2. Asynchronous Value Broadcasting:
   • Broadcast the proposal_value to all peers asynchronously as soon as it is received from the beacon node in fetcher component.
   • This asynchronous broadcasting will be independent of the consensus process, allowing peers to receive the value without waiting for consensus.
3. Consensus and Block Selection:
   • Adapt the consensus algorithm to perform consensus solely on the root of the proposal value.
   • Peers will select the proposed block (sent/received from asynchronous broadcast step) based on the resultant root of the consensus step, ensuring agreement across the network.
4. Requesting Proposal Value:
   • Implement a mechanism for peers to request the proposal value based on the root from the consensus step.
   • This feature enables peers that missed the asynchronous broadcast to obtain the required proposal value from other peers.
5. Utilizing "Verify Proposer Value Consensus":
   • Integrate the existing "verify proposer value consensus" component to work with this new change in consensus algorithm based on duty type.
6. Expected Bandwidth Optimization: By decoupling data transfer from the consensus step, this approach is expected to significantly reduce bandwidth requirements for large payloads.

Based on the feasibility and potential benefits outlined in this idea, a detailed design document should be created. The document should address the proposed changes, risks, implementation plan, testing strategy, and expected outcomes. We also need to put the design doc in front of QBFT authors to get some feedback.