From 8dc6048d5eb20886f5d0781d54e073441d3bd86c Mon Sep 17 00:00:00 2001
From: eskimor <eskimor@users.noreply.github.com>
Date: Mon, 11 Mar 2024 15:11:55 +0100
Subject: [PATCH] Remove unused FullCandidateReceipt (#3641)
Currently redesigning candidate data structures, noticed that this one
seems dead.
Co-authored-by: eskimor <eskimor@no-such-url.com>
---
polkadot/primitives/src/v6/mod.rs | 12 ---------
.../implementers-guide/src/types/README.md | 11 --------
.../implementers-guide/src/types/candidate.md | 26 ++-----------------
3 files changed, 2 insertions(+), 47 deletions(-)
diff --git a/polkadot/primitives/src/v6/mod.rs b/polkadot/primitives/src/v6/mod.rs
index 89431f7801f..cab34deeb50 100644
--- a/polkadot/primitives/src/v6/mod.rs
+++ b/polkadot/primitives/src/v6/mod.rs
@@ -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))]
diff --git a/polkadot/roadmap/implementers-guide/src/types/README.md b/polkadot/roadmap/implementers-guide/src/types/README.md
index 87092bf3a00..5fd3050f949 100644
--- a/polkadot/roadmap/implementers-guide/src/types/README.md
+++ b/polkadot/roadmap/implementers-guide/src/types/README.md
@@ -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>
diff --git a/polkadot/roadmap/implementers-guide/src/types/candidate.md b/polkadot/roadmap/implementers-guide/src/types/candidate.md
index 00176229e5a..399d7854ac4 100644
--- a/polkadot/roadmap/implementers-guide/src/types/candidate.md
+++ b/polkadot/roadmap/implementers-guide/src/types/candidate.md
@@ -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
--
GitLab