Robert Habermeier
424d61818e
* rejig candidate types a bit * adjust doc * describe basic PoV distribution * replace some straggling html links * address grumbles from review and fix links
4.2 KiB
Statement Distribution
The Statement Distribution Subsystem is responsible for distributing statements about seconded candidates between validators.
Protocol
ProtocolId: b"stmd"
Input:
- NetworkBridgeUpdate(update)
Output:
- NetworkBridge::RegisterEventProducer(
ProtocolId) - NetworkBridge::SendMessage(
[PeerId],ProtocolId,Bytes) - NetworkBridge::ReportPeer(PeerId, cost_or_benefit)
Functionality
Implemented as a gossip protocol. Register a network event producer on startup. Handle updates to our view and peers' views. Neighbor packets are used to inform peers which chain heads we are interested in data for.
Statement Distribution is the only backing subsystem which has any notion of peer nodes, who are any full nodes on the network. Validators will also act as peer nodes.
It is responsible for distributing signed statements that we have generated and forwarding them, and for detecting a variety of Validator misbehaviors for reporting to Misbehavior Arbitration. During the Backing stage of the inclusion pipeline, it's the main point of contact with peer nodes. On receiving a signed statement from a peer, assuming the peer receipt state machine is in an appropriate state, it sends the Candidate Receipt to the Candidate Backing subsystem to handle the validator's statement.
Track equivocating validators and stop accepting information from them. Forward double-vote proofs to the double-vote reporting system. Establish a data-dependency order:
- In order to receive a
Secondedmessage we have the on corresponding chain head in our view - In order to receive an
InvalidorValidmessage we must have received the correspondingSecondedmessage.
And respect this data-dependency order from our peers by respecting their views. This subsystem is responsible for checking message signatures.
The Statement Distribution subsystem sends statements to peer nodes and detects double-voting by validators. When validators conflict with each other or themselves, the Misbehavior Arbitration system is notified.
Peer Receipt State Machine
There is a very simple state machine which governs which messages we are willing to receive from peers. Not depicted in the state machine: on initial receipt of any SignedFullStatement, validate that the provided signature does in fact sign the included data. Note that each individual parablock candidate gets its own instance of this state machine; it is perfectly legal to receive a Valid(X) before a Seconded(Y), as long as a Seconded(X) has been received.
A: Initial State. Receive SignedFullStatement(Statement::Second): extract Statement, forward to Candidate Backing and PoV Distribution, proceed to B. Receive any other SignedFullStatement variant: drop it.
B: Receive any SignedFullStatement: check signature, forward to Candidate Backing. Receive OverseerMessage::StopWork: proceed to C.
C: Receive any message for this block: drop it.
Peer Knowledge Tracking
The peer receipt state machine implies that for parsimony of network resources, we should model the knowledge of our peers, and help them out. For example, let's consider a case with peers A, B, and C, validators X and Y, and candidate M. A sends us a Statement::Second(M) signed by X. We've double-checked it, and it's valid. While we're checking it, we receive a copy of X's Statement::Second(M) from B, along with a Statement::Valid(M) signed by Y.
Our response to A is just the Statement::Valid(M) signed by Y. However, we haven't heard anything about this from C. Therefore, we send it everything we have: first a copy of X's Statement::Second, then Y's Statement::Valid.
This system implies a certain level of duplication of messages--we received X's Statement::Second from both our peers, and C may experience the same--but it minimizes the degree to which messages are simply dropped.
And respect this data-dependency order from our peers. This subsystem is responsible for checking message signatures.
No jobs, StartWork and StopWork pulses are used to control neighbor packets and what we are currently accepting.