feat: Rebrand Polkadot/Substrate references to PezkuwiChain
This commit systematically rebrands various references from Parity Technologies' Polkadot/Substrate ecosystem to PezkuwiChain within the kurdistan-sdk. Key changes include: - Updated external repository URLs (zombienet-sdk, parity-db, parity-scale-codec, wasm-instrument) to point to pezkuwichain forks. - Modified internal documentation and code comments to reflect PezkuwiChain naming and structure. - Replaced direct references to with or specific paths within the for XCM, Pezkuwi, and other modules. - Cleaned up deprecated issue and PR references in various and files, particularly in and modules. - Adjusted image and logo URLs in documentation to point to PezkuwiChain assets. - Removed or rephrased comments related to external Polkadot/Substrate PRs and issues. This is a significant step towards fully customizing the SDK for the PezkuwiChain ecosystem.
This commit is contained in:
@@ -1,6 +1,6 @@
|
||||
//! # Upgrade Teyrchain for Asynchronous Backing Compatibility
|
||||
//!
|
||||
//! This guide is relevant for cumulus based teyrchain projects started in 2023 or before, whose
|
||||
//! This guide is relevant for pezcumulus based teyrchain projects started in 2023 or before, whose
|
||||
//! backing process is synchronous where parablocks can only be built on the latest Relay Chain
|
||||
//! block. Async Backing allows collators to build parablocks on older Relay Chain blocks and create
|
||||
//! pipelines of multiple pending parablocks. This parallel block generation increases efficiency
|
||||
@@ -53,8 +53,8 @@
|
||||
//! 3. Establish constants `MILLISECS_PER_BLOCK` and `SLOT_DURATION` if not already present in the
|
||||
//! runtime.
|
||||
//! ```ignore
|
||||
//! // `SLOT_DURATION` is picked up by `pallet_timestamp` which is in turn picked
|
||||
//! // up by `pallet_aura` to implement `fn slot_duration()`.
|
||||
//! // `SLOT_DURATION` is picked up by `pezpallet_timestamp` which is in turn picked
|
||||
//! // up by `pezpallet_aura` to implement `fn slot_duration()`.
|
||||
//! //
|
||||
//! // Change this to adjust the block time.
|
||||
//! pub const MILLISECS_PER_BLOCK: u64 = 12000;
|
||||
@@ -83,14 +83,14 @@
|
||||
//! }
|
||||
//! ```
|
||||
//!
|
||||
//! 5. Configure `pallet_aura` in the runtime.
|
||||
//! 5. Configure `pezpallet_aura` in the runtime.
|
||||
//!
|
||||
//! - Set `AllowMultipleBlocksPerSlot` to `false` (don't worry, we will set it to `true` when we
|
||||
//! activate async backing in phase 3).
|
||||
//!
|
||||
//! - Define `pallet_aura::SlotDuration` using our constant `SLOT_DURATION`
|
||||
//! - Define `pezpallet_aura::SlotDuration` using our constant `SLOT_DURATION`
|
||||
//! ```ignore
|
||||
//! impl pallet_aura::Config for Runtime {
|
||||
//! impl pezpallet_aura::Config for Runtime {
|
||||
//! ..
|
||||
//! type AllowMultipleBlocksPerSlot = ConstBool<false>;
|
||||
//! #[cfg(feature = "experimental")]
|
||||
@@ -99,22 +99,22 @@
|
||||
//! }
|
||||
//! ```
|
||||
//!
|
||||
//! 6. Update `sp_consensus_aura::AuraApi::slot_duration` in `sp_api::impl_runtime_apis` to match
|
||||
//! 6. Update `pezsp_consensus_aura::AuraApi::slot_duration` in `pezsp_api::impl_runtime_apis` to match
|
||||
//! the constant `SLOT_DURATION`
|
||||
#![doc = docify::embed!("../../templates/teyrchain/runtime/src/apis.rs", impl_slot_duration)]
|
||||
//!
|
||||
//! 7. Implement the `AuraUnincludedSegmentApi`, which allows the collator client to query its
|
||||
//! runtime to determine whether it should author a block.
|
||||
//!
|
||||
//! - Add the dependency `cumulus-primitives-aura` to the `runtime/Cargo.toml` file for your
|
||||
//! - Add the dependency `pezcumulus-primitives-aura` to the `runtime/Cargo.toml` file for your
|
||||
//! runtime
|
||||
//! ```ignore
|
||||
//! ..
|
||||
//! cumulus-primitives-aura = { path = "../../../../primitives/aura", default-features = false }
|
||||
//! pezcumulus-primitives-aura = { path = "../../../../primitives/aura", default-features = false }
|
||||
//! ..
|
||||
//! ```
|
||||
//!
|
||||
//! - In the same file, add `"cumulus-primitives-aura/std",` to the `std` feature.
|
||||
//! - In the same file, add `"pezcumulus-primitives-aura/std",` to the `std` feature.
|
||||
//!
|
||||
//! - Inside the `impl_runtime_apis!` block for your runtime, implement the
|
||||
//! `cumulus_primitives_aura::AuraUnincludedSegmentApi` as shown below.
|
||||
@@ -139,10 +139,10 @@
|
||||
//! 1. Import `cumulus_primitives_core::ValidationCode` to `node/src/service.rs`.
|
||||
#![doc = docify::embed!("../../templates/teyrchain/node/src/service.rs", cumulus_primitives)]
|
||||
//!
|
||||
//! 2. In `node/src/service.rs`, modify `sc_service::spawn_tasks` to use a clone of `Backend` rather
|
||||
//! 2. In `node/src/service.rs`, modify `pezsc_service::spawn_tasks` to use a clone of `Backend` rather
|
||||
//! than the original
|
||||
//! ```ignore
|
||||
//! sc_service::spawn_tasks(sc_service::SpawnTasksParams {
|
||||
//! pezsc_service::spawn_tasks(pezsc_service::SpawnTasksParams {
|
||||
//! ..
|
||||
//! backend: backend.clone(),
|
||||
//! ..
|
||||
@@ -197,7 +197,7 @@
|
||||
//! 6. In `start_consensus()` replace `basic_aura::run` with `aura::run`
|
||||
//! ```ignore
|
||||
//! let fut =
|
||||
//! aura::run::<Block, sp_consensus_aura::sr25519::AuthorityPair, _, _, _, _, _, _, _, _, _>(
|
||||
//! aura::run::<Block, pezsp_consensus_aura::sr25519::AuthorityPair, _, _, _, _, _, _, _, _, _>(
|
||||
//! params,
|
||||
//! );
|
||||
//! task_manager.spawn_essential_handle().spawn("aura", None, fut);
|
||||
@@ -207,7 +207,7 @@
|
||||
//!
|
||||
//! This phase consists of changes to your teyrchain’s runtime that activate async backing feature.
|
||||
//!
|
||||
//! 1. Configure `pallet_aura`, setting `AllowMultipleBlocksPerSlot` to true in
|
||||
//! 1. Configure `pezpallet_aura`, setting `AllowMultipleBlocksPerSlot` to true in
|
||||
//! `runtime/src/lib.rs`.
|
||||
#![doc = docify::embed!("../../templates/teyrchain/runtime/src/configs/mod.rs", aura_config)]
|
||||
//!
|
||||
@@ -224,11 +224,11 @@
|
||||
//! 4. Update `MAXIMUM_BLOCK_WEIGHT` to reflect the increased time available for block production.
|
||||
#![doc = docify::embed!("../../templates/teyrchain/runtime/src/lib.rs", max_block_weight)]
|
||||
//!
|
||||
//! 5. Add a feature flagged alternative for `MinimumPeriod` in `pallet_timestamp`. The type should
|
||||
//! 5. Add a feature flagged alternative for `MinimumPeriod` in `pezpallet_timestamp`. The type should
|
||||
//! be `ConstU64<0>` with the feature flag experimental, and `ConstU64<{SLOT_DURATION / 2}>`
|
||||
//! without.
|
||||
//! ```ignore
|
||||
//! impl pallet_timestamp::Config for Runtime {
|
||||
//! impl pezpallet_timestamp::Config for Runtime {
|
||||
//! ..
|
||||
//! #[cfg(feature = "experimental")]
|
||||
//! type MinimumPeriod = ConstU64<0>;
|
||||
@@ -246,7 +246,7 @@
|
||||
//! actual time not matching up, stalling the teyrchain.
|
||||
//!
|
||||
//! One strategy to deal with this issue is to instead rely on relay chain block numbers for timing.
|
||||
//! Relay block number is kept track of by each teyrchain in `pallet-teyrchain-system` with the
|
||||
//! Relay block number is kept track of by each teyrchain in `pezpallet-teyrchain-system` with the
|
||||
//! storage value `LastRelayChainBlockNumber`. This value can be obtained and used wherever timing
|
||||
//! based on block number is needed.
|
||||
|
||||
|
||||
@@ -1 +0,0 @@
|
||||
//! # Cumulus Enabled Teyrchain
|
||||
@@ -129,9 +129,9 @@
|
||||
//! ### Teyrchain Slot Duration
|
||||
//!
|
||||
//! A common source of confusion is the correct configuration of the `SlotDuration` that is passed
|
||||
//! to `pallet-aura`.
|
||||
//! to `pezpallet-aura`.
|
||||
//! ```ignore
|
||||
//! impl pallet_aura::Config for Runtime {
|
||||
//! impl pezpallet_aura::Config for Runtime {
|
||||
//! // ...
|
||||
//! type SlotDuration = ConstU64<SLOT_DURATION>;
|
||||
//! }
|
||||
|
||||
@@ -44,7 +44,7 @@
|
||||
//! ### Runtime integration
|
||||
//!
|
||||
//! From the runtime side only the
|
||||
//! [`CheckMetadataHash`](frame_metadata_hash_extension::CheckMetadataHash) needs to be added to the
|
||||
//! [`CheckMetadataHash`](pezframe_metadata_hash_extension::CheckMetadataHash) needs to be added to the
|
||||
//! list of signed extension:
|
||||
#![doc = docify::embed!("../../templates/teyrchain/runtime/src/lib.rs", template_signed_extra)]
|
||||
//!
|
||||
@@ -64,19 +64,19 @@
|
||||
//!
|
||||
//! The extension does not work with the native runtime, because the
|
||||
//! `RUNTIME_METADATA_HASH` environment variable is not set when building the
|
||||
//! `frame-metadata-hash-extension` crate.
|
||||
//! `pezframe-metadata-hash-extension` crate.
|
||||
//!
|
||||
//! </div>
|
||||
//!
|
||||
//! ### Enable metadata hash generation
|
||||
//!
|
||||
//! The metadata hash generation needs to be enabled when building the wasm binary. The
|
||||
//! `substrate-wasm-builder` supports this out of the box:
|
||||
//! `bizinikiwi-wasm-builder` supports this out of the box:
|
||||
#![doc = docify::embed!("../../templates/teyrchain/runtime/build.rs", template_enable_metadata_hash)]
|
||||
//!
|
||||
//! > **Note:**
|
||||
//! >
|
||||
//! > The `metadata-hash` feature needs to be enabled for the `substrate-wasm-builder` to enable the
|
||||
//! > The `metadata-hash` feature needs to be enabled for the `bizinikiwi-wasm-builder` to enable the
|
||||
//! > code for being able to generate the metadata hash. It is also recommended to put the metadata
|
||||
//! > hash generation behind a feature in the runtime as shown above. The reason behind is that it
|
||||
//! > adds a lot of code which increases the compile time and the generation itself also increases
|
||||
|
||||
@@ -2,8 +2,8 @@
|
||||
//!
|
||||
//! This guide will teach you how to enable storage weight reclaiming for a teyrchain. The
|
||||
//! explanations in this guide assume a project structure similar to the one detailed in
|
||||
//! the [substrate documentation](crate::pezkuwi_sdk::substrate#anatomy-of-a-binary-crate). Full
|
||||
//! technical details are available in the original [pull request](https://github.com/paritytech/polkadot-sdk/pull/3002).
|
||||
//! the [bizinikiwi documentation](crate::pezkuwi_sdk::bizinikiwi#anatomy-of-a-binary-crate). Full
|
||||
//! technical details are available in the original [pull request](https://github.com/pezkuwichain/kurdistan-sdk/issues/111).
|
||||
//!
|
||||
//! # What is PoV reclaim?
|
||||
//! When a teyrchain submits a block to a relay chain like Pezkuwi or Kusama, it sends the block
|
||||
@@ -12,7 +12,7 @@
|
||||
//! validators distribute this PoV among themselves over the network. This distribution is costly
|
||||
//! and limits the size of the storage proof. The storage weight dimension of FRAME weights reflects
|
||||
//! this cost and limits the size of the storage proof. However, the storage weight determined
|
||||
//! during [benchmarking](crate::reference_docs::frame_benchmarking_weight) represents the worst
|
||||
//! during [benchmarking](crate::reference_docs::pezframe_benchmarking_weight) represents the worst
|
||||
//! case. In reality, runtime operations often consume less space in the storage proof. PoV reclaim
|
||||
//! offers a mechanism to reclaim the difference between the benchmarked worst-case and the real
|
||||
//! proof-size consumption.
|
||||
@@ -25,10 +25,10 @@
|
||||
//! ability to fetch the size of the storage proof from the node. The reclaim
|
||||
//! mechanism uses the
|
||||
//! [`storage_proof_size`](cumulus_primitives_proof_size_hostfunction::storage_proof_size)
|
||||
//! host function for this purpose. For convenience, cumulus provides
|
||||
//! host function for this purpose. For convenience, pezcumulus provides
|
||||
//! [`TeyrchainHostFunctions`](cumulus_client_service::TeyrchainHostFunctions), a set of
|
||||
//! host functions typically used by cumulus-based teyrchains. In the binary crate of your
|
||||
//! teyrchain, find the instantiation of the [`WasmExecutor`](sc_executor::WasmExecutor) and set the
|
||||
//! host functions typically used by pezcumulus-based teyrchains. In the binary crate of your
|
||||
//! teyrchain, find the instantiation of the [`WasmExecutor`](pezsc_executor::WasmExecutor) and set the
|
||||
//! correct generic type.
|
||||
//!
|
||||
//! This example from the teyrchain-template shows a type definition that includes the correct
|
||||
@@ -46,9 +46,9 @@
|
||||
//! The reclaim mechanism reads the size of the currently recorded storage proof multiple times
|
||||
//! during block authoring and block import. Proof recording during authoring is already enabled on
|
||||
//! teyrchains. You must also ensure that storage proof recording is enabled during block import.
|
||||
//! Find where your node builds the fundamental substrate components by calling
|
||||
//! [`new_full_parts`](sc_service::new_full_parts). Replace this
|
||||
//! with [`new_full_parts_record_import`](sc_service::new_full_parts_record_import) and
|
||||
//! Find where your node builds the fundamental bizinikiwi components by calling
|
||||
//! [`new_full_parts`](pezsc_service::new_full_parts). Replace this
|
||||
//! with [`new_full_parts_record_import`](pezsc_service::new_full_parts_record_import) and
|
||||
//! pass `true` as the last parameter to enable import recording.
|
||||
#![doc = docify::embed!("../../templates/teyrchain/node/src/service.rs", component_instantiation)]
|
||||
//!
|
||||
|
||||
@@ -28,7 +28,7 @@
|
||||
//! latency and reduces throughput, affecting the overall performance of the teyrchain.
|
||||
//!
|
||||
//! # Building on Older Pelay Parents
|
||||
//! Cumulus offers a way to mitigate the occurence of forks. Instead of picking a block at the tip
|
||||
//! Pezcumulus offers a way to mitigate the occurence of forks. Instead of picking a block at the tip
|
||||
//! of the relay chain to build blocks, the node side can pick a relay chain block that is older. By
|
||||
//! building on 12s old relay chain blocks, forks will already have settled and the teyrchain can
|
||||
//! build fork-free.
|
||||
|
||||
@@ -24,13 +24,13 @@
|
||||
pub mod your_first_pallet;
|
||||
|
||||
/// Write your first real [runtime](`crate::reference_docs::wasm_meta_protocol`),
|
||||
/// compiling it to [WASM](crate::pezkuwi_sdk::substrate#wasm-build).
|
||||
/// compiling it to [WASM](crate::pezkuwi_sdk::bizinikiwi#wasm-build).
|
||||
pub mod your_first_runtime;
|
||||
|
||||
/// Running the given runtime with a node. No specific consensus mechanism is used at this stage.
|
||||
pub mod your_first_node;
|
||||
|
||||
/// How to enhance a given runtime and node to be cumulus-enabled, run it as a teyrchain
|
||||
/// How to enhance a given runtime and node to be pezcumulus-enabled, run it as a teyrchain
|
||||
/// and connect it to a relay-chain.
|
||||
// pub mod your_first_teyrchain;
|
||||
|
||||
|
||||
@@ -0,0 +1 @@
|
||||
//! # Pezcumulus Enabled Teyrchain
|
||||
@@ -6,7 +6,7 @@
|
||||
//! other options when it comes to running a node.
|
||||
//!
|
||||
//! [`your_first_runtime`] is a runtime with no consensus related code, and therefore can only be
|
||||
//! executed with a node that also expects no consensus ([`sc_consensus_manual_seal`]).
|
||||
//! executed with a node that also expects no consensus ([`pezsc_consensus_manual_seal`]).
|
||||
//! `pezkuwi-omni-node`'s [`--dev-block-time`] precisely does this.
|
||||
//!
|
||||
//! > All of the following steps are coded as unit tests of this module. Please see `Source` of the
|
||||
@@ -28,7 +28,7 @@
|
||||
//! described in [`crate::guides::your_first_runtime#genesis-configuration`].
|
||||
//!
|
||||
//! ```text
|
||||
//! cargo install staging-chain-spec-builder
|
||||
//! cargo install pezstaging-chain-spec-builder
|
||||
//! ```
|
||||
//!
|
||||
//! > The name of the crate is prefixed with `staging` as the crate name `chain-spec-builder` on
|
||||
@@ -49,7 +49,7 @@
|
||||
//! ### Building Chain Spec
|
||||
//!
|
||||
//! Next, we can generate the corresponding chain-spec file. For this example, we will use the
|
||||
//! `development` (`sp_genesis_config::DEVELOPMENT`) preset.
|
||||
//! `development` (`pezsp_genesis_config::DEVELOPMENT`) preset.
|
||||
//!
|
||||
//! Note that we intend to run this chain-spec with `pezkuwi-omni-node`, which is tailored for
|
||||
//! running teyrchains. This requires the chain-spec to always contain the `para_id` and a
|
||||
@@ -82,7 +82,7 @@
|
||||
//!
|
||||
//! > Note that we always prefer to use `--tmp` for testing, as it will save the chain state to a
|
||||
//! > temporary folder, allowing the chain-to be easily restarted without `purge-chain`. See
|
||||
//! > [`sc_cli::commands::PurgeChainCmd`] and [`sc_cli::commands::RunCmd::tmp`] for more info.
|
||||
//! > [`pezsc_cli::commands::PurgeChainCmd`] and [`pezsc_cli::commands::RunCmd::tmp`] for more info.
|
||||
//!
|
||||
//! This will start the node and import the blocks. Note while using `--dev-block-time`, the node
|
||||
//! will use the testing-specific manual-seal consensus. This is an efficient way to test the
|
||||
@@ -104,8 +104,8 @@ mod tests {
|
||||
use assert_cmd::assert::OutputAssertExt;
|
||||
use cmd_lib::*;
|
||||
use rand::Rng;
|
||||
use sc_chain_spec::{DEV_RUNTIME_PRESET, LOCAL_TESTNET_RUNTIME_PRESET};
|
||||
use sp_genesis_builder::PresetId;
|
||||
use pezsc_chain_spec::{DEV_RUNTIME_PRESET, LOCAL_TESTNET_RUNTIME_PRESET};
|
||||
use pezsp_genesis_builder::PresetId;
|
||||
use std::{
|
||||
io::{BufRead, BufReader},
|
||||
path::PathBuf,
|
||||
@@ -182,7 +182,7 @@ mod tests {
|
||||
.arg("build")
|
||||
.arg("--release")
|
||||
.arg("-p")
|
||||
.arg("staging-chain-spec-builder")
|
||||
.arg("pezstaging-chain-spec-builder")
|
||||
.assert()
|
||||
.success();
|
||||
}
|
||||
@@ -224,7 +224,7 @@ mod tests {
|
||||
block_time: u64,
|
||||
maybe_preset: Option<PresetId>,
|
||||
) {
|
||||
sp_tracing::try_init_simple();
|
||||
pezsp_tracing::try_init_simple();
|
||||
maybe_build_runtimes();
|
||||
maybe_build_chain_spec_builder();
|
||||
maybe_build_omni_node();
|
||||
|
||||
@@ -77,21 +77,21 @@
|
||||
//! details:
|
||||
//!
|
||||
//! - Where do `T::AccountId` and `T::RuntimeOrigin` come from? These are both defined in
|
||||
//! [`frame::prelude::frame_system::Config`], therefore we can access them in `T`.
|
||||
//! [`frame::prelude::pezframe_system::Config`], therefore we can access them in `T`.
|
||||
//! - What is `ensure_signed`, and what does it do with the aforementioned `T::RuntimeOrigin`? This
|
||||
//! is outside the scope of this guide, and you can learn more about it in the origin reference
|
||||
//! document ([`crate::reference_docs::frame_origin`]). For now, you should only know the
|
||||
//! signature of the function: it takes a generic `T::RuntimeOrigin` and returns a
|
||||
//! `Result<T::AccountId, _>`. So by the end of this function call, we know that this dispatchable
|
||||
//! was signed by `sender`.
|
||||
#![doc = docify::embed!("../../substrate/frame/system/src/lib.rs", ensure_signed)]
|
||||
#![doc = docify::embed!("../../bizinikiwi/pezframe/system/src/lib.rs", ensure_signed)]
|
||||
//!
|
||||
//! - Where does `mutate`, `get` and `insert` and other storage APIs come from? All of them are
|
||||
//! explained in the corresponding `type`, for example, for `Balances::<T>::insert`, you can look
|
||||
//! into [`frame::prelude::StorageMap::insert`].
|
||||
//!
|
||||
//! - The return type of all dispatchable functions is [`frame::prelude::DispatchResult`]:
|
||||
#![doc = docify::embed!("../../substrate/frame/support/src/dispatch.rs", DispatchResult)]
|
||||
#![doc = docify::embed!("../../bizinikiwi/pezframe/support/src/dispatch.rs", DispatchResult)]
|
||||
//!
|
||||
//! Which is more or less a normal Rust `Result`, with a custom [`frame::prelude::DispatchError`] as
|
||||
//! the `Err` variant. We won't cover this error in detail here, but importantly you should know
|
||||
@@ -143,16 +143,16 @@
|
||||
//! Next, we create a "test runtime" in order to test our pallet. Recall from
|
||||
//! [`crate::pezkuwi_sdk::frame_runtime`] that a runtime is a collection of pallets, expressed
|
||||
//! through [`frame::runtime::prelude::construct_runtime`]. All runtimes also have to include
|
||||
//! [`frame::prelude::frame_system`]. So we expect to see a runtime with two pallet, `frame_system`
|
||||
//! [`frame::prelude::pezframe_system`]. So we expect to see a runtime with two pallet, `pezframe_system`
|
||||
//! and the one we just wrote.
|
||||
#![doc = docify::embed!("./packages/guides/first-pallet/src/lib.rs", runtime)]
|
||||
//!
|
||||
//! > [`frame::pallet_macros::derive_impl`] is a FRAME feature that enables developers to have
|
||||
//! > [`frame::pezpallet_macros::derive_impl`] is a FRAME feature that enables developers to have
|
||||
//! > defaults for associated types.
|
||||
//!
|
||||
//! Recall that within our pallet, (almost) all blocks of code are generic over `<T: Config>`. And,
|
||||
//! because `trait Config: frame_system::Config`, we can get access to all items in `Config` (or
|
||||
//! `frame_system::Config`) using `T::NameOfItem`. This is all within the boundaries of how
|
||||
//! because `trait Config: pezframe_system::Config`, we can get access to all items in `Config` (or
|
||||
//! `pezframe_system::Config`) using `T::NameOfItem`. This is all within the boundaries of how
|
||||
//! Rust traits and generics work. If unfamiliar with this pattern, read
|
||||
//! [`crate::reference_docs::trait_based_programming`] before going further.
|
||||
//!
|
||||
@@ -164,11 +164,11 @@
|
||||
//!
|
||||
//! Another way to think about this is that within a pallet, a lot of types are "unknown" and, we
|
||||
//! only know that they will be provided at some later point. For example, when you write
|
||||
//! `T::AccountId` (which is short for `<T as frame_system::Config>::AccountId`) in your pallet,
|
||||
//! `T::AccountId` (which is short for `<T as pezframe_system::Config>::AccountId`) in your pallet,
|
||||
//! you are in fact saying "*Some type `AccountId` that will be known later*". That "later" is in
|
||||
//! fact when you specify these types when you implement all `Config` traits for `Runtime`.
|
||||
//!
|
||||
//! As you see above, `frame_system::Config` is setting the `AccountId` to `u64`. Of course, a real
|
||||
//! As you see above, `pezframe_system::Config` is setting the `AccountId` to `u64`. Of course, a real
|
||||
//! runtime will not use this type, and instead reside to a proper type like a 32-byte standard
|
||||
//! public key. This is a HUGE benefit that FRAME developers can tap into: through the framework
|
||||
//! being so generic, different types can always be customized to simple things when needed.
|
||||
@@ -259,7 +259,7 @@
|
||||
//! by one character. FRAME errors are exactly a solution to maintain readability, whilst fixing
|
||||
//! the drawbacks mentioned. In short, we use an enum to represent different variants of our
|
||||
//! error. These variants are then mapped in an efficient way (using only `u8` indices) to
|
||||
//! [`sp_runtime::DispatchError::Module`]. Read more about this in [`pallet::error`].
|
||||
//! [`pezsp_runtime::DispatchError::Module`]. Read more about this in [`pallet::error`].
|
||||
//!
|
||||
//! - **Event**: Events are akin to the return type of dispatchables. They are mostly data blobs
|
||||
//! emitted by the runtime to let outside world know what is happening inside the pallet. Since
|
||||
@@ -304,7 +304,7 @@
|
||||
//! RuntimeEvent`) is generated by
|
||||
//! [`construct_runtime`](frame::runtime::prelude::construct_runtime). An interesting way to inspect
|
||||
//! this type is to see its definition in rust-docs:
|
||||
//! [`crate::guides::your_first_pallet::pallet_v2::tests::runtime_v2::RuntimeEvent`].
|
||||
//! [`crate::guides::your_first_pallet::pezpallet_v2::tests::runtime_v2::RuntimeEvent`].
|
||||
//!
|
||||
//!
|
||||
//! ## What Next?
|
||||
@@ -317,15 +317,15 @@
|
||||
//! - [`crate::reference_docs::frame_runtime_types`].
|
||||
//! - The pallet we wrote in this guide was using `dev_mode`, learn more in [`pallet::config`].
|
||||
//! - Learn more about the individual pallet items/macros, such as event and errors and call, in
|
||||
//! [`frame::pallet_macros`].
|
||||
//! [`frame::pezpallet_macros`].
|
||||
//!
|
||||
//! [`pallet::storage`]: frame_support::pallet_macros::storage
|
||||
//! [`pallet::call`]: frame_support::pallet_macros::call
|
||||
//! [`pallet::event`]: frame_support::pallet_macros::event
|
||||
//! [`pallet::error`]: frame_support::pallet_macros::error
|
||||
//! [`pallet::pallet`]: frame_support::pallet
|
||||
//! [`pallet::config`]: frame_support::pallet_macros::config
|
||||
//! [`pallet::generate_deposit`]: frame_support::pallet_macros::generate_deposit
|
||||
//! [`pallet::storage`]: pezframe_support::pezpallet_macros::storage
|
||||
//! [`pallet::call`]: pezframe_support::pezpallet_macros::call
|
||||
//! [`pallet::event`]: pezframe_support::pezpallet_macros::event
|
||||
//! [`pallet::error`]: pezframe_support::pezpallet_macros::error
|
||||
//! [`pallet::pallet`]: pezframe_support::pallet
|
||||
//! [`pallet::config`]: pezframe_support::pezpallet_macros::config
|
||||
//! [`pallet::generate_deposit`]: pezframe_support::pezpallet_macros::generate_deposit
|
||||
|
||||
#[docify::export]
|
||||
#[frame::pallet(dev_mode)]
|
||||
@@ -333,7 +333,7 @@ pub mod shell_pallet {
|
||||
use frame::prelude::*;
|
||||
|
||||
#[pallet::config]
|
||||
pub trait Config: frame_system::Config {}
|
||||
pub trait Config: pezframe_system::Config {}
|
||||
|
||||
#[pallet::pallet]
|
||||
pub struct Pallet<T>(_);
|
||||
@@ -347,7 +347,7 @@ pub mod pallet {
|
||||
pub type Balance = u128;
|
||||
|
||||
#[pallet::config]
|
||||
pub trait Config: frame_system::Config {}
|
||||
pub trait Config: pezframe_system::Config {}
|
||||
|
||||
#[pallet::pallet]
|
||||
pub struct Pallet<T>(_);
|
||||
@@ -459,26 +459,26 @@ pub mod pallet {
|
||||
// we need to reference our `mod pallet` as an identifier to pass to
|
||||
// `construct_runtime`.
|
||||
// YOU HAVE TO CHANGE THIS LINE BASED ON YOUR TEMPLATE
|
||||
use crate::guides::your_first_pallet::pallet as pallet_currency;
|
||||
use crate::guides::your_first_pallet::pallet as pezpallet_currency;
|
||||
|
||||
construct_runtime!(
|
||||
pub enum Runtime {
|
||||
// ---^^^^^^ This is where `enum Runtime` is defined.
|
||||
System: frame_system,
|
||||
Currency: pallet_currency,
|
||||
System: pezframe_system,
|
||||
Currency: pezpallet_currency,
|
||||
}
|
||||
);
|
||||
|
||||
#[derive_impl(frame_system::config_preludes::TestDefaultConfig)]
|
||||
impl frame_system::Config for Runtime {
|
||||
#[derive_impl(pezframe_system::config_preludes::TestDefaultConfig)]
|
||||
impl pezframe_system::Config for Runtime {
|
||||
type Block = MockBlock<Runtime>;
|
||||
// within pallet we just said `<T as frame_system::Config>::AccountId`, now we
|
||||
// within pallet we just said `<T as pezframe_system::Config>::AccountId`, now we
|
||||
// finally specified it.
|
||||
type AccountId = u64;
|
||||
}
|
||||
|
||||
// our simple pallet has nothing to be configured.
|
||||
impl pallet_currency::Config for Runtime {}
|
||||
impl pezpallet_currency::Config for Runtime {}
|
||||
}
|
||||
|
||||
pub(crate) use runtime::*;
|
||||
@@ -500,7 +500,7 @@ pub mod pallet {
|
||||
|
||||
#[docify::export]
|
||||
pub(crate) struct StateBuilder {
|
||||
balances: Vec<(<Runtime as frame_system::Config>::AccountId, Balance)>,
|
||||
balances: Vec<(<Runtime as pezframe_system::Config>::AccountId, Balance)>,
|
||||
}
|
||||
|
||||
#[docify::export(default_state_builder)]
|
||||
@@ -514,7 +514,7 @@ pub mod pallet {
|
||||
impl StateBuilder {
|
||||
fn add_balance(
|
||||
mut self,
|
||||
who: <Runtime as frame_system::Config>::AccountId,
|
||||
who: <Runtime as pezframe_system::Config>::AccountId,
|
||||
amount: Balance,
|
||||
) -> Self {
|
||||
self.balances.push((who, amount));
|
||||
@@ -665,17 +665,17 @@ pub mod pallet {
|
||||
}
|
||||
|
||||
#[frame::pallet(dev_mode)]
|
||||
pub mod pallet_v2 {
|
||||
pub mod pezpallet_v2 {
|
||||
use super::pallet::Balance;
|
||||
use frame::prelude::*;
|
||||
|
||||
#[docify::export(config_v2)]
|
||||
#[pallet::config]
|
||||
pub trait Config: frame_system::Config {
|
||||
pub trait Config: pezframe_system::Config {
|
||||
/// The overarching event type of the runtime.
|
||||
#[allow(deprecated)]
|
||||
type RuntimeEvent: From<Event<Self>>
|
||||
+ IsType<<Self as frame_system::Config>::RuntimeEvent>
|
||||
+ IsType<<Self as pezframe_system::Config>::RuntimeEvent>
|
||||
+ TryInto<Event<Self>>;
|
||||
}
|
||||
|
||||
@@ -740,22 +740,22 @@ pub mod pallet_v2 {
|
||||
#[docify::export]
|
||||
pub mod runtime_v2 {
|
||||
use super::*;
|
||||
use crate::guides::your_first_pallet::pallet_v2 as pallet_currency;
|
||||
use crate::guides::your_first_pallet::pezpallet_v2 as pezpallet_currency;
|
||||
|
||||
construct_runtime!(
|
||||
pub enum Runtime {
|
||||
System: frame_system,
|
||||
Currency: pallet_currency,
|
||||
System: pezframe_system,
|
||||
Currency: pezpallet_currency,
|
||||
}
|
||||
);
|
||||
|
||||
#[derive_impl(frame_system::config_preludes::TestDefaultConfig)]
|
||||
impl frame_system::Config for Runtime {
|
||||
#[derive_impl(pezframe_system::config_preludes::TestDefaultConfig)]
|
||||
impl pezframe_system::Config for Runtime {
|
||||
type Block = MockBlock<Runtime>;
|
||||
type AccountId = u64;
|
||||
}
|
||||
|
||||
impl pallet_currency::Config for Runtime {
|
||||
impl pezpallet_currency::Config for Runtime {
|
||||
type RuntimeEvent = RuntimeEvent;
|
||||
}
|
||||
}
|
||||
|
||||
@@ -10,16 +10,16 @@
|
||||
//! A runtime shares a few similar setup requirements as with a pallet:
|
||||
//!
|
||||
//! * importing [`frame`], [`codec`], and [`scale_info`] crates.
|
||||
//! * following the [`std` feature-gating](crate::pezkuwi_sdk::substrate#wasm-build) pattern.
|
||||
//! * following the [`std` feature-gating](crate::pezkuwi_sdk::bizinikiwi#wasm-build) pattern.
|
||||
//!
|
||||
//! But, more specifically, it also contains:
|
||||
//!
|
||||
//! * a `build.rs` that uses [`substrate_wasm_builder`]. This entails declaring
|
||||
//! * a `build.rs` that uses [`bizinikiwi_wasm_builder`]. This entails declaring
|
||||
//! `[build-dependencies]` in the Cargo manifest file:
|
||||
//!
|
||||
//! ```ignore
|
||||
//! [build-dependencies]
|
||||
//! substrate-wasm-builder = { ... }
|
||||
//! bizinikiwi-wasm-builder = { ... }
|
||||
//! ```
|
||||
//!
|
||||
//! >Note that a runtime must always be one-runtime-per-crate. You cannot define multiple runtimes
|
||||
@@ -49,13 +49,13 @@
|
||||
//! their `Config` need to be implemented for `struct Runtime`:
|
||||
#![doc = docify::embed!("./packages/guides/first-runtime/src/lib.rs", config_impls)]
|
||||
//!
|
||||
//! Notice how we use [`frame::pallet_macros::derive_impl`] to provide "default" configuration items
|
||||
//! Notice how we use [`frame::pezpallet_macros::derive_impl`] to provide "default" configuration items
|
||||
//! for each pallet. Feel free to dive into the definition of each default prelude (eg.
|
||||
//! [`frame::prelude::frame_system::pallet::config_preludes`]) to learn more which types are exactly
|
||||
//! [`frame::prelude::pezframe_system::pallet::config_preludes`]) to learn more which types are exactly
|
||||
//! used.
|
||||
//!
|
||||
//! Recall that in test runtime in [`crate::guides::your_first_pallet`], we provided `type AccountId
|
||||
//! = u64` to `frame_system`, while in this case we rely on whatever is provided by
|
||||
//! = u64` to `pezframe_system`, while in this case we rely on whatever is provided by
|
||||
//! [`SolochainDefaultConfig`], which is indeed a "real" 32 byte account id.
|
||||
//!
|
||||
//! Then, a familiar instance of `construct_runtime` amalgamates all of the pallets:
|
||||
@@ -101,7 +101,7 @@
|
||||
//!
|
||||
//! Once you compile a crate that contains a runtime as above, simply running `cargo build` will
|
||||
//! generate the wasm blobs and place them under `./target/release/wbuild`, as explained
|
||||
//! [here](crate::pezkuwi_sdk::substrate#wasm-build).
|
||||
//! [here](crate::pezkuwi_sdk::bizinikiwi#wasm-build).
|
||||
//!
|
||||
//! ## Genesis Configuration
|
||||
//!
|
||||
@@ -110,7 +110,7 @@
|
||||
//! what is known as a **Chain Specification, or chain spec for short**. A chain spec is the
|
||||
//! primary way to run a new chain.
|
||||
//!
|
||||
//! These APIs are defined in [`sp_genesis_builder`], and are re-exposed as a part of
|
||||
//! These APIs are defined in [`pezsp_genesis_builder`], and are re-exposed as a part of
|
||||
//! [`frame::runtime::apis`]. Therefore, the implementation blocks can be found inside of
|
||||
//! `impl_runtime_apis!` similar to:
|
||||
//!
|
||||
@@ -136,7 +136,7 @@
|
||||
//! The implementation of these function can naturally vary from one runtime to the other, but the
|
||||
//! overall pattern is common. For the case of this runtime, we do the following:
|
||||
//!
|
||||
//! 1. Expose one non-default preset, namely [`sp_genesis_builder::DEV_RUNTIME_PRESET`]. This means
|
||||
//! 1. Expose one non-default preset, namely [`pezsp_genesis_builder::DEV_RUNTIME_PRESET`]. This means
|
||||
//! our runtime has two "presets" of genesis state in total: `DEV_RUNTIME_PRESET` and `None`.
|
||||
#![doc = docify::embed!("./packages/guides/first-runtime/src/lib.rs", preset_names)]
|
||||
//!
|
||||
@@ -167,7 +167,7 @@
|
||||
//! 5. To see a complete example of a runtime+pallet that is similar to this guide, please see
|
||||
//! [`crate::pezkuwi_sdk::templates`].
|
||||
//!
|
||||
//! [`SolochainDefaultConfig`]: struct@frame_system::pallet::config_preludes::SolochainDefaultConfig
|
||||
//! [`SolochainDefaultConfig`]: struct@pezframe_system::pallet::config_preludes::SolochainDefaultConfig
|
||||
|
||||
#[cfg(test)]
|
||||
mod tests {
|
||||
|
||||
Reference in New Issue
Block a user