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

Implement validation data refactor (#1585)

Browse Source 
* update primitives

* correct parent_head field

* make hrmp field pub

* refactor validation data: runtime

* refactor validation data: messages

* add arguments to full_validation_data runtime API

* port runtime API

* mostly port over candidate validation

* remove some parameters from ValidationParams

* guide: update candidate validation

* update candidate outputs

* update ValidationOutputs in primitives

* port over candidate validation

* add a new test for no-transient behavior

* update util runtime API wrappers

* candidate backing

* fix missing imports

* change some fields of validation data around

* runtime API impl

* update candidate validation

* fix backing tests

* grumbles from review

* fix av-store tests

* fix some more crates

* fix provisioner tests

* fix availability distribution tests

* port collation-generation to new validation data

* fix overseer tests

* Update roadmap/implementers-guide/src/node/utility/candidate-validation.md

Co-authored-by: Peter Goodspeed-Niklaus <coriolinus@users.noreply.github.com>

Co-authored-by: Peter Goodspeed-Niklaus <coriolinus@users.noreply.github.com>
This commit is contained in:
Robert Habermeier
2020-08-18 14:41:40 +02:00
committed by GitHub
parent 3395044402
commit 262574fc49
36 changed files with 619 additions and 1153 deletions
Download Patch File Download Diff File Expand all files Collapse all files
polkadot/roadmap/implementers-guide/src/node/utility/candidate-validation.md
+2 -2
View File
@@ -24,7 +24,7 @@ Upon receiving a validation request, the first thing the candidate validation su
### Determining Parameters
For a [`CandidateValidationMessage`][CVM]`::ValidateFromExhaustive`, these parameters are exhaustively provided. The [`OmittedValidationData`](../../types/availability.md#omittedvalidationdata) can be deconstructed into the validation data.
For a [`CandidateValidationMessage`][CVM]`::ValidateFromExhaustive`, these parameters are exhaustively provided. The [`TransientValidationData`](../../types/candidate.md#transientvalidationdata) is optional, and is used to perform further checks on the outputs of validation.
For a [`CandidateValidationMessage`][CVM]`::ValidateFromChainState`, some more work needs to be done. Due to the uncertainty of Availability Cores (implemented in the [`Scheduler`](../../runtime/scheduler.md) module of the runtime), a candidate at a particular relay-parent and for a particular para may have two different valid validation-data to be executed under depending on what is assumed to happen if the para is occupying a core at the onset of the new block. This is encoded as an `OccupiedCoreAssumption` in the runtime API.
@@ -40,7 +40,7 @@ Once we have all parameters, we can spin up a background task to perform the val
* The collator signature is valid
* The PoV provided matches the `pov_hash` field of the descriptor
After that, we can invoke the validation function. Lastly, we do some final checks on the output:
After that, we can invoke the validation function. Lastly, if available, we do some final checks on the output using the `TransientValidationData`:
* The produced head-data is no larger than the maximum allowed.
* The produced code upgrade, if any, is no larger than the maximum allowed, and a code upgrade was allowed to be signaled.
* The amount and size of produced upward messages is not too large.
polkadot/roadmap/implementers-guide/src/types/candidate.md
+22 -22
View File
@@ -77,7 +77,7 @@ struct CandidateDescriptor {
/// The blake2-256 hash of the persisted validation data. These are extra parameters
/// derived from relay-chain state that influence the validity of the block which
/// must also be kept available for secondary checkers.
validation_data_hash: Hash,
persisted_validation_data_hash: Hash,
/// The blake2-256 hash of the pov-block.
pov_hash: Hash,
/// Signature on blake2-256 of components of this receipt:
@@ -119,23 +119,13 @@ Validation data that needs to be persisted for secondary checkers. See the secti
struct PersistedValidationData {
/// The parent head-data.
parent_head: HeadData,
/// Whether the parachain is allowed to upgrade its validation code.
///
/// This is `Some` if so, and contains the number of the minimum relay-chain
/// height at which the upgrade will be applied, if an upgrade is signaled
/// now.
///
/// A parachain should enact its side of the upgrade at the end of the first
/// parablock executing in the context of a relay-chain block with at least this
/// height. This may be equal to the current perceived relay-chain block height, in
/// which case the code upgrade should be applied at the end of the signaling
/// block.
///
/// This informs a relay-chain backing check and the parachain logic.
code_upgrade_allowed: Option<BlockNumber>,
/// The relay-chain block number this is in the context of. This informs the collator.
block_number: BlockNumber,
/// The relay-chain
/// The list of MQC heads for the inbound channels paired with the sender para ids. This
/// vector is sorted ascending by the para id and doesn't contain multiple entries with the same
/// sender.
hrmp_mqc_heads: Vec<(ParaId, Hash)>,
}
```
@@ -155,10 +145,20 @@ struct TransientValidationData {
max_head_data_size: u32,
/// The balance of the parachain at the moment of validation.
balance: Balance,
/// The list of MQC heads for the inbound channels paired with the sender para ids. This
/// vector is sorted ascending by the para id and doesn't contain multiple entries with the same
/// sender. This informs the collator.
hrmp_mqc_heads: Vec<(ParaId, Hash)>,
/// Whether the parachain is allowed to upgrade its validation code.
///
/// This is `Some` if so, and contains the number of the minimum relay-chain
/// height at which the upgrade will be applied, if an upgrade is signaled
/// now.
///
/// A parachain should enact its side of the upgrade at the end of the first
/// parablock executing in the context of a relay-chain block with at least this
/// height. This may be equal to the current perceived relay-chain block height, in
/// which case the code upgrade should be applied at the end of the signaling
/// block.
///
/// This informs a relay-chain backing check and the parachain logic.
code_upgrade_allowed: Option<BlockNumber>,
}
```
@@ -219,8 +219,8 @@ This struct encapsulates the outputs of candidate validation.
struct ValidationOutputs {
/// The head-data produced by validation.
head_data: HeadData,
/// The validation data, persisted and transient.
validation_data: ValidationData,
/// The validation data, persisted.
validation_data: PersistedValidationData,
/// Messages directed to other paras routed via the relay chain.
horizontal_messages: Vec<OutboundHrmpMessage>,
/// Upwards messages to the relay chain.
polkadot/roadmap/implementers-guide/src/types/overseer-protocol.md
+5 -3
View File
@@ -393,11 +393,13 @@ enum CandidateValidationMessage {
/// the para is not free at the relay-parent, an error is returned.
ValidateFromChainState(CandidateDescriptor, PoV, ResponseChannel<Result<ValidationResult>>),
/// Validate a candidate with provided parameters. Explicitly provide the `OmittedValidationData`
/// Validate a candidate with provided parameters. Explicitly provide the `PersistedValidationData`
/// and `ValidationCode` so this can do full validation without needing to access the state of
/// the relay-chain.
/// the relay-chain. Optionally provide the `TransientValidationData` which will lead to checks
/// on the output.
ValidateFromExhaustive(
OmittedValidationData,
PersistedValidationData,
Option<TransientValidationData>,
ValidationCode,
CandidateDescriptor,
PoV,