This guide assumes full familiarity with Asynchronous Backing and its
-//! terminology, as defined in
the Pezkuwi SDK Docs.
-//!
-//!
-//! ## Quick introduction to Elastic Scaling
-//!
-//! [Elastic scaling](https://www.parity.io/blog/polkadot-web3-cloud) is a feature that enables teyrchains (rollups) to use multiple cores.
-//! Teyrchains can adjust their usage of core resources on the fly to increase TPS and decrease
-//! latency.
-//!
-//! ### When do you need Elastic Scaling?
-//!
-//! Depending on their use case, applications might have an increased need for the following:
-//! - compute (CPU weight)
-//! - bandwidth (proof size)
-//! - lower latency (block time)
-//!
-//! ### High throughput (TPS) and lower latency
-//!
-//! If the main bottleneck is the CPU, then your teyrchain needs to maximize the compute usage of
-//! each core while also achieving a lower latency.
-//! 3 cores provide the best balance between CPU, bandwidth and latency: up to 6s of execution,
-//! 5MB/s of DA bandwidth and fast block time of just 2 seconds.
-//!
-//! ### High bandwidth
-//!
-//! Useful for applications that are bottlenecked by bandwidth.
-//! By using 6 cores, applications can make use of up to 6s of compute, 10MB/s of bandwidth
-//! while also achieving 1 second block times.
-//!
-//! ### Ultra low latency
-//!
-//! When latency is the primary requirement, Elastic scaling is currently the only solution. The
-//! caveat is the efficiency of core time usage decreases as more cores are used.
-//!
-//! For example, using 12 cores enables fast transaction confirmations with 500ms blocks and up to
-//! 20 MB/s of DA bandwidth.
-//!
-//! ## Dependencies
-//!
-//! Prerequisites: Pezkuwi-SDK `2509` or newer.
-//!
-//! To ensure the security and reliability of your chain when using this feature you need the
-//! following:
-//! - An omni-node based collator. This has already become the default choice for collators.
-//! - UMP signal support.
-//! [RFC103](https://github.com/polkadot-fellows/RFCs/blob/main/text/0103-introduce-core-index-commitment.md).
-//! This is mandatory protection against PoV replay attacks.
-//! - Enabling the relay parent offset feature. This is required to ensure the teyrchain block times
-//! and transaction in-block confidence are not negatively affected by relay chain forks. Read
-//! [`crate::guides::handling_teyrchain_forks`] for more information.
-//! - Block production configuration adjustments.
-//!
-//! ### Upgrade to Pezkuwi Omni node
-//!
-//! Your collators need to run `pezkuwi-teyrchain` or `pezkuwi-omni-node` with the `--authoring
-//! slot-based` CLI argument.
-//! To avoid potential issues and get best performance it is recommeneded to always run the
-//! latest release on all of the collators.
-//!
-//! Further information about omni-node and how to upgrade is available:
-//! - [high level docs](https://docs.pezkuwichain.io/develop/toolkit/parachains/polkadot-omni-node/)
-//! - [`crate::reference_docs::omni_node`]
-//!
-//! ### UMP signals
-//!
-//! UMP signals are now enabled by default in the `teyrchain-system` pezpallet and are used for
-//! elastic scaling. You can find more technical details about UMP signals and their usage for
-//! elastic scaling
-//! [here](https://github.com/polkadot-fellows/RFCs/blob/main/text/0103-introduce-core-index-commitment.md).
-//!
-//! ### Enable the relay parent offset feature
-//!
-//! It is recommended to use an offset of `1`, which is sufficient to eliminate any issues
-//! with relay chain forks.
-//!
-//! Configure the relay parent offset like this:
-//! ```ignore
-//! /// Build with an offset of 1 behind the relay chain best block.
-//! const RELAY_PARENT_OFFSET: u32 = 1;
-//!
-//! impl pezcumulus_pezpallet_teyrchain_system::Config for Runtime {
-//! // ...
-//! type RelayParentOffset = ConstU32