mirror of
https://github.com/pezkuwichain/pezkuwi-subxt.git
synced 2026-05-08 14:48:01 +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.
|
||||
#[derive(PartialEq, Eq, Clone, Encode, Decode, TypeInfo, RuntimeDebug)]
|
||||
#[cfg_attr(feature = "std", derive(Hash))]
|
||||
|
||||
@@ -55,17 +55,6 @@ digraph {
|
||||
CandidateCommitmentsHash [label = "Hash", shape="doublecircle", fill="gray90"]
|
||||
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 = <
|
||||
<table>
|
||||
<tr><td border="0" colspan="2" port="name">CommittedCandidateReceipt<H = Hash></td></tr>
|
||||
|
||||
@@ -20,12 +20,8 @@ struct ParaId(u32);
|
||||
|
||||
## Candidate Receipt
|
||||
|
||||
Much info in a [`FullCandidateReceipt`](#full-candidate-receipt) is duplicated from the relay-chain state. When the
|
||||
corresponding relay-chain state is considered widely available, the Candidate Receipt should be favored over the
|
||||
`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.
|
||||
Compact representation of the result of a validation. This is what validators
|
||||
receive from collators, together with the PoV.
|
||||
|
||||
```rust
|
||||
/// 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
|
||||
|
||||
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