From 04097c881d188ee8354bad5d036e4f757f7238f0 Mon Sep 17 00:00:00 2001
From: Peter Goodspeed-Niklaus <coriolinus@users.noreply.github.com>
Date: Wed, 17 Jun 2020 20:37:03 +0200
Subject: [PATCH] Update guide candidate validation module (#1264)
* first pass updating candidate validation module in the guide
* expand candidate validation functionality section
* add candidate fetch; validation requires PoV to be provided
* remove candidate fetch
---
.../src/node/utility/candidate-validation.md | 16 +++++++++++++---
.../implementors-guide/src/type-definitions.md | 9 +--------
2 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/polkadot/roadmap/implementors-guide/src/node/utility/candidate-validation.md b/polkadot/roadmap/implementors-guide/src/node/utility/candidate-validation.md
index 30c110fdef1..6ad59f60f31 100644
--- a/polkadot/roadmap/implementors-guide/src/node/utility/candidate-validation.md
+++ b/polkadot/roadmap/implementors-guide/src/node/utility/candidate-validation.md
@@ -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.
+
+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.
+- Return the statement on the provided channel.
diff --git a/polkadot/roadmap/implementors-guide/src/type-definitions.md b/polkadot/roadmap/implementors-guide/src/type-definitions.md
index d8c90bba50d..1c730e9a3b6 100644
--- a/polkadot/roadmap/implementors-guide/src/type-definitions.md
+++ b/polkadot/roadmap/implementors-guide/src/type-definitions.md
@@ -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>),
}
```
--
GitLab