Investigate 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

plan

• [x] read host implementors guide
• [x] Observe rust code and figure out what we need to implement
• [ ] Understand Rust code and raise issues for all the necessary tasks.

[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 (validated) 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
   • message to send a request to other validators
   • message to get an update of available peers to try fetching statements
   • report a peer who behaves worse than just not providing data
   • fetched finished
3. respond to the large statement to the other validators
   • check if we have data and send it back to the requester

[axaysagathiya]

We need to have a separate Goroutine that will simultaneously process the requests we get from other validators to fetch the large statement for a candidate.

This Goroutine should ensure we process only some predecided number of requests simultaneously. Process the message and send back the large statement to the requester