Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

Add a Statement Gossip Subsystem section to the implementors guide #1151

Closed
wants to merge 3 commits into from
Closed

Add a Statement Gossip Subsystem section to the implementors guide #1151

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
0705a94
Move to this repo
expenses May 26, 2020
0e4f023
Add notes about message validation
expenses May 26, 2020
c469f91
Start summarising gossip protocols
expenses May 27, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 20 additions & 0 deletions roadmap/implementors-guide/guide.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,7 @@ There are a number of other documents describing the research in more detail. Al
* [Overseer](#Overseer)
* [Candidate Backing](#Candidate-Backing-Subsystem)
* [Statement Gossip](#Statement-Gossip-Subsystem)
* [Gossip Protocols](#Gossip-Protocols)
* [Data Structures and Types](#Data-Structures-and-Types)
* [Glossary / Jargon](#Glossary)

Expand Down Expand Up @@ -1030,6 +1031,7 @@ The following conditions need to be met for an incoming statement to be accepted

* The sender of the statement has to be in the validator set for the relay block.
* If the statement is `Valid` or `Invalid`, then the candidate that the hash refers to must be known.
* As only `MAX_CHAIN_HEADS` (currently set to 5) competing parachain heads are accepted at a time, if the statement is `Seconded`, then there must be less than `MAX_CHAIN_HEADS` other candidate receipts for the parachain block.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

then there must be less than MAX_CHAIN_HEADS other candidate receipts for the parachain block.

This is not accurate - max chain heads is about how many relay chain heads a particular peer is allowed to say they are interested in, not about how many candidates there are for any specific relay chain head.

* The statement signature must be valid.

I have a basic implementation of this code on the [`ashley-test-statement-gossip-subsystem`](https://github.com/paritytech/polkadot/tree/ashley-test-statement-gossip-subsystem) branch.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In case you would like to have input on this, would you mind opening up a pull request? That would make discussions a lot easier.

Expand All @@ -1043,6 +1045,24 @@ I have a basic implementation of this code on the [`ashley-test-statement-gossip

----

## Gossip Protocols

A lot of a relay chain's communication happens via gossiping messages. To avoid this becoming an attack vector, we want to use [Bounded Gossip Protocols](https://github.com/w3f/research/blob/master/docs/polkadot/networking/0-overview.md#bounded-gossip-protocols).

### Functionality

Several components make up a gossiping system:

* A network implementation, that contains things like the actual connections to peers.
* A propagation pool of messages.

When the node wants to gossip a message:
* The message is put into the propagation pool and stays there until cleaned up.
* The message is sent out to the nodes that it is currently connected to.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

However, this is not accurate and does not capture all of the aspects of bounded gossip protocols. We only send out messages to peers that pass the filtration criterion for that peer. And then later on we may "unlock" those messages once we are aware of the filtration criterion for that peer changing.


When a new node connects to our node:
* All messages in the propagation pool are sent to it, and we receive all of its propagation pool messages.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here - we only send messages to a peer that pass the filtration-criterion allowed_k. At this level of detail, we can paraphrase that as a function is_message_allowed(peer, msg) which gossip protocols need to implement


## Data Structures and Types

[TODO]
Expand Down