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

Remove TransientValidationData (#2272)

Browse Source 
* collation-generation: use persisted validation data

* node: remote FullValidationData API

* runtime: remove FullValidationData API

* backing tests: use persisted validation data

* FullCandidateReceipt: use persisted validation data

This is not a big change since this type is not used anywhere

* Remove ValidationData and TransientValidationData

Also update the guide
This commit is contained in:
Sergei Shulepov
2021-01-19 00:57:09 +01:00
committed by GitHub
parent b009cbe801
commit 226af6a877
20 changed files with 77 additions and 417 deletions
Download Patch File Download Diff File Expand all files Collapse all files
polkadot/roadmap/implementers-guide/src/SUMMARY.md
-1
View File
@@ -24,7 +24,6 @@
- [Validator Groups](runtime-api/validator-groups.md)
- [Availability Cores](runtime-api/availability-cores.md)
- [Persisted Validation Data](runtime-api/persisted-validation-data.md)
- [Full Validation Data](runtime-api/full-validation-data.md)
- [Session Index](runtime-api/session-index.md)
- [Validation Code](runtime-api/validation-code.md)
- [Candidate Pending Availability](runtime-api/candidate-pending-availability.md)
polkadot/roadmap/implementers-guide/src/node/collators/collation-generation.md
+1 -1
View File
@@ -33,7 +33,7 @@ pub struct Collation {
}
type CollatorFn = Box<
dyn Fn(Hash, &ValidationData) -> Pin<Box<dyn Future<Output = Option<Collation>>>>
dyn Fn(Hash, &PeristedValidationData) -> Pin<Box<dyn Future<Output = Option<Collation>>>>
>;
struct CollationGenerationConfig {
polkadot/roadmap/implementers-guide/src/runtime-api/full-validation-data.md
-7
View File
@@ -1,7 +0,0 @@
# Full Validation Data
Yields the full [`ValidationData`](../types/candidate.md#validationdata) at the state of a given block.
```rust
fn full_validation_data(at: Block, ParaId, OccupiedCoreAssumption) -> Option<ValidationData>;
```
polkadot/roadmap/implementers-guide/src/types/candidate.md
+14 -123
View File
@@ -33,7 +33,7 @@ struct CandidateReceipt {
## Full Candidate Receipt
This is the full receipt type. The `ValidationData` are technically redundant with the `inner.relay_parent`, which uniquely describes the block in the blockchain from whose state these values are derived. The [`CandidateReceipt`](#candidate-receipt) variant is often used instead for this reason.
This is the full receipt type. The `PersistedValidationData` are technically redundant with the `inner.relay_parent`, which uniquely describes the block in the blockchain from whose state these values are derived. The [`CandidateReceipt`](#candidate-receipt) variant is often used instead for this reason.
However, the Full Candidate Receipt type is useful as a means of avoiding the implicit dependency on availability of old blockchain state. In situations such as availability and approval, having the full description of the candidate within a self-contained struct is convenient.
@@ -41,7 +41,7 @@ However, the Full Candidate Receipt type is useful as a means of avoiding the im
/// All data pertaining to the execution of a para candidate.
struct FullCandidateReceipt {
inner: CandidateReceipt,
validation_data: ValidationData,
validation_data: PeristedValidationData,
}
```
@@ -88,38 +88,17 @@ struct CandidateDescriptor {
}
```
## ValidationData
The validation data provide information about how to validate both the inputs and outputs of a candidate. There are two types of validation data: [persisted](#persistedvalidationdata) and [transient](#transientvalidationdata). Their respective sections of the guide elaborate on their functionality in more detail.
This information is derived from the chain state and will vary from para to para, although some of the fields may be the same for every para.
Persisted validation data are generally derived from some relay-chain state to form inputs to the validation function, and as such need to be persisted by the availability system to avoid dependence on availability of the relay-chain state. The backing phase of the inclusion pipeline ensures that everything that is included in a valid fork of the relay-chain already adheres to the transient constraints.
The validation data also serve the purpose of giving collators a means of ensuring that their produced candidate and the commitments submitted to the relay-chain alongside it will pass the checks done by the relay-chain when backing, and give validators the same understanding when determining whether to second or attest to a candidate.
Furthermore, the validation data acts as a way to authorize the additional data the collator needs to pass to the validation
function. For example, the validation function can check whether the incoming messages (e.g. downward messages) were actually
sent by using the data provided in the validation data using so called MQC heads.
Since the commitments of the validation function are checked by the relay-chain, secondary checkers can rely on the invariant that the relay-chain only includes para-blocks for which these checks have already been done. As such, there is no need for the validation data used to inform validators and collators about the checks the relay-chain will perform to be persisted by the availability system. Nevertheless, we expose it so the backing validators can validate the outputs of a candidate before voting to submit it to the relay-chain and so collators can collate candidates that satisfy the criteria implied these transient validation data.
Design-wise we should maintain two properties about this data structure:
1. The `ValidationData` should be relatively lightweight primarly because it is constructed during inclusion for each candidate.
1. To make contextual execution possible, `ValidationData` should be constructable only having access to the latest relay-chain state for the past `k` blocks. That implies
either that the relay-chain should maintain all the required data accessible or somehow provided indirectly with a header-chain proof and a state proof from there.
```rust
struct ValidationData {
persisted: PersistedValidationData,
transient: TransientValidationData,
}
```
## PersistedValidationData
Validation data that needs to be persisted for secondary checkers. See the section on [`ValidationData`](#validationdata) for more details.
The validation data provides information about how to create the inputs for validation of a candidate. This information is derived from the chain state and will vary from para to para, although some of the fields may be the same for every para.
Since this data is used to form inputs to the validation function, it needs to be persisted by the availability system to avoid dependence on availability of the relay-chain state.
Furthermore, the validation data acts as a way to authorize the additional data the collator needs to pass to the validation function. For example, the validation function can check whether the incoming messages (e.g. downward messages) were actually sent by using the data provided in the validation data using so called MQC heads.
Since the commitments of the validation function are checked by the relay-chain, secondary checkers can rely on the invariant that the relay-chain only includes para-blocks for which these checks have already been done. As such, there is no need for the validation data used to inform validators and collators about the checks the relay-chain will perform to be persisted by the availability system.
The `PersistedValidationData` should be relatively lightweight primarly because it is constructed during inclusion for each candidate and therefore lies on the critical path of inclusion.
```rust
struct PersistedValidationData {
@@ -141,96 +120,8 @@ struct PersistedValidationData {
/// The HRMP MQC heads will be used by the validation function to authorize the input messages passed
/// by the collator.
hrmp_mqc_heads: Vec<(ParaId, Hash)>,
}
```
## TransientValidationData
These validation data are derived from some relay-chain state to check outputs of the validation function.
It's worth noting that all the data is collected **before** the candidate execution.
```rust
struct TransientValidationData {
/// The maximum code size permitted, in bytes, of a produced validation code upgrade.
///
/// This informs a relay-chain backing check and the parachain logic.
max_code_size: u32,
/// The maximum head-data size permitted, in bytes.
///
/// This informs a relay-chain backing check and the parachain collator.
max_head_data_size: u32,
/// The balance of the parachain at the moment of validation.
balance: Balance,
/// 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>,
/// A copy of `config.max_upward_message_num_per_candidate` for checking that a candidate doesn't
/// send more messages than permitted.
config_max_upward_message_num_per_candidate: u32,
/// The number of messages pending of the downward message queue.
dmq_length: u32,
/// A part of transient validation data related to HRMP.
hrmp: HrmpTransientValidationData,
}
struct HrmpTransientValidationData {
/// A vector that enumerates the list of blocks in which there was at least one HRMP message
/// received.
///
/// The first number in the vector, if any, is always greater than the HRMP watermark. The
/// elements are ordered by ascending the block number. The vector doesn't contain duplicates.
digest: Vec<BlockNumber>,
/// The watermark of the HRMP. That is, the block number up to which (inclusive) all HRMP messages
/// sent to the parachain are processed.
watermark: BlockNumber,
/// A mapping that specifies if the parachain can send an HRMP message to the given recipient
/// channel. A candidate can send a message only to the recipients that are present in this
/// mapping. The number elements in this vector corresponds to the number of egress channels.
/// Since it's a mapping there can't be two items with same `ParaId`.
egress_limits: Vec<(ParaId, HrmpChannelLimits)>,
/// A vector of paras that have a channel to this para. The number of elements in this vector
/// correponds to the number of ingress channels. The items are ordered ascending by `ParaId`.
/// The vector doesn't contain two entries with the same `ParaId`.
ingress_senders: Vec<ParaId>,
/// A vector of open requests in which the para participates either as sender or recipient. The
/// items are ordered ascending by `HrmpChannelId`. The vector doesn't contain two entries
/// with the same `HrmpChannelId`.
open_requests: Vec<(HrmpChannelId, HrmpAbridgedOpenChannelRequest)>,
/// A vector of close requests in which the para participates either as sender or recipient.
/// The vector doesn't contain two entries with the same `HrmpChannelId`.
close_requests: Vec<HrmpChannelId>,
/// The maximum number of inbound channels the para is allowed to have. This is a copy of either
/// `config.hrmp_max_parachain_inbound_channels` or `config.hrmp_max_parathread_inbound_channels`
/// depending on the type of this para.
config_max_inbound_channels: u32,
/// The maximum number of outbound channels the para is allowed to have. This is a copy of either
/// `config.hrmp_max_parachain_outbound_channels` or `config.hrmp_max_parathread_outbound_channels`
/// depending on the type of this para.
config_max_outbound_channels: u32,
}
/// A shorter version of `HrmpOpenChannelRequest`.
struct HrmpAbridgedOpenChannelRequest {
confirmed: bool,
}
struct HrmpChannelLimits {
/// Indicates if the channel is already full and cannot accept any more messages.
is_full: bool,
/// A message sent to the channel can occupy only that many bytes.
available_size: u32,
/// The maximum legal size of a POV block, in bytes.
pub max_pov_size: u32,
}
```
@@ -277,4 +168,4 @@ struct SigningContext {
/// The session index this signature is in the context of.
session_index: SessionIndex,
}
```
```
polkadot/roadmap/implementers-guide/src/types/overseer-protocol.md
-6
View File
@@ -442,12 +442,6 @@ enum RuntimeApiRequest {
OccupiedCoreAssumption,
ResponseChannel<Option<PersistedValidationData>>,
),
/// Get the full validation data for a specific para, with the given occupied core assumption.
FullValidationData(
ParaId,
OccupiedCoreAssumption,
ResponseChannel<Option<ValidationData>>,
),
/// Sends back `true` if the commitments pass all acceptance criteria checks.
CheckValidationOutputs(
ParaId,