mirror of
https://github.com/pezkuwichain/pwap.git
synced 2026-06-21 11:01:02 +00:00
Rebrand: polkadot → pezkuwi build fixes
- Fixed TypeScript type assertion issues - Updated imports from api-augment/substrate to api-augment/bizinikiwi - Fixed imgConvert.mjs header and imports - Added @ts-expect-error for runtime-converted types - Fixed all @polkadot copyright headers to @pezkuwi
This commit is contained in:
@@ -4,21 +4,21 @@
|
||||
//! of a blockchain via the [_state transition
|
||||
//! function_][crate::reference_docs::blockchain_state_machines].
|
||||
//!
|
||||
//! Substrate is configurable enough that extrinsics can take any format. In practice, runtimes
|
||||
//! tend to use our [`sp_runtime::generic::UncheckedExtrinsic`] type to represent extrinsics,
|
||||
//! Bizinikiwi is configurable enough that extrinsics can take any format. In practice, runtimes
|
||||
//! tend to use our [`pezsp_runtime::generic::UncheckedExtrinsic`] type to represent extrinsics,
|
||||
//! because it's generic enough to cater for most (if not all) use cases. In Pezkuwi, this is
|
||||
//! configured [here](https://github.com/polkadot-fellows/runtimes/blob/94b2798b69ba6779764e20a50f056e48db78ebef/relay/polkadot/src/lib.rs#L1478)
|
||||
//! at the time of writing.
|
||||
//!
|
||||
//! What follows is a description of how extrinsics based on this
|
||||
//! [`sp_runtime::generic::UncheckedExtrinsic`] type are encoded into bytes. Specifically, we are
|
||||
//! [`pezsp_runtime::generic::UncheckedExtrinsic`] type are encoded into bytes. Specifically, we are
|
||||
//! looking at how extrinsics with a format version of 5 are encoded. This version is itself a part
|
||||
//! of the payload, and if it changes, it indicates that something about the encoding may have
|
||||
//! changed.
|
||||
//!
|
||||
//! # Encoding an Extrinsic
|
||||
//!
|
||||
//! At a high level, all extrinsics compatible with [`sp_runtime::generic::UncheckedExtrinsic`]
|
||||
//! At a high level, all extrinsics compatible with [`pezsp_runtime::generic::UncheckedExtrinsic`]
|
||||
//! are formed from concatenating some details together, as in the following pseudo-code:
|
||||
//!
|
||||
//! ```text
|
||||
@@ -30,14 +30,14 @@
|
||||
//! )
|
||||
//! ```
|
||||
//!
|
||||
//! For clarity, the actual implementation in Substrate looks like this:
|
||||
#![doc = docify::embed!("../../substrate/primitives/runtime/src/generic/unchecked_extrinsic.rs", unchecked_extrinsic_encode_impl)]
|
||||
//! For clarity, the actual implementation in Bizinikiwi looks like this:
|
||||
#![doc = docify::embed!("../../bizinikiwi/primitives/runtime/src/generic/unchecked_extrinsic.rs", unchecked_extrinsic_encode_impl)]
|
||||
//!
|
||||
//! Let's look at how each of these details is constructed:
|
||||
//!
|
||||
//! ## compact_encoded_length
|
||||
//!
|
||||
//! This is a [SCALE compact encoded][frame::deps::codec::Compact] integer which is equal to the
|
||||
//! This is a [SCALE compact encoded][pezframe::deps::codec::Compact] integer which is equal to the
|
||||
//! length, in bytes, of the rest of the extrinsic details.
|
||||
//!
|
||||
//! To obtain this value, we must encode and concatenate together the rest of the extrinsic details
|
||||
@@ -90,25 +90,26 @@
|
||||
//!
|
||||
//! #### from_address
|
||||
//!
|
||||
//! This is the [SCALE encoded][frame::deps::codec] address of the sender of the extrinsic. The
|
||||
//! address is the first generic parameter of [`sp_runtime::generic::UncheckedExtrinsic`], and so
|
||||
//! This is the [SCALE encoded][pezframe::deps::codec] address of the sender of the extrinsic. The
|
||||
//! address is the first generic parameter of [`pezsp_runtime::generic::UncheckedExtrinsic`], and so
|
||||
//! can vary from chain to chain.
|
||||
//!
|
||||
//! The address type used on the Pezkuwi relay chain is [`sp_runtime::MultiAddress<AccountId32>`],
|
||||
//! where `AccountId32` is defined [here][`sp_core::crypto::AccountId32`]. When constructing a
|
||||
//! signed extrinsic to be submitted to a Pezkuwi node, you'll always use the
|
||||
//! [`sp_runtime::MultiAddress::Id`] variant to wrap your `AccountId32`.
|
||||
//! The address type used on the Pezkuwi relay chain is
|
||||
//! [`pezsp_runtime::MultiAddress<AccountId32>`], where `AccountId32` is defined
|
||||
//! [here][`pezsp_core::crypto::AccountId32`]. When constructing a signed extrinsic to be submitted
|
||||
//! to a Pezkuwi node, you'll always use the [`pezsp_runtime::MultiAddress::Id`] variant to wrap
|
||||
//! your `AccountId32`.
|
||||
//!
|
||||
//! #### signature
|
||||
//!
|
||||
//! This is the [SCALE encoded][frame::deps::codec] signature. The signature type is configured via
|
||||
//! the third generic parameter of [`sp_runtime::generic::UncheckedExtrinsic`], which determines the
|
||||
//! shape of the signature and signing algorithm that should be used.
|
||||
//! This is the [SCALE encoded][pezframe::deps::codec] signature. The signature type is configured via
|
||||
//! the third generic parameter of [`pezsp_runtime::generic::UncheckedExtrinsic`], which determines
|
||||
//! the shape of the signature and signing algorithm that should be used.
|
||||
//!
|
||||
//! The signature is obtained by signing the _signed payload_ bytes (see below on how this is
|
||||
//! constructed) using the private key associated with the address and correct algorithm.
|
||||
//!
|
||||
//! The signature type used on the Pezkuwi relay chain is [`sp_runtime::MultiSignature`]; the
|
||||
//! The signature type used on the Pezkuwi relay chain is [`pezsp_runtime::MultiSignature`]; the
|
||||
//! variants there are the types of signature that can be provided.
|
||||
//!
|
||||
//! ### General extrinsics
|
||||
@@ -120,12 +121,12 @@
|
||||
//!
|
||||
//! ### transaction_extensions_extra
|
||||
//!
|
||||
//! This is the concatenation of the [SCALE encoded][frame::deps::codec] bytes representing first a
|
||||
//! This is the concatenation of the [SCALE encoded][pezframe::deps::codec] bytes representing first a
|
||||
//! single byte describing the extension version (this is bumped whenever a change occurs in the
|
||||
//! transaction extension pipeline) followed by the bytes of each of the [_transaction
|
||||
//! extensions_][sp_runtime::traits::TransactionExtension], and are configured by the fourth generic
|
||||
//! parameter of [`sp_runtime::generic::UncheckedExtrinsic`]. Learn more about transaction
|
||||
//! extensions [here][crate::reference_docs::transaction_extensions].
|
||||
//! extensions_][pezsp_runtime::traits::TransactionExtension], and are configured by the fourth
|
||||
//! generic parameter of [`pezsp_runtime::generic::UncheckedExtrinsic`]. Learn more about
|
||||
//! transaction extensions [here][crate::reference_docs::transaction_extensions].
|
||||
//!
|
||||
//! When it comes to constructing an extrinsic, each transaction extension has two things that we
|
||||
//! are interested in here:
|
||||
@@ -141,22 +142,22 @@
|
||||
//! configuration. At the time of writing, Pezkuwi configures them
|
||||
//! [here](https://github.com/polkadot-fellows/runtimes/blob/1dc04eb954eadf8aadb5d83990b89662dbb5a074/relay/polkadot/src/lib.rs#L1432C25-L1432C25).
|
||||
//! Some of the common transaction extensions are defined
|
||||
//! [here][frame::deps::frame_system#transaction-extensions].
|
||||
//! [here][pezframe::deps::pezframe_system#transaction-extensions].
|
||||
//!
|
||||
//! Information about exactly which transaction extensions are present on a chain and in what order
|
||||
//! is also a part of the metadata for the chain. For V15 metadata, it can be [found
|
||||
//! here][frame::deps::frame_support::__private::metadata::v15::ExtrinsicMetadata].
|
||||
//! here][pezframe::deps::pezframe_support::__private::metadata::v15::ExtrinsicMetadata].
|
||||
//!
|
||||
//! ## call_data
|
||||
//!
|
||||
//! This is the main payload of the extrinsic, which is used to determine how the chain's state is
|
||||
//! altered. This is defined by the second generic parameter of
|
||||
//! [`sp_runtime::generic::UncheckedExtrinsic`].
|
||||
//! [`pezsp_runtime::generic::UncheckedExtrinsic`].
|
||||
//!
|
||||
//! A call can be anything that implements [`Encode`][frame::deps::codec::Encode]. In FRAME-based
|
||||
//! A call can be anything that implements [`Encode`][pezframe::deps::codec::Encode]. In FRAME-based
|
||||
//! runtimes, a call is represented as an enum of enums, where the outer enum represents the FRAME
|
||||
//! pallet being called, and the inner enum represents the call being made within that pallet, and
|
||||
//! any arguments to it. Read more about the call enum
|
||||
//! pezpallet being called, and the inner enum represents the call being made within that pezpallet,
|
||||
//! and any arguments to it. Read more about the call enum
|
||||
//! [here][crate::reference_docs::frame_runtime_types].
|
||||
//!
|
||||
//! FRAME `Call` enums are automatically generated, and end up looking something like this:
|
||||
@@ -166,23 +167,23 @@
|
||||
//!
|
||||
//! ```text
|
||||
//! call_data = concat(
|
||||
//! pallet_index,
|
||||
//! pezpallet_index,
|
||||
//! call_index,
|
||||
//! call_args
|
||||
//! )
|
||||
//! ```
|
||||
//!
|
||||
//! - `pallet_index` is a single byte denoting the index of the pallet that we are calling into, and
|
||||
//! is what the tag of the outermost enum will encode to.
|
||||
//! - `call_index` is a single byte denoting the index of the call that we are making the pallet,
|
||||
//! - `pezpallet_index` is a single byte denoting the index of the pezpallet that we are calling
|
||||
//! into, and is what the tag of the outermost enum will encode to.
|
||||
//! - `call_index` is a single byte denoting the index of the call that we are making the pezpallet,
|
||||
//! and is what the tag of the inner enum will encode to.
|
||||
//! - `call_args` are the SCALE encoded bytes for each of the arguments that the call expects, and
|
||||
//! are typically provided as values to the inner enum.
|
||||
//!
|
||||
//! Information about the pallets that exist for a chain (including their indexes), the calls
|
||||
//! available in each pallet (including their indexes), and the arguments required for each call can
|
||||
//! be found in the metadata for the chain. For V15 metadata, this information [is
|
||||
//! here][frame::deps::frame_support::__private::metadata::v15::PalletMetadata].
|
||||
//! available in each pezpallet (including their indexes), and the arguments required for each call
|
||||
//! can be found in the metadata for the chain. For V15 metadata, this information [is
|
||||
//! here][pezframe::deps::pezframe_support::__private::metadata::v15::PalletMetadata].
|
||||
//!
|
||||
//! # The Signed Payload Format
|
||||
//!
|
||||
@@ -202,13 +203,13 @@
|
||||
//!
|
||||
//! The bytes representing `call_data` and `transaction_extensions_extra` can be obtained as
|
||||
//! descibed above. `transaction_extensions_implicit` is constructed by SCALE encoding the
|
||||
//! ["implicit" data][sp_runtime::traits::TransactionExtension::Implicit] for each transaction
|
||||
//! ["implicit" data][pezsp_runtime::traits::TransactionExtension::Implicit] for each transaction
|
||||
//! extension that the chain is using, in order.
|
||||
//!
|
||||
//! Once we've concatenated those together, we hash the result using a Blake2 256bit hasher.
|
||||
//!
|
||||
//! The [`sp_runtime::generic::SignedPayload`] type takes care of assembling the correct payload for
|
||||
//! us, given `call_data` and a tuple of transaction extensions.
|
||||
//! The [`pezsp_runtime::generic::SignedPayload`] type takes care of assembling the correct payload
|
||||
//! for us, given `call_data` and a tuple of transaction extensions.
|
||||
//!
|
||||
//! # The General Transaction Format
|
||||
//!
|
||||
@@ -216,22 +217,22 @@
|
||||
//! extrinsic, such as a traditionally signed transaction. Instead, general transactions should have
|
||||
//! one or more extensions in the transaction extension pipeline that auhtorize origins in some way,
|
||||
//! one of which could be the traditional signature check that happens for all signed transactions
|
||||
//! in the [Checkable](sp_runtime::traits::Checkable) implementation of
|
||||
//! [UncheckedExtrinsic](sp_runtime::generic::UncheckedExtrinsic). Therefore, it is up to each
|
||||
//! in the [Checkable](pezsp_runtime::traits::Checkable) implementation of
|
||||
//! [UncheckedExtrinsic](pezsp_runtime::generic::UncheckedExtrinsic). Therefore, it is up to each
|
||||
//! extension to define the format of the payload it will try to check and authorize the right
|
||||
//! origin type. For an example, look into the [authorization example pallet
|
||||
//! extensions](pallet_example_authorization_tx_extension::extensions)
|
||||
//! origin type. For an example, look into the [authorization example pezpallet
|
||||
//! extensions](pezpallet_example_authorization_tx_extension::extensions)
|
||||
//!
|
||||
//! # Example Encoding
|
||||
//!
|
||||
//! Using [`sp_runtime::generic::UncheckedExtrinsic`], we can construct and encode an extrinsic as
|
||||
//! follows:
|
||||
//! Using [`pezsp_runtime::generic::UncheckedExtrinsic`], we can construct and encode an extrinsic
|
||||
//! as follows:
|
||||
#![doc = docify::embed!("./src/reference_docs/extrinsic_encoding.rs", encoding_example)]
|
||||
|
||||
#[docify::export]
|
||||
pub mod call_data {
|
||||
use codec::{Decode, Encode};
|
||||
use sp_runtime::{traits::Dispatchable, DispatchResultWithInfo};
|
||||
use pezsp_runtime::{traits::Dispatchable, DispatchResultWithInfo};
|
||||
|
||||
// The outer enum composes calls within
|
||||
// different pallets together. We have two
|
||||
@@ -245,7 +246,7 @@ pub mod call_data {
|
||||
}
|
||||
|
||||
// An inner enum represents the calls within
|
||||
// a specific pallet. "PalletA" has one call,
|
||||
// a specific pezpallet. "PalletA" has one call,
|
||||
// "Foo".
|
||||
#[derive(Encode, Decode, Clone)]
|
||||
pub enum PalletACall {
|
||||
@@ -275,9 +276,9 @@ pub mod encoding_example {
|
||||
use super::call_data::{Call, PalletACall};
|
||||
use crate::reference_docs::transaction_extensions::transaction_extensions_example;
|
||||
use codec::Encode;
|
||||
use sp_core::crypto::AccountId32;
|
||||
use sp_keyring::sr25519::Keyring;
|
||||
use sp_runtime::{
|
||||
use pezsp_core::crypto::AccountId32;
|
||||
use pezsp_keyring::sr25519::Keyring;
|
||||
use pezsp_runtime::{
|
||||
generic::{SignedPayload, UncheckedExtrinsic},
|
||||
MultiAddress, MultiSignature,
|
||||
};
|
||||
|
||||
Reference in New Issue
Block a user