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

expand validity subsystems descriptions independent of subsystems overview #1185

Merged
rphmeier merged 19 commits into from
Jun 10, 2020
Merged

expand validity subsystems descriptions independent of subsystems overview #1185

Changes from 1 commit
Commits
Show all changes
19 commits
Select commit Hold shift + click to select a range
cbaf2f3
expand subsystems descriptions independent of subsystems overview
coriolinus Jun 2, 2020
45674fa
Reorder subsystem descriptions, add some messages
coriolinus Jun 2, 2020
cc68890
add some more message types, Statement Distribution overview
coriolinus Jun 2, 2020
4679c5f
add more detail on Statement Distribution, Misbehavior Arbitration
coriolinus Jun 2, 2020
d22b23a
Merge remote-tracking branch 'origin/master' into prgn-guide-subsyste…
coriolinus Jun 3, 2020
97de4c4
intentionally punt MA details for a future PR
coriolinus Jun 3, 2020
c938d16
reduce duplication from overseer signal handling
coriolinus Jun 4, 2020
1d6337b
reword for clarity
coriolinus Jun 4, 2020
0803ee5
clarify: other modules and subsystems also get to talk to the network
coriolinus Jun 4, 2020
572118c
Merge remote-tracking branch 'origin/master' into prgn-guide-subsyste…
coriolinus Jun 9, 2020
07df04a
finish current work on candidate selection
coriolinus Jun 9, 2020
45a548a
update candidate backing subsystem description according to current t…
coriolinus Jun 9, 2020
460d581
update mechanism for candidate backing to report collator misbehavior…
coriolinus Jun 9, 2020
f084834
sketch out the peer receipt state machine
coriolinus Jun 9, 2020
a46bd64
Fix typo in roadmap/implementors-guide/guide.md
coriolinus Jun 9, 2020
ec87322
Don't specify 'peer validators', as messages from non-validator peers…
coriolinus Jun 9, 2020
e8137ad
clarify instancing of peer receipt state machine
coriolinus Jun 9, 2020
d8085fa
add section on peer knowledge tracking
coriolinus Jun 9, 2020
6fc1316
fix typo in roadmap/implementors-guide/guide.md
coriolinus Jun 9, 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
Prev Previous commit
Next Next commit
clarify instancing of peer receipt state machine
  • Loading branch information
@coriolinus
coriolinus committed Jun 9, 2020
commit e8137ad3a18a15f23fbbba022f88f732023e442a
2 changes: 1 addition & 1 deletion roadmap/implementors-guide/guide.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1104,7 +1104,7 @@ Statement Distribution is the only validity module subsystem which has any notio

#### 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 `SignedStatement`, validate that the provided signature does in fact sign the included data.
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 `SignedStatement`, 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)` from peer `A`.

A: Initial State. Receive `SignedStatement(Statement::Second)`: extract `Statement`, forward to Candidate Backing, proceed to B. Receive any other `SignedStatement` variant: drop it.
Copy link
Contributor

@rphmeier rphmeier Jun 9, 2020

Choose a reason for hiding this comment

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

It should be fine to receive a Valid(X) signed by A before a Seconded(Y). I can see the justification for not allowing it, but it does not seem to get us much of a win. Requiring that we know Seconded(Y) before Valid(Y) already restricts us to a bounded set of messages, and is simpler to implement (as it is a more focused condition).

Copy link
Contributor Author

@coriolinus coriolinus Jun 9, 2020

Choose a reason for hiding this comment

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

Yes, I'll add that this state machine applies for each individual parablock candidate, not for all candidates from a particular validator.

Copy link
Contributor

@rphmeier rphmeier Jun 9, 2020 •
edited
Loading

Choose a reason for hiding this comment

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

And then there should be a small note in there about knowledge tracking for our peers, so we know who knows which candidates based on what they've sent or what we've sent them (this needs to be scoped to active relay-parent set)

B: Receive any `SignedStatement`: extract `Statement`, forward to Candidate Backing. Receive `OverseerMessage::StopWork`: proceed to C.
Expand Down