pezkuwichain/pezkuwi-subxt
1
0
Fork 0
mirror of https://github.com/pezkuwichain/pezkuwi-subxt.git synced 2026-05-30 17:31:03 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update guide candidate validation module (#1264)

Browse Source 
* 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
This commit is contained in:
Peter Goodspeed-Niklaus
2020-06-17 20:37:03 +02:00
committed by GitHub
parent c3ed40fbe6
commit 04097c881d
2 changed files with 14 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files
polkadot/roadmap/implementors-guide/src/node/utility/candidate-validation.md
+13 -3
View File
@@ -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.
polkadot/roadmap/implementors-guide/src/type-definitions.md
+1 -8
View File
@@ -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>),
}
```