mirror of
https://github.com/pezkuwichain/pezkuwi-subxt.git
synced 2026-07-21 15:35:42 +00:00
Remove unused FullCandidateReceipt (#3641)
Currently redesigning candidate data structures, noticed that this one seems dead. Co-authored-by: eskimor <eskimor@no-such-url.com>
This commit is contained in:
@@ -533,18 +533,6 @@ impl<H> CandidateReceipt<H> {
|
|||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
/// All data pertaining to the execution of a para candidate.
|
|
||||||
#[derive(PartialEq, Eq, Clone, Encode, Decode, TypeInfo, RuntimeDebug)]
|
|
||||||
pub struct FullCandidateReceipt<H = Hash, N = BlockNumber> {
|
|
||||||
/// The inner candidate receipt.
|
|
||||||
pub inner: CandidateReceipt<H>,
|
|
||||||
/// The validation data derived from the relay-chain state at that
|
|
||||||
/// point. The hash of the persisted validation data should
|
|
||||||
/// match the `persisted_validation_data_hash` in the descriptor
|
|
||||||
/// of the receipt.
|
|
||||||
pub validation_data: PersistedValidationData<H, N>,
|
|
||||||
}
|
|
||||||
|
|
||||||
/// A candidate-receipt with commitments directly included.
|
/// A candidate-receipt with commitments directly included.
|
||||||
#[derive(PartialEq, Eq, Clone, Encode, Decode, TypeInfo, RuntimeDebug)]
|
#[derive(PartialEq, Eq, Clone, Encode, Decode, TypeInfo, RuntimeDebug)]
|
||||||
#[cfg_attr(feature = "std", derive(Hash))]
|
#[cfg_attr(feature = "std", derive(Hash))]
|
||||||
|
|||||||
@@ -55,17 +55,6 @@ digraph {
|
|||||||
CandidateCommitmentsHash [label = "Hash", shape="doublecircle", fill="gray90"]
|
CandidateCommitmentsHash [label = "Hash", shape="doublecircle", fill="gray90"]
|
||||||
CandidateCommitmentsHash -> CandidateCommitments:name
|
CandidateCommitmentsHash -> CandidateCommitments:name
|
||||||
|
|
||||||
FullCandidateReceipt [label = <
|
|
||||||
<table>
|
|
||||||
<tr><td border="0" colspan="2" port="name">FullCandidateReceipt<H = Hash, N = BlockNumber></td></tr>
|
|
||||||
<tr><td>inner</td><td port="inner">CandidateReceipt<H></td></tr>
|
|
||||||
<tr><td>validation_data</td><td port="validation_data">ValidationData<N></td></tr>
|
|
||||||
</table>
|
|
||||||
>]
|
|
||||||
|
|
||||||
FullCandidateReceipt:inner -> CandidateReceipt:name
|
|
||||||
FullCandidateReceipt:validation_data -> ValidationData:name
|
|
||||||
|
|
||||||
CommittedCandidateReceipt [label = <
|
CommittedCandidateReceipt [label = <
|
||||||
<table>
|
<table>
|
||||||
<tr><td border="0" colspan="2" port="name">CommittedCandidateReceipt<H = Hash></td></tr>
|
<tr><td border="0" colspan="2" port="name">CommittedCandidateReceipt<H = Hash></td></tr>
|
||||||
|
|||||||
@@ -20,12 +20,8 @@ struct ParaId(u32);
|
|||||||
|
|
||||||
## Candidate Receipt
|
## Candidate Receipt
|
||||||
|
|
||||||
Much info in a [`FullCandidateReceipt`](#full-candidate-receipt) is duplicated from the relay-chain state. When the
|
Compact representation of the result of a validation. This is what validators
|
||||||
corresponding relay-chain state is considered widely available, the Candidate Receipt should be favored over the
|
receive from collators, together with the PoV.
|
||||||
`FullCandidateReceipt`.
|
|
||||||
|
|
||||||
Examples of situations where the state is readily available includes within the scope of work done by subsystems working
|
|
||||||
on a given relay-parent, or within the logic of the runtime importing a backed candidate.
|
|
||||||
|
|
||||||
```rust
|
```rust
|
||||||
/// A candidate-receipt.
|
/// A candidate-receipt.
|
||||||
@@ -37,24 +33,6 @@ struct CandidateReceipt {
|
|||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
## Full Candidate Receipt
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
```rust
|
|
||||||
/// All data pertaining to the execution of a para candidate.
|
|
||||||
struct FullCandidateReceipt {
|
|
||||||
inner: CandidateReceipt,
|
|
||||||
validation_data: PeristedValidationData,
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
## Committed Candidate Receipt
|
## Committed Candidate Receipt
|
||||||
|
|
||||||
This is a variant of the candidate receipt which includes the commitments of the candidate receipt alongside the
|
This is a variant of the candidate receipt which includes the commitments of the candidate receipt alongside the
|
||||||
|
|||||||
Reference in New Issue
Block a user