Skip to content
Snippets Groups Projects
Unverified Commit 8dc6048d authored by eskimor's avatar eskimor Committed by GitHub
Browse files

Remove unused FullCandidateReceipt (#3641)


Currently redesigning candidate data structures, noticed that this one
seems dead.

Co-authored-by: default avatareskimor <eskimor@no-such-url.com>
parent a6713c55
No related merge requests found
Pipeline #453935 passed with warnings with stages
in 52 minutes and 21 seconds
......@@ -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&lt;H = Hash, N = BlockNumber&gt;</td></tr>
<tr><td>inner</td><td port="inner">CandidateReceipt&lt;H&gt;</td></tr>
<tr><td>validation_data</td><td port="validation_data">ValidationData&lt;N&gt;</td></tr>
</table>
>]
FullCandidateReceipt:inner -> CandidateReceipt:name
FullCandidateReceipt:validation_data -> ValidationData:name
CommittedCandidateReceipt [label = <
<table>
<tr><td border="0" colspan="2" port="name">CommittedCandidateReceipt&lt;H = Hash&gt;</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
......
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment