Expand PoV Distribution section and improve candidate types

[rphmeier]

This is based on #1283

Closes #1228

This proposes a gossip-like system for PoV Distribution where all peers fetch PoVs and peers notify each other of what they're waiting for. It requires that Statement Distribution notify it of all SignedFullStatements, which I find to be a clean abstraction. In the future, when we redesign this to directly connect to validators and get the information from them, the same information will be needed, just used in a different way.

[mxinden]

Just to make sure, are we attaching a version to these protocol ids somewhere? I.e. something along the lines of b"povd/1"?

That would help tremendously evolving the protocol later in the future.

[rphmeier]

These are attached to the network bridge. I figure these can handle versioning internally since the network bridge protocol is so generic

[mxinden]

I see. The network bridge would treats the protocol ids as opaque strings. Thereby later a subsystem could even just listen for both povd and povd/2 during the transition period, correct?

[rphmeier]

Yeah, that's right

[coriolinus]

Suggested change

	- PoVs will flow transitively across a network of honest nodes, stemming from the validators that originate them.
	- PoVs will flow transitively across a network of honest nodes, stemming from the collators that originate them.

[rphmeier]

In this case, I do mean validators, but the phrasing could be more clear. It's about seconding leading to dataflow, not collation.

[coriolinus]

I like the direction you're taking the candidate receipt types!

…

On Mon, Jun 22, 2020 at 8:35 AM Max Inden ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In roadmap/implementors-guide/src/node/backing/pov-distribution.md <#1294 (comment)>: > @@ -4,10 +4,118 @@ This subsystem is responsible for distributing PoV blocks. For now, unified with ## Protocol -Handle requests for PoV block by candidate hash and relay-parent. +`ProtocolId`: `b"povd"` Just to make sure, are we attaching a version to these protocol ids somewhere? I.e. something along the lines of b"povd/1"? That would help tremendously evolving the protocol later in the future. ------------------------------ In roadmap/implementors-guide/src/node/backing/pov-distribution.md <#1294 (comment)>: > ## Functionality -Implemented as a gossip system, where `PoV`s are not accepted unless we know a `Seconded` message. +This network protocol is responsible for distributing [`PoV`s](../../types/availability.md#proof-of-validity) by gossip. Since PoVs are heavy in practice, gossip is far from the most efficient way to distribute them. In the future, this should be replaced by a better network protocol that finds validators who have validated the block and connects to them directly. Would it make sense to link to https://github.com/w3f/research/blob/master/docs/polkadot/networking/3-avail-valid.md here? ------------------------------ In roadmap/implementors-guide/src/node/backing/pov-distribution.md <#1294 (comment)>: > ## Functionality -Implemented as a gossip system, where `PoV`s are not accepted unless we know a `Seconded` message. +This network protocol is responsible for distributing [`PoV`s](../../types/availability.md#proof-of-validity) by gossip. Since PoVs are heavy in practice, gossip is far from the most efficient way to distribute them. In the future, this should be replaced by a better network protocol that finds validators who have validated the block and connects to them directly. + +This protocol is described in terms of "us" and our peers, with the understanding that this is the procedure that any honest node will run. It has the following goals: + - We never have to buffer an unbounded amount of data + - PoVs will flow transitively across a network of honest nodes, stemming from the validators that originate them. + +As we are gossiping, we need to track which PoVs our peers are waiting for to avoid sending them data that they are not expecting. It is not reasonable to expect our peers to buffer unexpected PoVs, just as we will not buffer unexpected PoVs. So notification to our peers about what is being awaited is key. However it is important that the notifications system is also bounded. ⬇️ Suggested change -As we are gossiping, we need to track which PoVs our peers are waiting for to avoid sending them data that they are not expecting. It is not reasonable to expect our peers to buffer unexpected PoVs, just as we will not buffer unexpected PoVs. So notification to our peers about what is being awaited is key. However it is important that the notifications system is also bounded. +As we are gossiping, we need to track which PoVs our peers are waiting for to avoid sending them data that they are not expecting. It is not reasonable to expect our peers to buffer unexpected PoVs, just as we will not buffer unexpected PoVs. So notifying our peers about what is being awaited is key. However it is important that the notifications system is also bounded. Not sure whether this was wrong in the first place. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1294 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3V4TXCKHHLYJMT2VW3D3DRX33RNANCNFSM4ODCQPPQ> .

-- Wichtige Mitteilung Diese Mitteilung wurde von Parity Technologies Deutschland GmbH kommuniziert, eine im Handelsregister des Amtsgerichtes Charlottenburg unter HRB 190583 B registrierte Gesellschaft mit beschränkter Haftung (GmbH). Die Geschäftsführerin der GmbH ist Frau Dr. Jutta Steiner. Der registrierte Geschäftssitz ist Glogauer Straße 6 in 10999 Berlin, Deutschland.  Diese Mitteilung enthält Informationen welche vertraulich sind und welche eventuell die Vertraulichkeit der Rechtsberatung ("Anwaltsgeheimnis") berühren. Sie ist ausschließlich für den/die vorgesehenen Empfänger bestimmt. Wenn Sie nicht der/die beabsichtigte(n) Empfänger sind, benachrichtigen Sie bitte [email protected] <mailto:[email protected]> und löschen Sie diese Nachricht sofort. Unsere Datenschutzrichtlinie, einschließlich die Art und den Umfang von personenbezogenen Daten, die wir erfassen, wie wir diese Daten erfassen und verarbeiten, an wen wir sie in Bezug auf die von uns angebotenen Dienste weitergeben dürfen, sowie bestimmte Rechte und Optionen, die Sie in dieser Hinsicht haben, finden Sie unter: https://www.parity.io/privacy/ <https://www.parity.io/privacy/>