Renaming Parathread Mentions

node/core/provisioner/src/lib.rs

@@ -663,7 +663,7 @@ async fn request_backable_candidates(
 						// The candidate occupying the core is available, choose its
 						// child in the fragment tree.
 						//
-						// TODO: doesn't work for parathreads. We lean hard on the assumption
+						// TODO: doesn't work for on-demand parachains. We lean hard on the assumption
 						// that cores are fixed to specific parachains within a session.
 						// https://github.com/paritytech/polkadot/issues/5492
 						(scheduled_core.para_id, vec![occupied_core.candidate_hash])

node/network/collator-protocol/src/validator_side/mod.rs

@@ -520,9 +520,9 @@ where
 		},
 	};
 
-	// This code won't work well, if at all for parathreads. For parathreads we'll
-	// have to be aware of which core the parathread claim is going to be multiplexed
-	// onto. The parathread claim will also have a known collator, and we should always
+	// This code won't work well, if at all for on-demand parachains. For on-demand we'll
+	// have to be aware of which core the on-demand claim is going to be multiplexed
+	// onto. The on-demand claim will also have a known collator, and we should always
 	// allow an incoming connection from that collator. If not even connecting to them
 	// directly.
 	//

node/network/statement-distribution/src/vstaging/mod.rs

@@ -549,7 +549,7 @@ fn find_local_validator_state(
 
 	let our_group = groups.by_validator_index(validator_index)?;
 
-	// note: this won't work well for parathreads because it only works
+	// note: this won't work well for on-demand parachains because it only works
 	// when core assignments to paras are static throughout the session.
 
 	let core = group_rotation_info.core_for_group(our_group, availability_cores.len());
@@ -1708,7 +1708,7 @@ fn group_for_para(
 	group_rotation_info: &GroupRotationInfo,
 	para_id: ParaId,
 ) -> Option<GroupIndex> {
-	// Note: this won't work well for parathreads as it assumes that core assignments are fixed
+	// Note: this won't work well for on-demand parachains as it assumes that core assignments are fixed
 	// across blocks.
 	let core_index = availability_cores.iter().position(|c| c.para_id() == Some(para_id));
 

primitives/src/v4/mod.rs

@@ -802,12 +802,13 @@ impl TypeIndex for GroupIndex {
 	}
 }
 
-/// A claim on authoring the next block for a given parathread.
+/// A claim on authoring the next block for a given parathread (on-demand parachain).
 #[derive(Clone, Encode, Decode, TypeInfo, RuntimeDebug)]
 #[cfg_attr(feature = "std", derive(PartialEq))]
 pub struct ParathreadClaim(pub Id, pub CollatorId);
 
-/// An entry tracking a claim to ensure it does not pass the maximum number of retries.
+/// An entry tracking a parathread (on-demand parachain) claim to ensure it does not 
+/// pass the maximum number of retries.
 #[derive(Clone, Encode, Decode, TypeInfo, RuntimeDebug)]
 #[cfg_attr(feature = "std", derive(PartialEq))]
 pub struct ParathreadEntry {
@@ -821,7 +822,7 @@ pub struct ParathreadEntry {
 #[derive(Clone, Encode, Decode, TypeInfo, RuntimeDebug)]
 #[cfg_attr(feature = "std", derive(PartialEq))]
 pub enum CoreOccupied {
-	/// A parathread.
+	/// A parathread (on-demand parachain).
 	Parathread(ParathreadEntry),
 	/// A parachain.
 	Parachain,
@@ -974,8 +975,9 @@ pub enum CoreState<H = Hash, N = BlockNumber> {
 	/// variant.
 	#[codec(index = 1)]
 	Scheduled(ScheduledCore),
-	/// The core is currently free and there is nothing scheduled. This can be the case for parathread
-	/// cores when there are no parathread blocks queued. Parachain cores will never be left idle.
+	/// The core is currently free and there is nothing scheduled. This can be the case for 
+	/// on-demand parachain cores when there are no on-demand blocks queued. Leased parachain 
+	/// cores will never be left idle.
 	#[codec(index = 2)]
 	Free,
 }
@@ -1176,10 +1178,10 @@ pub const POLKADOT_ENGINE_ID: runtime_primitives::ConsensusEngineId = *b"POL1";
 /// A consensus log item for polkadot validation. To be used with [`POLKADOT_ENGINE_ID`].
 #[derive(Decode, Encode, Clone, PartialEq, Eq)]
 pub enum ConsensusLog {
-	/// A parachain or parathread upgraded its code.
+	/// A parachain upgraded its code.
 	#[codec(index = 1)]
 	ParaUpgradeCode(Id, ValidationCodeHash),
-	/// A parachain or parathread scheduled a code upgrade.
+	/// A parachain scheduled a code upgrade.
 	#[codec(index = 2)]
 	ParaScheduleUpgradeCode(Id, ValidationCodeHash, BlockNumber),
 	/// Governance requests to auto-approve every candidate included up to the given block

roadmap/implementers-guide/src/SUMMARY.md

@@ -12,18 +12,18 @@
   - [Messaging Overview](messaging.md)
   - [PVF Pre-checking](pvf-prechecking.md)
 - [Runtime Architecture](runtime/README.md)
-  - [`Initializer` Module](runtime/initializer.md)
-  - [`Configuration` Module](runtime/configuration.md)
-  - [`Shared`](runtime/shared.md)
-  - [`Disputes` Module](runtime/disputes.md)
-  - [`Paras` Module](runtime/paras.md)
-  - [`Scheduler` Module](runtime/scheduler.md)
-  - [`Inclusion` Module](runtime/inclusion.md)
-  - [`ParaInherent` Module](runtime/parainherent.md)
-  - [`DMP` Module](runtime/dmp.md)
-  - [`UMP` Module](runtime/ump.md)
-  - [`HRMP` Module](runtime/hrmp.md)
-  - [`Session Info` Module](runtime/session_info.md)
+  - [`Initializer` Pallet](runtime/initializer.md)
+  - [`Configuration` Pallet](runtime/configuration.md)
+  - [`Shared` Pallet](runtime/shared.md)
+  - [`Disputes` Pallet](runtime/disputes.md)
+  - [`Paras` Pallet](runtime/paras.md)
+  - [`Scheduler` Pallet](runtime/scheduler.md)
+  - [`Inclusion` Pallet](runtime/inclusion.md)
+  - [`ParaInherent` Pallet](runtime/parainherent.md)
+  - [`DMP` Pallet](runtime/dmp.md)
+  - [`UMP` Pallet](runtime/ump.md)
+  - [`HRMP` Pallet](runtime/hrmp.md)
+  - [`Session Info` Pallet](runtime/session_info.md)
 - [Runtime APIs](runtime-api/README.md)
   - [Validators](runtime-api/validators.md)
   - [Validator Groups](runtime-api/validator-groups.md)

roadmap/implementers-guide/src/glossary.md

@@ -24,11 +24,12 @@ exactly one downward message queue.
 - **Parablock:** A block in a parachain.
 - **Parachain:** A constituent chain secured by the Relay Chain's validators.
 - **Parachain Validators:** A subset of validators assigned during a period of time to back candidates for a specific parachain
-- **Parathread:** A parachain which is scheduled on a pay-as-you-go basis.
+- **On-demand parachain:** A parachain which is scheduled on a pay-as-you-go basis.
+- **Lease holding parachain:** A parachain possessing an active slot lease. The lease holder is assigned a single availability core for the duration of the lease, granting consistent blockspace scheduling at the rate 1 parablock per relay block.
 - **PDK (Parachain Development Kit):** A toolset that allows one to develop a parachain. Cumulus is a PDK.
 - **Preimage:** In our context, if `H(X) = Y` where `H` is a hash function and `Y` is the hash, then `X` is the hash preimage.
 - **Proof-of-Validity (PoV):** A stateless-client proof that a parachain candidate is valid, with respect to some validation function.
-- **PVF:** Parachain Validation Function. The validation code that is run by validators on parachains or parathreads.
+- **PVF:** Parachain Validation Function. The validation code that is run by validators on parachains.
 - **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.

roadmap/implementers-guide/src/pvf-prechecking.md

@@ -4,7 +4,7 @@
 
 ## Motivation
 
-Parachains' and parathreads' validation function is described by a wasm module that we refer to as a PVF. Since a PVF is a wasm module the typical way of executing it is to compile it to machine code.
+Parachains' validation function is described by a wasm module that we refer to as a PVF. Since a PVF is a wasm module the typical way of executing it is to compile it to machine code.
 
 Typically an optimizing compiler consists of algorithms that are able to optimize the resulting machine code heavily. However, while those algorithms perform quite well for a typical wasm code produced by standard toolchains (e.g. rustc/LLVM), those algorithms can be abused to consume a lot of resources. Moreover, since those algorithms are rather complex there is a lot of room for a bug that can crash the compiler.
 
@@ -23,8 +23,8 @@ As a result of this issue we need a fairly hard guarantee that the PVFs of regis
 
 The problem is solved by having a pre-checking process which is run when a new validation code is included in the chain. A new PVF can be added in two cases:
 
-- A new parachain or parathread is registered.
-- An existing parachain or parathread signalled an upgrade of its validation code.
+- A new parachain is registered.
+- An existing parachain signalled an upgrade of its validation code.
 
 Before any of those operations finish, the PVF pre-checking vote is initiated. The PVF pre-checking vote is identified by the PVF code hash that is being voted on. If there is already PVF pre-checking process running, then no
 new PVF pre-checking vote will be started. Instead, the operation just subscribes to the existing vote.
@@ -48,7 +48,7 @@ On the node-side, there is a PVF pre-checking [subsystem][pvf-prechecker-subsyst
 
 ## Summary
 
-Parachains' and parathreads' validation function is described by a wasm module that we refer to as a PVF.
+Parachains' validation function is described by a wasm module that we refer to as a PVF.
 
 In order to make the PVF usable for candidate validation it has to be registered on-chain.
 

roadmap/implementers-guide/src/runtime-api/availability-cores.md

@@ -52,8 +52,8 @@ enum CoreState {
     /// If a particular Collator is required to author this block, that is also present in this
     /// variant.
     Scheduled(ScheduledCore),
-    /// The core is currently free and there is nothing scheduled. This can be the case for parathread
-    /// cores when there are no parathread blocks queued. Parachain cores will never be left idle.
+    /// The core is currently free and there is nothing scheduled. This can be the case for on-demand
+    /// cores when there are no on-demand parachain blocks queued. Leased cores will never be left idle.
     Free,
 }
 ```

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

@@ -6,7 +6,7 @@ Due to the (lack of) guarantees provided by a particular blockchain-runtime fram
 
 We also expect, although it's beyond the scope of this guide, that these runtime modules will exist alongside various other modules. This has two facets to consider. First, even if the modules that we describe here don't invoke each others' entry points or routines during initialization, we still have to protect against those other modules doing that. Second, some of those modules are expected to provide governance capabilities for the chain. Configuration exposed by parachain-host modules is mostly for the benefit of these governance modules, to allow the operators or community of the chain to tweak parameters.
 
-The runtime's primary roles to manage scheduling and updating of parachains and parathreads, as well as handling misbehavior reports and slashing. This guide doesn't focus on how parachains or parathreads are registered, only that they are. Also, this runtime description assumes that validator sets are selected somehow, but doesn't assume any other details than a periodic _session change_ event. Session changes give information about the incoming validator set and the validator set of the following session.
+The runtime's primary role is to manage scheduling and updating of parachains, as well as handling misbehavior reports and slashing. This guide doesn't focus on how parachains are registered, only that they are. Also, this runtime description assumes that validator sets are selected somehow, but doesn't assume any other details than a periodic _session change_ event. Session changes give information about the incoming validator set and the validator set of the following session.
 
 The runtime also serves another role, which is to make data available to the Node-side logic via Runtime APIs. These Runtime APIs should be sufficient for the Node-side code to author blocks correctly.
 
@@ -17,9 +17,9 @@ We will split the logic of the runtime up into these modules:
 * Initializer: manages initialization order of the other modules.
 * Shared: manages shared storage and configurations for other modules.
 * 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.
+* Paras: manages chain-head and validation code for parachains.
+* Scheduler: manages parachain scheduling as well as validator assignments.
+* Inclusion: handles the inclusion and availability of scheduled parachains.
 * 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.

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

@@ -1,4 +1,4 @@
-# Configuration Module
+# Configuration Pallet
 
 This module is responsible for managing all configuration of the parachain host in-flight. It provides a central point for configuration updates to prevent races between configuration changes and parachain-processing logic. Configuration can only change during the session change routine, and as this module handles the session change notification first it provides an invariant that the configuration does not change throughout the entire session. Both the [scheduler](scheduler.md) and [inclusion](inclusion.md) modules rely on this invariant to ensure proper behavior of the scheduler.
 

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

@@ -1,4 +1,4 @@
-# Disputes Module
+# Disputes Pallet
 
 After a backed candidate is made available, it is included and proceeds into an acceptance period during which validators are randomly selected to do (secondary) approval checks of the parablock. Any reports disputing the validity of the candidate will cause escalation, where even more validators are requested to check the block, and so on, until either the parablock is determined to be invalid or valid. Those on the wrong side of the dispute are slashed and, if the parablock is deemed invalid, the relay chain is rolled back to a point before that block was included.
 

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

@@ -1,4 +1,4 @@
-# DMP Module
+# DMP Pallet
 
 A module responsible for Downward Message Processing (DMP). See [Messaging Overview](../messaging.md) for more details.
 

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

@@ -1,4 +1,4 @@
-# HRMP Module
+# HRMP Pallet
 
 A module responsible for Horizontally Relay-routed Message Passing (HRMP). See [Messaging Overview](../messaging.md) for more details.
 

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

@@ -1,6 +1,6 @@
-# Inclusion Module
+# Inclusion Pallet
 
-The inclusion module is responsible for inclusion and availability of scheduled parachains and parathreads. It also manages the UMP dispatch queue of each parachain/thread.
+The inclusion module is responsible for inclusion and availability of scheduled parachains. It also manages the UMP dispatch queue of each parachain.
 
 ## Storage
 
@@ -61,9 +61,9 @@ No initialization routine runs for this module. However, the initialization of t
 All failed checks should lead to an unrecoverable error making the block invalid.
 
 * `process_bitfields(expected_bits, Bitfields, core_lookup: Fn(CoreIndex) -> Option<ParaId>)`:
-  1. call `sanitize_bitfields<true>` and use the sanitized `signed_bitfields` from now on.
-  1. call `sanitize_backed_candidates<true>` and use the sanitized `backed_candidates` from now on.
-  1. apply each bit of bitfield to the corresponding pending candidate. looking up parathread cores using the `core_lookup`. Disregard bitfields that have a `1` bit for any free cores.
+  1. Call `sanitize_bitfields<true>` and use the sanitized `signed_bitfields` from now on.
+  1. Call `sanitize_backed_candidates<true>` and use the sanitized `backed_candidates` from now on.
+  1. Apply each bit of bitfield to the corresponding pending candidate, looking up on-demand parachain cores using the `core_lookup`. Disregard bitfields that have a `1` bit for any free cores.
   1. For each applied bit of each availability-bitfield, set the bit for the validator in the `CandidatePendingAvailability`'s `availability_votes` bitfield. Track all candidates that now have >2/3 of bits set in their `availability_votes`. These candidates are now available and can be enacted.
   1. For all now-available candidates, invoke the `enact_candidate` routine with the candidate and relay-parent number.
   1. Return a list of `(CoreIndex, CandidateHash)` from freed cores consisting of the cores where candidates have become available.

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

@@ -1,4 +1,4 @@
-# Initializer Module
+# Initializer Pallet
 
 This module is responsible for initializing the other modules in a deterministic order. It also has one other purpose as described in the overview of the runtime: accepting and forwarding session change notifications.