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

Update guide candidate validation module #1264

Merged
rphmeier merged 5 commits into from
Jun 17, 2020
Merged

Update guide candidate validation module #1264

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
8e809af
first pass updating candidate validation module in the guide
coriolinus Jun 15, 2020
41b5ec2
expand candidate validation functionality section
coriolinus Jun 16, 2020
6ea7b2c
Merge remote-tracking branch 'origin/master' into prgn-candidate-vali…
coriolinus Jun 16, 2020
ac6fabe
add candidate fetch; validation requires PoV to be provided
coriolinus Jun 16, 2020
0c404e7
remove candidate fetch
coriolinus Jun 17, 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
16 changes: 13 additions & 3 deletions roadmap/implementors-guide/src/node/utility/candidate-validation.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,12 +2,22 @@

This subsystem is responsible for handling candidate validation requests. It is a simple request/response server.

A variety of subsystems want to know if a parachain block candidate is valid. None of them care about the detailed mechanics of how a candidate gets validated, just the results. This subsystem handles those details.

## Protocol

Input:
Input: [`CandidateValidationMessage`](../../type-definitions.html#validation-request-type)

- [`CandidateValidationMessage`](../../type-definitions.html#validation-request-type)
Output: [`Statement`](../../type-definitions.html#statement-type) via the provided `Sender<Statement>`.

## Functionality

Given a candidate, its validation code, and its PoV, determine whether the candidate is valid. There are a few different situations this code will be called in, and this will lead to variance in where the parameters originate. Determining the parameters is beyond the scope of this subsystem.
Given the hashes of a relay parent and a parachain candidate block, and either its PoV or the information with which to retrieve the PoV from the network, spawn a short-lived async job to determine whether the candidate is valid.
Copy link
Copy Markdown
Contributor

@rphmeier rphmeier Jun 16, 2020

Choose a reason for hiding this comment

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

The old line said:

Determining the parameters is beyond the scope of this subsystem.

I find this vastly superior to a system where the validation subsystem is responsible for fetching the PoV. The caller will know best where to get the PoV.

Copy link
Copy Markdown
Contributor Author

@coriolinus coriolinus Jun 16, 2020

Choose a reason for hiding this comment

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

I didn't know what "determining the parameters" meant, in the old line.

If the caller is responsible for fetching the PoV, then what is this subsystem supposed to do when it receives a CandidateValidationMessage::Validate with PoVOrigin::Network? If it's the caller's responsibility, then we don't need PoVOrigin at all; we can just make the PoV one of Validate's fields.

Copy link
Copy Markdown
Contributor

@rphmeier rphmeier Jun 16, 2020

Choose a reason for hiding this comment

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

If it's the caller's responsibility, then we don't need PoVOrigin at all; we can just make the PoV one of Validate's fields

Yeah, this is what I'd advocate for.

Copy link
Copy Markdown
Contributor Author

@coriolinus coriolinus Jun 16, 2020

Choose a reason for hiding this comment

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

OK, I can make that change.


Each job follows this process:

- Get the full candidate from the current relay chain state
- Check the candidate's proof
> TODO: that's extremely hand-wavey. What does that actually entail?
- Generate either `Statement::Valid` or `Statement::Invalid`. Note that this never generates `Statement::Seconded`; Candidate Backing is the only subsystem which upgrades valid to seconded.
Copy link
Copy Markdown
Contributor

@rphmeier rphmeier Jun 17, 2020

Choose a reason for hiding this comment

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

I'd prefer to return true/false or Valid/Invalid on the channel as opposed to the Statement type which can included Seconded - doesn't make sense here.

- Return the statement on the provided channel.
9 changes: 1 addition & 8 deletions roadmap/implementors-guide/src/type-definitions.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -91,16 +91,9 @@ enum CandidateBackingMessage {
Various modules request that the [Candidate Validation subsystem](node/utility/candidate-validation.html) validate a block with this message

```rust
enum PoVOrigin {
/// The proof of validity is available here.
Included(PoV),
/// We need to fetch proof of validity from some peer on the network.
Network(CandidateReceipt),
}

enum CandidateValidationMessage {
/// Validate a candidate and issue a Statement
Validate(CandidateHash, RelayHash, PoVOrigin),
Validate(CandidateHash, RelayHash, PoV, Sender<Statement>),
}
```

Expand Down