guide: remove refences to outdated secondary checkers

node/primitives/src/lib.rs

@@ -383,7 +383,7 @@ impl std::fmt::Debug for CollationGenerationConfig {
 pub struct AvailableData {
 	/// The Proof-of-Validation of the candidate.
 	pub pov: std::sync::Arc<PoV>,
-	/// The persisted validation data needed for secondary checks.
+	/// The persisted validation data needed for approval checks.
 	pub validation_data: PersistedValidationData,
 }
 

roadmap/implementers-guide/src/glossary.md

@@ -2,6 +2,7 @@
 
 Here you can find definitions of a bunch of jargon, usually specific to the Polkadot project.
 
+- **Approval Checker:** A validator who has been randomly selected to perform validity checks on a parablock which is pending approval.
 - **BABE:** (Blind Assignment for Blockchain Extension). The algorithm validators use to safely extend the Relay Chain. See [the Polkadot wiki][0] for more information.
 - **Backable Candidate:** A Parachain Candidate which is backed by a majority of validators assigned to a given parachain.
 - **Backed Candidate:** A Backable Candidate noted in a relay-chain block
@@ -31,11 +32,9 @@ exactly one downward message queue.
 - **PVF Prechecking:** This is the process of initially checking the PVF when it is first added. We attempt preparation of the PVF and make sure it succeeds within a given timeout.
 - **PVF Preparation:** This is the process of preparing the WASM blob and includes both prevalidation and compilation. As prevalidation is pretty minimal right now, preparation mostly consists of compilation.
 - **Relay Parent:** A block in the relay chain, referred to in a context where work is being done in the context of the state at this block.
-- **Router:** The router module is a meta module that consists of three runtime modules responsible for routing messages between paras and the relay chain. The three separate runtime modules are: Dmp, Ump, Hrmp, each responsible for the respective part of message routing.
 - **Runtime:** The relay-chain state machine.
 - **Runtime Module:** See Module.
 - **Runtime API:** A means for the node-side behavior to access structured information based on the state of a fork of the blockchain.
-- **Secondary Checker:** A validator who has been randomly selected to perform secondary approval checks on a parablock which is pending approval.
 - **Subsystem:** A long-running task which is responsible for carrying out a particular category of work.
 - **UMP:** (Upward Message Passing) A vertical message passing mechanism from a parachain to the relay chain.
 - **Validator:** Specially-selected node in the network who is responsible for validating parachain blocks and issuing attestations about their validity.

roadmap/implementers-guide/src/runtime/README.md

@@ -14,16 +14,18 @@ There is some functionality of the relay chain relating to parachains that we al
 
 We will split the logic of the runtime up into these modules:
 
-* Initializer: manage initialization order of the other modules.
+* Initializer: manages initialization order of the other modules.
 * Shared: manages shared storage and configurations for other modules.
-* Configuration: manage configuration and configuration updates in a non-racy manner.
-* Paras: manage chain-head and validation code for parachains and parathreads.
+* Configuration: manages configuration and configuration updates in a non-racy manner.
+* Paras: manages chain-head and validation code for parachains and parathreads.
 * Scheduler: manages parachain and parathread scheduling as well as validator assignments.
 * Inclusion: handles the inclusion and availability of scheduled parachains and parathreads.
-* Validity: handles secondary checks and dispute resolution for included, available parablocks.
+* SessionInfo: manages various session keys of validators and other params stored per session.
+* Disputes: handles dispute resolution for included, available parablocks.
+* Slashing: handles slashing logic for concluded disputes.
 * HRMP: handles horizontal messages between paras.
-* UMP: Handles upward messages from a para to the relay chain.
-* DMP: Handles downward messages from the relay chain to the para.
+* UMP: handles upward messages from a para to the relay chain.
+* DMP: handles downward messages from the relay chain to the para.
 
 The [Initializer module](initializer.md) is special - it's responsible for handling the initialization logic of the other modules to ensure that the correct initialization order and related invariants are maintained. The other modules won't specify a on-initialize logic, but will instead expose a special semi-private routine that the initialization module will call. The other modules are relatively straightforward and perform the roles described above.
 

roadmap/implementers-guide/src/types/approval.md

@@ -6,7 +6,7 @@ The public key of a keypair used by a validator for determining assignments to a
 
 ## `AssignmentCert`
 
-An `AssignmentCert`, short for Assignment Certificate, is a piece of data provided by a validator to prove that they have been selected to perform secondary approval checks on an included candidate.
+An `AssignmentCert`, short for Assignment Certificate, is a piece of data provided by a validator to prove that they have been selected to perform approval checks on an included candidate.
 
 These certificates can be checked in the context of a specific block, candidate, and validator assignment VRF key. The block state will also provide further context about the availability core states at that block.
 

roadmap/implementers-guide/src/types/candidate.md

@@ -76,7 +76,7 @@ struct CandidateDescriptor {
 	collator: CollatorId,
 	/// The blake2-256 hash of the persisted validation data. These are extra parameters
 	/// derived from relay-chain state that influence the validity of the block which
-	/// must also be kept available for secondary checkers.
+	/// must also be kept available for approval checkers.
 	persisted_validation_data_hash: Hash,
 	/// The blake2-256 hash of the `pov-block`.
 	pov_hash: Hash,
@@ -100,7 +100,7 @@ Since this data is used to form inputs to the validation function, it needs to b
 
 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.
+Since the commitments of the validation function are checked by the relay-chain, approval 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 primarily because it is constructed during inclusion for each candidate and therefore lies on the critical path of inclusion.
 

roadmap/implementers-guide/src/types/overseer-protocol.md

@@ -827,7 +827,7 @@ pub enum CandidateValidationMessage {
     ///
     /// This request doesn't involve acceptance criteria checking, therefore only useful for the
     /// cases where the validity of the candidate is established. This is the case for the typical
-    /// use-case: secondary checkers would use this request relying on the full prior checks
+    /// use-case: approval checkers would use this request relying on the full prior checks
     /// performed by the relay-chain.
     ValidateFromExhaustive(
         PersistedValidationData,

runtime/parachains/src/paras/mod.rs

@@ -659,7 +659,7 @@ pub mod pallet {
 
 	/// Past code of parachains. The parachains themselves may not be registered anymore,
 	/// but we also keep their code on-chain for the same amount of time as outdated code
-	/// to keep it available for secondary checkers.
+	/// to keep it available for approval checkers.
 	#[pallet::storage]
 	#[pallet::getter(fn past_code_meta)]
 	pub(super) type PastCodeMeta<T: Config> =