pezkuwichain/pezkuwi-runtime-templates
1
0
Fork 0
mirror of https://github.com/pezkuwichain/pezkuwi-runtime-templates.git synced 2026-06-17 22:01:02 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update documentation and templates for Pezkuwi branding

Browse Source
This commit is contained in:
Kurdistan Tech Ministry
2026-01-17 23:19:40 +03:00
parent d839cbd92b
commit 9bd688a742
172 changed files with 12903 additions and 6604 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/modules/ROOT/pages/guides/async_backing.adoc
+3 -3
View File
@@ -4,7 +4,7 @@
= Async Backing
Async backing is a feature of parachains that allow to shorten the block time, get more execution time and speed up transaction inclusion in general. You can read in details what async backing is in the link:https://wiki.polkadot.network/docs/learn-async-backing#candidate-receipt[general guide] and in the link:https://wiki.polkadot.network/docs/maintain-guides-async-backing[update guide]. In our generic template we have included async backing under a feature. This page describes how can you build and test the template with async backing enabled.
Async backing is a feature of teyrchains that allow to shorten the block time, get more execution time and speed up transaction inclusion in general. You can read in details what async backing is in the link:https://wiki.pezkuwi.network/docs/learn-async-backing#candidate-receipt[general guide] and in the link:https://wiki.pezkuwi.network/docs/maintain-guides-async-backing[update guide]. In our generic template we have included async backing under a feature. This page describes how can you build and test the template with async backing enabled.
== How to build
@@ -16,9 +16,9 @@ cargo build --release --features="async-backing"
== How to test
You can always test it against Paseo (it should already have enabled async backing), but the fastest way is to test against a local relay chain. In our repository you can find a script, a config and a link:https://github.com/OpenZeppelin/polkadot-runtime-templates/tree/main/generic-template/zombienet-config[manual] that will run both relay chain and a parachain. To launch a parachain with a relay chain, you will need to run these commands:
You can always test it against Paseo (it should already have enabled async backing), but the fastest way is to test against a local relay chain. In our repository you can find a script, a config and a link:https://github.com/OpenZeppelin/pezkuwi-runtime-templates/tree/main/generic-template/zombienet-config[manual] that will run both relay chain and a teyrchain. To launch a teyrchain with a relay chain, you will need to run these commands:
* Get the Polkadot binaries:
* Get the Pezkuwi binaries:
** If you are using some Linux distro, you can download the binaries:
+
```
docs/modules/ROOT/pages/guides/contract_migration.adoc
+1 -1
View File
@@ -33,7 +33,7 @@ WARNING: You must not use these keys for any production purpose
=== Url for the EVM RPC.
This part is simple. You can use the same url that you would use with the polkadot.js wallet -- it serves the EVM JSON-RPC as well. If you have followed our guide, you can use http://localhost:8844.
This part is simple. You can use the same url that you would use with the pezkuwi.js wallet -- it serves the EVM JSON-RPC as well. If you have followed our guide, you can use http://localhost:8844.
== Step 3: Deploy your contract
docs/modules/ROOT/pages/guides/hrmp_channels.adoc
+32 -32
View File
@@ -2,42 +2,42 @@
:highlightjs-languages: rust
:github-icon: pass:[<svg class="icon"><use href="#github-icon"/></svg>]
= Sending Cross-Chain Messages between Parachains
= Sending Cross-Chain Messages between Teyrchains
The supported way to exchange cross-chain messages (XCM) between parachains is to use Horizontal Relay-routed Message Passing (HRMP) channels.
The supported way to exchange cross-chain messages (XCM) between teyrchains is to use Horizontal Relay-routed Message Passing (HRMP) channels.
Each HRMP channel is unidirectional. In order to enable full connectivity between two parachains, two HRMP channels must be opened: one for sending outgoing XCM and the other for receiving incoming XCM.
Each HRMP channel is unidirectional. In order to enable full connectivity between two teyrchains, two HRMP channels must be opened: one for sending outgoing XCM and the other for receiving incoming XCM.
== Opening an HRMP Channel
Opening a channel between two parachains A and B takes 2 steps:
1. parachain A initiates a channel request
2. parachain B accepts the channel request
Opening a channel between two teyrchains A and B takes 2 steps:
1. teyrchain A initiates a channel request
2. teyrchain B accepts the channel request
For step (1), parachain A calls `hrmp > hrmpInitOpenChannel(recipient, proposedMaxCapacity, proposedMaxMessageSize)` to create a channel request with the input configuration.
For step (1), teyrchain A calls `hrmp > hrmpInitOpenChannel(recipient, proposedMaxCapacity, proposedMaxMessageSize)` to create a channel request with the input configuration.
For step (2), parachain B calls `hrmp > hrmpAcceptOpenChannel(sender)` to accept the channel open request from the input sender.
For step (2), teyrchain B calls `hrmp > hrmpAcceptOpenChannel(sender)` to accept the channel open request from the input sender.
In order to dispatch a call from its sovereign origin, a parachain may use governance to send the encoded call in a Transact instruction to the Relay Chain, but it may also execute this logic autonomously (e.g. on the notification that a channel was requested).
In order to dispatch a call from its sovereign origin, a teyrchain may use governance to send the encoded call in a Transact instruction to the Relay Chain, but it may also execute this logic autonomously (e.g. on the notification that a channel was requested).
== Connecting to Ecosystem Parachains
== Connecting to Ecosystem Teyrchains
The examples in this section include steps to connect to existing parachains in the Polkadot ecosystem. Examples include the following Polkadot parachains:
The examples in this section include steps to connect to existing teyrchains in the Pezkuwi ecosystem. Examples include the following Pezkuwi teyrchains:
1. AssetHub supports managing asset balances as well as the execution of cross-chain transfers.
2. Snowbridge supports sending ERC20 tokens between Polkadot parachains and Ethereum in both directions.
3. HydraDX supports DeFi functionality to provide liquidity to Polkadot.
2. Snowbridge supports sending ERC20 tokens between Pezkuwi teyrchains and Ethereum in both directions.
3. HydraDX supports DeFi functionality to provide liquidity to Pezkuwi.
For all examples:
. `paraId` for the user's parachain is set to `43211234`.
. `proposedMaxCapacity` and `proposedMaxMessageSize` are set to the values of Polkadot `config.hrmpChannelMaxCapacity = 1000` and `config.hrmpChannelMaxMessageSize = 102400`, respectively.
. `paraId` for the user's teyrchain is set to `43211234`.
. `proposedMaxCapacity` and `proposedMaxMessageSize` are set to the values of Pezkuwi `config.hrmpChannelMaxCapacity = 1000` and `config.hrmpChannelMaxMessageSize = 102400`, respectively.
=== AssetHub
AssetHub supports managing asset balances as well as the execution of cross-chain transfers.
AssetHub is a common-good, system parachain and is therefore controlled by relay chain governance. This means it is sufficient to propose opening both channels at once through the relay chain's `GeneralAdmin` track. The proposal should set its call (proposed to be executed) to `utility.batchAll` with the input including 2 calls to `hrmp.forceOpenHrmpChannel` to open a channel in each direction between the user parachain and AssetHub.
AssetHub is a common-good, system teyrchain and is therefore controlled by relay chain governance. This means it is sufficient to propose opening both channels at once through the relay chain's `GeneralAdmin` track. The proposal should set its call (proposed to be executed) to `utility.batchAll` with the input including 2 calls to `hrmp.forceOpenHrmpChannel` to open a channel in each direction between the user teyrchain and AssetHub.
The first call to `hrmp.forceOpenHrmpChannel` proposes opening a unidirectional channel to send XCM from the user parachain to AssetHub. If AssetHub's paraId is set to `1000`, here are the inputs:
The first call to `hrmp.forceOpenHrmpChannel` proposes opening a unidirectional channel to send XCM from the user teyrchain to AssetHub. If AssetHub's paraId is set to `1000`, here are the inputs:
```
hrmp.forceOpenChannel(
sender = 43211234,
@@ -46,7 +46,7 @@ hrmp.forceOpenChannel(
max_message_size = 102400,
)
```
Here is the second call to open a unidirectional channel to send XCM from AssetHub to the user parachain:
Here is the second call to open a unidirectional channel to send XCM from AssetHub to the user teyrchain:
```
hrmp.forceOpenChannel(
sender = 1000,
@@ -56,17 +56,17 @@ hrmp.forceOpenChannel(
)
```
link:https://polkadot.subsquare.io/referenda/438[Here] is a successful example of this proposal which passed to open 2 HRMP channels between Unique Network and AssetHub. link:https://polkadot.polkassembly.io/referenda/594[Here] is another example of a proposal executed to open HRMP Channels between AssetHub and Mythos.
link:https://pezkuwi.subsquare.io/referenda/438[Here] is a successful example of this proposal which passed to open 2 HRMP channels between Unique Network and AssetHub. link:https://pezkuwi.polkassembly.io/referenda/594[Here] is another example of a proposal executed to open HRMP Channels between AssetHub and Mythos.
=== Snowbridge
Snowbridge supports sending ERC20 tokens between Polkadot parachains and Ethereum in both directions.
Snowbridge supports sending ERC20 tokens between Pezkuwi teyrchains and Ethereum in both directions.
Snowbridge leverages AssetHub to mint ERC20 tokens received from Ethereum and send them to parachains. This implies that a prerequisite step for receiving ERC20 tokens via Snowbridge is opening HRMP channels with AssetHub by following the previous section.
Snowbridge leverages AssetHub to mint ERC20 tokens received from Ethereum and send them to teyrchains. This implies that a prerequisite step for receiving ERC20 tokens via Snowbridge is opening HRMP channels with AssetHub by following the previous section.
The standard way of interacting with Snowbridge is to make calls to the link:https://github.com/Snowfork/snowbridge/blob/main/contracts/src/interfaces/IGateway.sol[Gateway] contract deployed on Ethereum at link:https://etherscan.io/address/0x27ca963C279c93801941e1eB8799c23f407d68e7[this address].
If an ERC20 token has already been bridged before, the user may send the following transaction to the Gateway to send ERC20 tokens to parachain `destinationChain` from Ethereum and deposit into account `destinationAddress` on that parachain.
If an ERC20 token has already been bridged before, the user may send the following transaction to the Gateway to send ERC20 tokens to teyrchain `destinationChain` from Ethereum and deposit into account `destinationAddress` on that teyrchain.
```solidity, ignore
function sendToken(address token, ParaID destinationChain, MultiAddress destinationAddress, uint128 destinationFee, uint128 amount)
external
@@ -77,17 +77,17 @@ If the ERC20 tokens has not been bridged before, there is a prerequisite step to
```solidity, ignore
function registerToken(address token) external payable;
```
The above function sends a message to the AssetHub parachain to register a new fungible asset in the `ForeignAssets` pezpallet. To account for delivery costs, the above function charges a fee in Ether which may be retrieved beforehand by calling `quoteRegisterFee`.
The above function sends a message to the AssetHub teyrchain to register a new fungible asset in the `ForeignAssets` pezpallet. To account for delivery costs, the above function charges a fee in Ether which may be retrieved beforehand by calling `quoteRegisterFee`.
For more information, see the link:https://docs.snowbridge.network[Snowbridge Docs]. For more information on the Snowbridge deployment to Polkadot, see the link:https://polkadot.polkassembly.io/referenda/680[governance proposal which initialized Snowbridge on BridgeHub and AssetHub].
For more information, see the link:https://docs.snowbridge.network[Snowbridge Docs]. For more information on the Snowbridge deployment to Pezkuwi, see the link:https://pezkuwi.polkassembly.io/referenda/680[governance proposal which initialized Snowbridge on BridgeHub and AssetHub].
=== HydraDX
HydraDX supports DeFi functionality to provide liquidity to Polkadot.
HydraDX supports DeFi functionality to provide liquidity to Pezkuwi.
The `Opening an HRMP Channel` section shows the general steps for opening two HRMP channels between any two parachains.
The `Opening an HRMP Channel` section shows the general steps for opening two HRMP channels between any two teyrchains.
To propose opening a channel to send XCM to HydraDX, the sending parachain may call:
To propose opening a channel to send XCM to HydraDX, the sending teyrchain may call:
```
hrmp.hrmpInitOpenChannel(
recipient = 2034,
@@ -96,14 +96,14 @@ hrmp.hrmpInitOpenChannel(
)
```
HydraDX may accept the channel open request from the sending parachain with paraID 43211234 by calling:
HydraDX may accept the channel open request from the sending teyrchain with paraID 43211234 by calling:
```
hrmpAcceptOpenChannel(
sender = 43211234
)
```
HydraDX may call the following to propose opening a channel to send XCM from HydraDX to the parachain with paraID 43211234:
HydraDX may call the following to propose opening a channel to send XCM from HydraDX to the teyrchain with paraID 43211234:
```
hrmp.hrmpInitOpenChannel(
recipient = 43211234,
@@ -112,14 +112,14 @@ hrmp.hrmpInitOpenChannel(
)
```
Assuming the HydraDX has paraID 2034, the receiving parachain may accept the channel open request by calling:
Assuming the HydraDX has paraID 2034, the receiving teyrchain may accept the channel open request by calling:
```
hrmpAcceptOpenChannel(
sender = 2034
)
```
Note that in order to dispatch a call from its sovereign origin, a parachain may use governance to send the encoded call in a Transact instruction to the Relay Chain, but it may also execute this logic autonomously (e.g. on the notification that a channel was requested). HRMP extrinsics often must be called from the parachain’s sovereign account as origin, often via a democracy proposal.
Note that in order to dispatch a call from its sovereign origin, a teyrchain may use governance to send the encoded call in a Transact instruction to the Relay Chain, but it may also execute this logic autonomously (e.g. on the notification that a channel was requested). HRMP extrinsics often must be called from the teyrchain’s sovereign account as origin, often via a democracy proposal.
link:https://moonbeam.polkassembly.network/referendum/93[Here] is an example of a proposal on Moonbeam to Open/Accept HRMP channels with HydraDX.
@@ -144,4 +144,4 @@ pub trait HandleHrmpChannelClosing {
fn handle(initiator: u32, sender: u32, recipient: u32) -> XcmResult;
}
```
The default implementation `()` returns `Ok(())` without executing any effects. Read more in the link:https://wiki.polkadot.network/docs/build-hrmp-channels[Polkadot documentation].
The default implementation `()` returns `Ok(())` without executing any effects. Read more in the link:https://wiki.pezkuwi.network/docs/build-hrmp-channels[Pezkuwi documentation].
docs/modules/ROOT/pages/guides/pay_dot_as_a_fee.adoc
+5 -5
View File
@@ -2,13 +2,13 @@
:highlightjs-languages: rust
:github-icon: pass:[<svg class="icon"><use href="#github-icon"/></svg>]
= Pay DOT as a Fee
= Pay HEZ as a Fee
This feature allows you to set DOT (or any other registered asset) as a fee for transaction execution. Here are the steps that you will need to execute to support it.
This feature allows you to set HEZ (or any other registered asset) as a fee for transaction execution. Here are the steps that you will need to execute to support it.
== Configuration
All you need to configure to start using this feature is an Oracle. You can use some service from any oracle service (like Chainlink, Pyth and others who support Substrate runtimes) or set up a development-mode solution.
All you need to configure to start using this feature is an Oracle. You can use some service from any oracle service (like Chainlink, Pyth and others who support Bizinikiwi runtimes) or set up a development-mode solution.
=== 1. Add Oracle Members
@@ -45,11 +45,11 @@ Here's how to submit oracle data using the CLI:
[source,bash]
----
# Submit price feed for DOT/USD
# Submit price feed for HEZ/USD
subxt tx --url "ws://localhost:9944" \
--suri "<oracle-member-key>" \
orml-oracle feed_values \
--values '[[1, "12000000000000000000"]]' # replace the CurrencyId with DOT's AssetId and the number with price of native DOT in native tokens
--values '[[1, "12000000000000000000"]]' # replace the CurrencyId with HEZ's AssetId and the number with price of native HEZ in native tokens
----
=== 4. Query Oracle Data
docs/modules/ROOT/pages/guides/pezpallet_abstractions.adoc
+27 -27
View File
@@ -2,11 +2,11 @@
:highlightjs-languages: rust
:github-icon: pass:[<svg class="icon"><use href="#github-icon"/></svg>]
= OpenZeppelin Pezpallet Abstractions
= OpenZeppelin Pezpezpallet Abstractions
=== Introduction
link:https://github.com/OpenZeppelin/openzeppelin-pezpallet-abstractions[openzeppelin-pezpallet-abstractions] is a Rust macro library designed to simplify and secure the configuration of Polkadot parachain runtimes. By reducing repetitive boilerplate and providing sensible defaults, the library helps developers configure their runtimes with fewer lines of code while ensuring flexibility for customizations.
link:https://github.com/OpenZeppelin/openzeppelin-pezpallet-abstractions[openzeppelin-pezpallet-abstractions] is a Rust macro library designed to simplify and secure the configuration of Pezkuwi teyrchain runtimes. By reducing repetitive boilerplate and providing sensible defaults, the library helps developers configure their runtimes with fewer lines of code while ensuring flexibility for customizations.
Note: This library has not been audited yet and should not be used in production environments.
@@ -39,7 +39,7 @@ impl SystemConfig for OpenZeppelinRuntime {
}
impl_openzeppelin_system!(OpenZeppelinRuntime);
```
This expands to configure multiple core pezpallets like `pezframe_system`, `pezpallet_timestamp`, `parachain_info`, and others essential for a functioning parachain runtime.
This expands to configure multiple core pezpallets like `pezframe_system`, `pezpallet_timestamp`, `teyrchain_info`, and others essential for a functioning teyrchain runtime.
===== 2. Additional configurations
@@ -74,7 +74,7 @@ impl_openzeppelin_evm!(OpenZeppelinRuntime);
===== 3. Advanced Configuration Options
Each macro allows optional parameters to override the default values. This enables fine-tuning of runtime settings according to the specific needs of your parachain while retaining the benefits of standardized, secure defaults.
Each macro allows optional parameters to override the default values. This enables fine-tuning of runtime settings according to the specific needs of your teyrchain while retaining the benefits of standardized, secure defaults.
Default Overrides: Customize specific parameters like `ExistentialDeposit`, `BaseXcmWeight`, or `AssetId` while relying on default values for other settings.
Custom Implementations: Integrate custom types (like `EitherOf`, `ConstU32`) or origins (`EnsureRoot`, `WhitelistedCaller`) for advanced use cases.
@@ -86,7 +86,7 @@ While the library is built with security in mind, it’s essential to review eac
===== 5. Contributing and Feedback
We encourage contributions from the community to improve the library. Please refer to the link:https://github.com/OpenZeppelin/openzeppelin-pezpallet-abstractions/blob/main/CONTRIBUTING.MD[CONTRIBUTING.md] for guidelines.
=== 3. Using Procedural Macros in OpenZeppelin Pezpallet Abstractions
=== 3. Using Procedural Macros in OpenZeppelin Pezpezpallet Abstractions
==== 1. `construct_runtime!` Macro
@@ -101,17 +101,17 @@ mod runtime {
#[abstraction]
struct System; // Available abstractions: System, Consensus, XCM, Assets, Governance, EVM.
#[pezpallet]
type Pezpallet = pezpallet_crate; // Regular pezpallets defined with `#[pezpallet]` mimic the `construct_runtime!` structure.
type Pezpezpallet = pezpallet_crate; // Regular pezpallets defined with `#[pezpallet]` mimic the `construct_runtime!` structure.
}
```
Note: Pezpallet index assignments are handled automatically by this macro. If you require explicit control over pezpallet indices, please consider submitting a link:https://github.com/OpenZeppelin/openzeppelin-pezpallet-abstractions/issues[feature request].
Note: Pezpezpallet index assignments are handled automatically by this macro. If you require explicit control over pezpallet indices, please consider submitting a link:https://github.com/OpenZeppelin/openzeppelin-pezpallet-abstractions/issues[feature request].
===== Supported Abstractions and their Pezpallets:
* System -- pezframe_system, pezpallet_timestamp, parachain_info, pezpallet_scheduler, pezpallet_preimage, pezpallet_proxy, pezpallet_balances, pezpallet_utility, cumulus_pezpallet_parachain_system, pezpallet_multisig, pezpallet_session
===== Supported Abstractions and their Pezpezpallets:
* System -- pezframe_system, pezpallet_timestamp, teyrchain_info, pezpallet_scheduler, pezpallet_preimage, pezpallet_proxy, pezpallet_balances, pezpallet_utility, pezcumulus_pezpallet_teyrchain_system, pezpallet_multisig, pezpallet_session
* Assets -- pezpallet_assets, pezpallet_transaction_payment, pezpallet_asset_manager
* Consensus -- pezpallet_authorship, pezpallet_aura, cumulus_pezpallet_aura_ext, pezpallet_collator_selection
* Consensus -- pezpallet_authorship, pezpallet_aura, pezcumulus_pezpallet_aura_ext, pezpallet_collator_selection
* Governance -- pezpallet_sudo, pezpallet_treasury, pezpallet_conviction_voting, pezpallet_whitelist, pezpallet_custom_origins, pezpallet_referenda
* XCM -- pezpallet_message_queue, cumulus_pezpallet_xcmp_queue, pezpallet_xcm, cumulus_pezpallet_xcm, pezpallet_xcm_transactor, orml_xtokens, pezpallet_xcm_weight_trader
* XCM -- pezpallet_message_queue, pezcumulus_pezpallet_xcmp_queue, pezpallet_xcm, pezcumulus_pezpallet_xcm, pezpallet_xcm_transactor, orml_xtokens, pezpallet_xcm_weight_trader
* EVM -- pezpallet_ethereum, pezpallet_evm, pezpallet_base_fee, pezpallet_evm_chain_id, pezpallet_erc20_xcm_bridge
==== 2. `impl_runtime_apis!` Macro
@@ -148,7 +148,7 @@ mod apis {
| * `fp_rpc::EthereumRuntimeRPCApi` +
* `fp_rpc::ConvertTransactionRuntimeApi`
| * `RuntimeCall` -- runtime call generated by `construct_runtime` macro +
* `Executive` -- `pezframe_executive::Executive` specification used by parachain system +
* `Executive` -- `pezframe_executive::Executive` specification used by teyrchain system +
* `Ethereum` -- `pezpallet_ethereum` pezpallet struct generated by `construct_runtime` macro
| assets
@@ -159,28 +159,28 @@ mod apis {
* `Balance` -- type used for balance specification (e.g., in `pezpallet_balances` config)
| consensus
| * `sp_consensus_aura::AuraApi` +
* `sp_session::SessionKeys` +
* `cumulus_primitives_aura::AuraUnincludedSegmentApi` (if `async-backing` feature is enabled)
| * `pezsp_consensus_aura::AuraApi` +
* `pezsp_session::SessionKeys` +
* `pezcumulus_primitives_aura::AuraUnincludedSegmentApi` (if `async-backing` feature is enabled)
| * `SessionKeys` -- struct generated by `impl_opaque_keys` macro +
* `Aura` -- `pezpallet_aura` struct pezpallet generated by `construct_runtime` macro (only if `async-backing` feature is not enabled) +
* `SlotDuration` -- constant used for slot duration definition (only if `async-backing` feature is enabled) +
* `ConsensusHook` -- type used in `cumulus_pezpallet_parachain_system::Config::ConsensusHook` (only if `async-backing` feature is enabled)
* `ConsensusHook` -- type used in `pezcumulus_pezpallet_teyrchain_system::Config::ConsensusHook` (only if `async-backing` feature is enabled)
| system
| * `sp_api::Core` +
* `sp_api::Metadata` +
* `sp_block_builder::BlockBuilder` +
* `sp_transaction_pool::runtime_api::TaggedTransactionQueue` +
* `sp_offchain::OffchainWorkerApi` +
| * `pezsp_api::Core` +
* `pezsp_api::Metadata` +
* `pezsp_block_builder::BlockBuilder` +
* `pezsp_transaction_pool::runtime_api::TaggedTransactionQueue` +
* `pezsp_offchain::OffchainWorkerApi` +
* `pezframe_system_rpc_runtime_api::AccountNonceApi` +
* `cumulus_primitives_core::CollectCollationInfo` +
* `pezcumulus_primitives_core::CollectCollationInfo` +
* `pezframe_try_runtime::TryRuntime` (under a `try-runtime` feature) +
* `sp_genesis_builder::GenesisBuilder`
| * `Executive` -- `pezframe_executive::Executive` specification used by parachain system +
* `pezsp_genesis_builder::GenesisBuilder`
| * `Executive` -- `pezframe_executive::Executive` specification used by teyrchain system +
* `System` -- `pezframe_system` pezpallet struct generated by `construct_runtime` macro +
* `ParachainSystem` -- `cumulus_pezpallet_parachain_system` pezpallet struct generated by `construct_runtime` macro +
* `RuntimeVersion` -- runtime version, generated by `sp_version::runtime_version` +
* `TeyrchainSystem` -- `pezcumulus_pezpallet_teyrchain_system` pezpallet struct generated by `construct_runtime` macro +
* `RuntimeVersion` -- runtime version, generated by `pezsp_version::runtime_version` +
* `AccountId` -- account id type specified in `pezframe_system::Config` +
* `Nonce` -- nonce type specified in `pezframe_system::Config` +
* `RuntimeGenesisConfig` -- type generated by `construct_runtime` macro +
@@ -194,7 +194,7 @@ mod apis {
* `RuntimeOrigin` -- type generated by `construct_runtime` macro +
* `RelayLocation` -- `Location` type pointing to the relaychain +
* `System` -- `pezframe_system` pezpallet struct generated by `construct_runtime` macro +
* `ParachainSystem` -- `cumulus_pezpallet_parachain_system` pezpallet struct generated by `construct_runtime` macro +
* `TeyrchainSystem` -- `pezcumulus_pezpallet_teyrchain_system` pezpallet struct generated by `construct_runtime` macro +
* `ExistentialDeposit` -- type describing existential deposit +
* `AssetId` -- type describing internal asset id +
* `XCMConfig` -- struct implementing `xcm_executor::Config`, generated by XCM abstraction as `XcmExecutorConfig` +
docs/modules/ROOT/pages/guides/predeployed_contracts.adoc
+1 -1
View File
@@ -39,7 +39,7 @@ You can take as an example a file in our EVM template in path `contracts/contrac
During the step when you generate a chainspec pass the parameter `--predeployed-contracts` with a path to the directory where you have stored the contract artifacts and the configuration:
```bash
./target/release/parachain-template-node build-spec --disable-default-bootnode --predeployed-contracts=<path_to_dir> > plain-parachain-chainspec.json
./target/release/teyrchain-template-node build-spec --disable-default-bootnode --predeployed-contracts=<path_to_dir> > plain-teyrchain-chainspec.json
```
== Exclude any contracts from genesis config
docs/modules/ROOT/pages/guides/quick_start.adoc
+22 -22
View File
@@ -4,9 +4,9 @@
= Quick start
* Begin by visiting our link:https://github.com/OpenZeppelin/polkadot-runtime-templates[repository]. You can fork it, or simply clone it to your local directory.
* Begin by visiting our link:https://github.com/OpenZeppelin/pezkuwi-runtime-templates[repository]. You can fork it, or simply clone it to your local directory.
```bash
git clone git@github.com:OpenZeppelin/polkadot-runtime-templates.git
git clone git@github.com:OpenZeppelin/pezkuwi-runtime-templates.git
```
* Move to the directory of the template you want to use. We will use the `generic runtime template` for this tutorial, but it is the same for the same applies to the xref:runtimes/evm.adoc[EVM Runtime Template].
@@ -19,15 +19,15 @@ cd generic-template
cargo build --release
```
* Receive some `PSO` from the link:https://paritytech.github.io/polkadot-testnet-faucet/[Paseo faucet]
* Receive some `PSO` from the link:https://pezkuwichain.github.io/pezkuwi-testnet-faucet/[Paseo faucet]
* Reserve a ParaId on Paseo:
** Go to link:https://polkadot.js.org/apps[PolkadotJS]. Check that it points to Paseo testnet.
** Go to `Network` > `Parachains`
** Go to link:https://pezkuwi.js.org/apps[PezkuwiJS]. Check that it points to Paseo testnet.
** Go to `Network` > `Teyrchains`
** Go to `Parathreads` tab
** Click the `+ ParaId` button
** Save the `parachain id` for the further usage.
** Save the `teyrchain id` for the further usage.
** Click `Submit` and `Sign and Submit`.
* Generate and customize a chainspec:
@@ -40,24 +40,24 @@ We use the `generic-template-node` executable throughout all the commands since
** Generate a plain chainspec with this command:
+
```bash
./target/release/generic-template-node build-spec --disable-default-bootnode > plain-parachain-chainspec.json
./target/release/generic-template-node build-spec --disable-default-bootnode > plain-teyrchain-chainspec.json
```
** Edit the chainspec:
*** Update `name`, `id` and `protocolId` to unique values.
*** Change `relay_chain` from `paseo-local` to `paseo`.
*** Change `para_id` and `parachainInfo.parachainId` from `1000` to the previously saved parachain id.
*** Change `para_id` and `teyrchainInfo.teyrchainId` from `1000` to the previously saved teyrchain id.
** Generate a raw chainspec with this command:
+
```bash
./target/release/generic-template-node build-spec --chain plain-parachain-chainspec.json --disable-default-bootnode --raw > raw-parachain-chainspec.json
./target/release/generic-template-node build-spec --chain plain-teyrchain-chainspec.json --disable-default-bootnode --raw > raw-teyrchain-chainspec.json
```
[NOTE]
====
At this point, you are free to use the omni-node. The command for using omni-node takes the form: `polkadot-omni-node --chain <chain_spec.json>`. For more information about using omni-node, see the link:https://docs.polkadot.com/develop/toolkit/parachains/polkadot-omni-node/[polkadot-omni-node documentation].
At this point, you are free to use the omni-node. The command for using omni-node takes the form: `pezkuwi-omni-node --chain <chain_spec.json>`. For more information about using omni-node, see the link:https://docs.pezkuwi.com/develop/toolkit/teyrchains/pezkuwi-omni-node/[pezkuwi-omni-node documentation].
====
* Run two nodes and wait until it syncs with the Paseo relay chain. This can take a fairly long time(up to 2 days), so we can use the `fast-unsafe` flag to make the process faster since we are on a testnet(~ 3 hours). `fast` downloads the blocks without executing the transactions, and `unsafe` skips downloading the state proofs(which we are ok with since it is a testnet).
@@ -67,7 +67,7 @@ At this point, you are free to use the omni-node. The command for using omni-nod
--alice \
--collator \
--force-authoring \
--chain raw-parachain-chainspec.json \
--chain raw-teyrchain-chainspec.json \
--base-path <path to datadir> \
--port 40333 \
--rpc-port 8844 \
@@ -84,7 +84,7 @@ At this point, you are free to use the omni-node. The command for using omni-nod
--bob \
--collator \
--force-authoring \
--chain raw-parachain-chainspec.json \
--chain raw-teyrchain-chainspec.json \
--base-path <path to datadir> \
--port 40333 \
--rpc-port 8845 \
@@ -96,34 +96,34 @@ At this point, you are free to use the omni-node. The command for using omni-nod
--sync fast-unsafe
```
** `<path to datadir>` is where the downloaded chain state will be stored. It can be any folder on your computer.
** `<path to the Paseo chainspec>` is where your Paseo chainspec is stored. You can download this file from the link:https://github.com/paritytech/polkadot-sdk/blob/release-polkadot-v1.10.0/polkadot/node/service/chain-specs/paseo.json[official Polkadot sdk repository].
** `<path to the Paseo chainspec>` is where your Paseo chainspec is stored. You can download this file from the link:https://github.com/pezkuwichain/pezkuwi-sdk/blob/release-pezkuwi-v1.10.0/pezkuwi/node/service/chain-specs/paseo.json[official Pezkuwi sdk repository].
* Register a parathread:
** Generate a genesis state:
+
```bash
./target/release/generic-template-node export-genesis-state --chain raw-parachain-chainspec.json para-<paraId>-genesis-state
./target/release/generic-template-node export-genesis-state --chain raw-teyrchain-chainspec.json para-<paraId>-genesis-state
```
** Generate a genesis wasm:
+
```bash
./target/release/generic-template-node export-genesis-wasm --chain raw-parachain-chainspec.json para-<paraId>-wasm
./target/release/generic-template-node export-genesis-wasm --chain raw-teyrchain-chainspec.json para-<paraId>-wasm
```
** Go to link:https://polkadot.js.org/apps[PolkadotJS]. Check that it points to Paseo testnet.
** Go to `Network` > `Parachains`.
** Go to link:https://pezkuwi.js.org/apps[PezkuwiJS]. Check that it points to Paseo testnet.
** Go to `Network` > `Teyrchains`.
** Go to `Parathreads` tab.
** Click the `+ ParaThread` button.
** Insert `para-<paraId>-wasm` to `code` field.
** Insert `para-<paraId>-genesis-state` to `initial state` field.
** Click `Submit` and `Sign and Submit`.
* When a parachain gets synced with a relaychain, you may start producing blocks as a parathread:
** Create some transaction with a PolkadotJS pointing to your parachain setup.
** With a PolkadotJS pointing to Paseo go to `Developer` > `Extrinsics`.
* When a teyrchain gets synced with a relaychain, you may start producing blocks as a parathread:
** Create some transaction with a PezkuwiJS pointing to your teyrchain setup.
** With a PezkuwiJS pointing to Paseo go to `Developer` > `Extrinsics`.
** Submit an extrinsic `onDemandAssignmentProvider.placeOrderAllowDeath` or `onDemandAssignmentProvider.placeOrderKeepAlive`:
*** `maxAmount` should be not less than 10_000_000 and it is amount of 0.00001 PAS. It is an amount of PAS paid for the block.
*** `paraId` should be set to your parachain id.
*** `paraId` should be set to your teyrchain id.
*** Click `Submit` and `Sign and Submit`.
** In some time your parathread will produce a block and in one of the next blocks of Paseo there will be an inclusion of this block
@@ -132,4 +132,4 @@ At this point, you are free to use the omni-node. The command for using omni-nod
- Read our general guides to understand more about the concepts of runtime development.
- Learn more about the runtime configuration. Currently, we have two runtime templates: xref:runtimes/generic.adoc[Generic Runtime Template] and xref:runtimes/evm.adoc[EVM Runtime Template].
- Explore the documentation for pezpallets. It may be useful if you are considering building a frontend for your parachain.
- Explore the documentation for pezpallets. It may be useful if you are considering building a frontend for your teyrchain.
docs/modules/ROOT/pages/guides/rpc_differences.adoc
+1 -1
View File
@@ -4,7 +4,7 @@
= RPC Differences
The EVM in a Substrate node has almost the same RPC calls common to all nodes. But some of them are not applicable for Frontier.
The EVM in a Bizinikiwi node has almost the same RPC calls common to all nodes. But some of them are not applicable for Frontier.
These are the calls that behave differently than would be expected by regular Ethereum nodes:
docs/modules/ROOT/pages/guides/testing_with_zombienet.adoc
+22 -22
View File
@@ -4,16 +4,16 @@
= Testing Solidity Smart Contracts with Zombienet
In this tutorial, we will demonstrate how to deploy your parachain using Zombienet, and test the functionalities of your parachain.
In this tutorial, we will demonstrate how to deploy your teyrchain using Zombienet, and test the functionalities of your teyrchain.
Below are the main steps of this demo:
. Deploy our parachain against the locally simulated Paseo testnet by Zombienet.
. Deploy a Solidity smart contract on our parachain.
. Successfully invoke the Solidity smart contract deployed on our parachain.
. Deploy our teyrchain against the locally simulated Paseo testnet by Zombienet.
. Deploy a Solidity smart contract on our teyrchain.
. Successfully invoke the Solidity smart contract deployed on our teyrchain.
== Step 1: Deploy The Parachain
== Step 1: Deploy The Teyrchain
. git clone https://github.com/OpenZeppelin/polkadot-runtime-templates
. git clone https://github.com/OpenZeppelin/pezkuwi-runtime-templates
. move to evm template directory
+
@@ -26,7 +26,7 @@ cd evm-template
```rust
[relaychain]
chain = "paseo-local"
default_command = "./bin-v1.6.0/polkadot"
default_command = "./bin-v1.6.0/pezkuwi"
[[relaychain.nodes]]
name = "alice"
@@ -61,7 +61,7 @@ error[E0635]: unknown feature `stdsimd`
33 | #![cfg_attr(feature = "stdsimd", feature(stdsimd))]
```
`Cd` into the `polkadot-sdk` directory (the path should be visible on the error message), and run the below command to update `ahash`:
`Cd` into the `pezkuwi-sdk` directory (the path should be visible on the error message), and run the below command to update `ahash`:
```bash
cargo update -p ahash@0.7.6
@@ -95,53 +95,53 @@ cargo build --release --features="async-backing"
+
image::alice-direct-link.png[Alice Direct Link]
. Open the link with Chrome: link:https://polkadot.js.org/apps[PolkadotJS]. As of 2024 July, it doesn’t work on Safari and Brave, and it is buggy on Firefox.
. Open the link with Chrome: link:https://pezkuwi.js.org/apps[PezkuwiJS]. As of 2024 July, it doesn’t work on Safari and Brave, and it is buggy on Firefox.
. Reserve a `ParaId` on Zombienet:
.. Go to `Network` > `Parachains`
.. Go to `Network` > `Teyrchains`
.. Go to `Parathreads` tab
.. Click the `+ ParaId` button
.. Save a `parachain id` for the further usage.
.. Save a `teyrchain id` for the further usage.
.. Click `Submit` and `Sign and Submit` (you can use `Alice` as the account).
. Preparing necessary files to become a Parachain:
. Preparing necessary files to become a Teyrchain:
.. Generate a plain chainspec:
+
```bash
./target/release/evm-template-node build-spec --disable-default-bootnode > plain-parachain-chainspec.json
./target/release/evm-template-node build-spec --disable-default-bootnode > plain-teyrchain-chainspec.json
```
.. Edit the chainspec:
... Update `name`, `id` and `protocolId` to unique values (optional).
... Change `para_id` and `parachainInfo.parachainId` from `1000` to the previously saved parachain id (probably 2000 if that’s your first time ;) ).
... Change `para_id` and `teyrchainInfo.teyrchainId` from `1000` to the previously saved teyrchain id (probably 2000 if that’s your first time ;) ).
... Edit the `evmChainId.chainId` to the value of your choice. Try to select a value that has no existing EVM chain assigned to it (should be ok to leave as is for the most cases).
.. Generate a raw chainspec:
+
```bash
./target/release/evm-template-node build-spec --chain plain-parachain-chainspec.json --disable-default-bootnode --raw > raw-parachain-chainspec.json
./target/release/evm-template-node build-spec --chain plain-teyrchain-chainspec.json --disable-default-bootnode --raw > raw-teyrchain-chainspec.json
```
.. Generate the genesis state:
+
```bash
./target/release/evm-template-node export-genesis-state --chain raw-parachain-chainspec.json > genesis-state
./target/release/evm-template-node export-genesis-state --chain raw-teyrchain-chainspec.json > genesis-state
```
.. Generate the validation code:
+
```bash
./target/release/evm-template-node export-genesis-wasm --chain raw-parachain-chainspec.json > genesis-wasm
./target/release/evm-template-node export-genesis-wasm --chain raw-teyrchain-chainspec.json > genesis-wasm
```
. Registering the Parachain:
.. Go back to `polkadot.js.org/apps` (remember Chrome). Go to `Developer/Sudo`.
. Registering the Teyrchain:
.. Go back to `pezkuwi.js.org/apps` (remember Chrome). Go to `Developer/Sudo`.
.. select `pasasSudoWrapper` and `sudoScheduleParaInitialize(id, genesis)`
.. enter the reserved id (2000) to `id` field
.. enable `file upload` for both `genesisHead` and `validationCode` → because we will upload files for these.
.. select `Yes` for `paraKind` → meaning when we register our parachain, it will be a parachain rather than a parathread.
.. select `Yes` for `paraKind` → meaning when we register our teyrchain, it will be a teyrchain rather than a parathread.
.. drag&drop your `genesis-state` file generated in step `10.d` into `genesisHead` field (good luck with the aiming)
.. drag&drop your `genesis-wasm` file generated in `10.e` into `validationCode` field
.. It should look like below:
+
image::register-parachain.png[Register Parachain]
image::register-teyrchain.png[Register Teyrchain]
.. `Submit Sudo`!
. copy the path to `chain-spec` from zombienet terminal from `Bob` (beware, this file is changing every time you spin up a new zombienet):
@@ -156,7 +156,7 @@ image::zombie-chain-spec.png[Zombie Chain Spec]
--alice \
--collator \
--force-authoring \
--chain raw-parachain-chainspec.json \
--chain raw-teyrchain-chainspec.json \
--base-path storage/alice \
--port 40333 \
--rpc-port 8844 \
docs/modules/ROOT/pages/guides/weights_fees.adoc
+7 -7
View File
@@ -6,11 +6,11 @@
Weight is a metric to estimate the time it takes to execute code.
In Substrate, every transaction has a weight. The block production algorithm selects the set of transactions from the transaction pool that achieve block saturation without exceeding `MaximumBlockWeight`. The `AvailableBlockRatio` ensures only a fraction of `MaximumBlockWeight` is used for regular transactions while system-critical operations (operational transactions) may use all remaining block weight.
In Bizinikiwi, every transaction has a weight. The block production algorithm selects the set of transactions from the transaction pool that achieve block saturation without exceeding `MaximumBlockWeight`. The `AvailableBlockRatio` ensures only a fraction of `MaximumBlockWeight` is used for regular transactions while system-critical operations (operational transactions) may use all remaining block weight.
Substrate charges every transaction's caller with fees in proportion to the cost of execution. It does so by converting each transaction's weight to fees via `WeightToFee`.
Bizinikiwi charges every transaction's caller with fees in proportion to the cost of execution. It does so by converting each transaction's weight to fees via `WeightToFee`.
Weights which underestimate cost of execution expose a DDOS vulnerability. If a transaction takes up less space than it should, too many transactions may be included in the block and the block's execution time may exceed expected block time. For parachains, this DDOS vulnerability can be critical; it may prevent future block production by bricking the chain until the parachain state is reset on the relay chain.
Weights which underestimate cost of execution expose a DDOS vulnerability. If a transaction takes up less space than it should, too many transactions may be included in the block and the block's execution time may exceed expected block time. For teyrchains, this DDOS vulnerability can be critical; it may prevent future block production by bricking the chain until the teyrchain state is reset on the relay chain.
It is imperative for runtime developers to be conservative when approximating weight. Moreover, runtime complexity that is non-linear must be limited and bounded.
@@ -31,7 +31,7 @@ cargo build --features runtime-benchmarks
cargo build --release --features=runtime-benchmarks
# Collect all pezpallets needed for benchmarking
# Makes the assumption all pezpallets are present at: /pezpallets/$PALLET_NAME
# Makes the assumption all pezpallets are present at: /pezpallets/$PEZPALLET_NAME
pezpallets=$(ls pezpallets/)
# Generate weights
@@ -45,7 +45,7 @@ for pezpallet_name in $pezpallets; do
done
```
[start=3]
. Automate the benchmarking pipeline. The first step may be automated by enforcing the command in the CI. The second step may be automated by integrating a benchmarking github bot. For an example, see https://github.com/paritytech/command-bot[Parity's Command Bot].
. Automate the benchmarking pipeline. The first step may be automated by enforcing the command in the CI. The second step may be automated by integrating a benchmarking github bot. For an example, see https://github.com/pezkuwichain/command-bot[Parity's Command Bot].
== More Reading
@@ -55,8 +55,8 @@ Technically, *Weight* represents the time it takes to execute code on *productio
1 unit of weight = 1 picosecond of execution time on target reference hardware
```
It is important to ONLY generate weights on *production hardware*. https://wiki.polkadot.network/docs/maintain-guides-how-to-validate-polkadot#:~:text=Reference%20Hardware%E2%80%8B,instance%20on%20GCP%20and%20c6i[Polkadot Reference Hardware Docs] provides more information on Polkadot validator hardware requirements.
It is important to ONLY generate weights on *production hardware*. https://wiki.pezkuwi.network/docs/maintain-guides-how-to-validate-pezkuwi#:~:text=Reference%20Hardware%E2%80%8B,instance%20on%20GCP%20and%20c6i[Pezkuwi Reference Hardware Docs] provides more information on Pezkuwi validator hardware requirements.
=== References
https://www.shawntabrizi.com/blog/substrate/substrate-weight-and-fees/[Substrate Weight & Fees] by https://github.com/shawntabrizi/[Shawn Tabrizi]
https://www.shawntabrizi.com/blog/bizinikiwi/bizinikiwi-weight-and-fees/[Bizinikiwi Weight & Fees] by https://github.com/shawntabrizi/[Shawn Tabrizi]