Investigate on statement distribution subsystem

[axaysagathiya]

Issue summary

This parachain subsystem is responsible for

• distributing signed statements that we have generated and
• forwarding statements generated by our peers

[axaysagathiya]

There are 2 versions of the statement distribution protocol.

• v1 is for before async backing support
• v2 is designed for async backing

[axaysagathiya]

Statement distribution subsystem V2

• Validators must have statements, candidates, and persisted validation from all other validators.
• phases of statement distribution subsystem design
  • in group distribution - cluster - for legitimate fresh candidates
  • out group distribution - grid - to quickly get backed candidates in many validators
• validators request candidates lazily through request/response protocols.
  • can request the full CommittedCandidateReceipt and PersistedValidationData, along with statements

[axaysagathiya]

Statement distribution subsystem V1

• On receiving StatementDistributionMessage::Share we make sure to send messages to our backing group in addition to random other peers, to ensure a fast backing process and getting all statements quickly for distribution.

• This subsystem tracks equivocating validators and stops accepting information from them. It establishes a data-dependency order:

  • In order to receive a Seconded message we have the corresponding chain head in our view
  • In order to receive a Valid message we must have received the corresponding Seconded message

• This subsystem is responsible for checking message signatures.

Peer Receipt State Machine

A: Initial State. Receive SignedFullStatement(Statement::Second): extract Statement, forward to Candidate Backing, proceed to B. Receive any other SignedFullStatement variant: drop it.

B: Receive any SignedFullStatement: check signature and determine whether the statement is new to us. if new, forward to Candidate Backing and circulate to other peers. Receive OverseerMessage::StopWork: proceed to C.

C: Receive any message for this block: drop it.

Large statements

• The receiver of large statement message needs to request the actual payload via request/response by means of a StatementFetchingV1 request.

[axaysagathiya]

To implement v1, we need to handle the main 3 kinds of messages.

1. messages received from other subsystems
   • share signed statements with other validators
   • notification of candidate being backed
   • network bridge update
2. request the large statements from the other validators
3. respond to the large statement to the other validators