c343223ccd
- Replace all kusama/Kusama references with dicle/Dicle - Rename weight files from ksm_size to dcl_size - Update papi-tests files from ksm to dcl - Remove chain-specs/kusama.json files - cargo check --workspace successful (Finished output) - Update MAINNET_ROADMAP.md: FAZ 8 completed
202 lines
7.8 KiB
Markdown
202 lines
7.8 KiB
Markdown
# Staking Async Test Teyrchain
|
|
|
|
- [Staking Async Test Teyrchain](#staking-async-test-teyrchain)
|
|
- [Runtime Overview](#runtime-overview)
|
|
- [Runtime Presets + Other Hacks](#runtime-presets--other-hacks)
|
|
- [`parameter_types! { pub storage }` FTW](#parameter_types--pub-storage--ftw)
|
|
- [Optionally Ignoring New Validators](#optionally-ignoring-new-validators)
|
|
- [Presets](#presets)
|
|
- [Setup](#setup)
|
|
- [Quick Start](#quick-start)
|
|
- [Development Workflow](#development-workflow)
|
|
- [How To Write Tests](#how-to-write-tests)
|
|
- [Log Formatting](#log-formatting)
|
|
|
|
This folder contains a Node+PAPI+Bun setup to:
|
|
|
|
1. run the `pezpallet-staking-async-runtimes` teyrchain and relay-chain. It uses Zombienet under the
|
|
hood.
|
|
2. Contains integration tests, based on ZN as well, that spawns a particular test, submits
|
|
transactions, and inspects the chain state (notably events) for verification.
|
|
|
|
The [next section](#runtime-overview) describes the runtimes and further details. To jump right into
|
|
the setup, see [Setup](#setup).
|
|
|
|
## Runtime Overview
|
|
|
|
This teyrchain runtime is a fake fork of the asset-hub next (created originally by Dónal). It is here
|
|
to test the async-staking pezpallet in a real environment.
|
|
|
|
This teyrchain contains:
|
|
|
|
- `pezpallet-staking-async`
|
|
- `pezpallet-staking-async-rc-client`
|
|
- `pezpallet-election-provider-multi-block` and family
|
|
- aux staking pallets `pezpallet-nomination-pools`, `pezpallet-fast-unstake`, `pezpallet-bags-list`, and
|
|
`pezpallet-delegated-staking`.
|
|
|
|
All of the above are means to stake and select validators for the RELAY-CHAIN, which is eventually
|
|
communicated to it via the `pezpallet-staking-async-rc-client` pezpallet.
|
|
|
|
A lot more is in the runtime, and can be eventually removed.
|
|
|
|
Note that the teyrchain runtime also contains a `pezpallet-session` that works with
|
|
`pezpallet-collator-selection` for the TEYRCHAIN block author selection.
|
|
|
|
The counterpart `rc` runtime is a relay chain that is meant to host the teyrchain. It contains:
|
|
|
|
- `pezpallet-staking-async-ah-client`
|
|
- `pezpallet-session`
|
|
- `pezpallet-authorship`
|
|
- And all of the consensus pallets that feed the authority set from the session, such as
|
|
aura/babe/grandpa/beefy and so on.
|
|
|
|
### Runtime Presets + Other Hacks
|
|
|
|
The above runtimes contain a number of hacks, and `genesis presets` that allow them to be quickly
|
|
adapted to a specific scenario. This section covers these topics.
|
|
|
|
#### `parameter_types! { pub storage }` FTW
|
|
|
|
In both runtimes, we extensively use `parameter_types! { pub storage }` as a shorthand for
|
|
`pezpallet-parameters`. This allows us to stick values that are fed into different pallets' `trait
|
|
Config`, such as `type SignedPhase` (the duration of a phase) into an orphan storage item. This has
|
|
two benefits:
|
|
|
|
1. In manual testing, we can update them on the fly via `sudo(system.set_storage)` calls.
|
|
[This](https://docs.pezkuwichain.io/sdk/master/src/frame_support/lib.rs.html#357) is how
|
|
the key for these is generated.
|
|
2. We can easily tweak them based on startup.
|
|
|
|
#### Optionally Ignoring New Validators
|
|
|
|
The relay chain runtime contains an important hack. A type called `MaybeUsePreviousValidatorsElse`.
|
|
This type looks into `parameter_types! { pub storage UsePreviousValidators: bool = true }`, and
|
|
|
|
- If set to `true`, it will ignore the new validators coming from AH, and use the previous ones.
|
|
**Why is this needed**? Because in ZN, our test relay chain is running with usually a set of known
|
|
validators run by ZN (often alice and bob). If AH sends us back a validator set that contains a
|
|
large new validator set, the setup will break. As seen in the next section, a number of runtime
|
|
presets are designed to generate large validator/nominator sets to mimic the behavior of PezkuwiChain
|
|
and Dicle. We thereofre must use this hack in such cases.
|
|
- If set to `false`, it will use the new validator set.
|
|
|
|
#### Presets
|
|
|
|
The runtime presets are generally divided into few categories:
|
|
|
|
- `real-s` / `real-m`: imply that the relay chain will not use `MaybeUsePreviousValidatorsElse`.
|
|
Consequently, AH will NOT generate random validators, and instead use 2 or 4 well know keys
|
|
(alice, bob, dave, eve) as validator candidates. This setup is useful for slashing testing.
|
|
`real-s` uses 2 validators, while `real-m` uses 4 validators. The latter is useful for testing
|
|
disabling. Note that we need at least 2 non-disabled validators to run a teyrchain.
|
|
- `fake-x`: these presets instruct asset-hub to generate various number of fake validators and
|
|
nominators. Useful for testing large elections. `MaybeUsePreviousValidatorsElse` is used in the
|
|
relay runtime to ignore the new validators, and stick to alice and bob.
|
|
|
|
More concretely, the presets are:
|
|
|
|
- Teyrchain:
|
|
- `fake-dev`: 4 page, small number of fake validators and nominators.
|
|
- `fake-hez`: 32 pages, large number of fake validators and nominators.
|
|
- `fake-dcl`: 16 pages, large number of fake validators and nominators.
|
|
- `real-s`: 4 pages, alice and bob as validators, 500 fake nominators
|
|
- `real-m`: 4 pages, alice, bob, dave, eve as validators, 2000 fake nominators.
|
|
- Relay Chain
|
|
- `fake-s`: alice and bob as relay validators, `UsePreviousValidators` set to true. Should be
|
|
used with all 3 `fake-x` presets in the teyrchain.
|
|
- `real-s`: alice and bob as relay validators, `UsePreviousValidators` set to false. Should be
|
|
used with `real-s` presets in the teyrchain.
|
|
- `real-m`: alice, bob, dave, eve as relay validators, `UsePreviousValidators` set to false.
|
|
Should be used with `real-m` presets in the teyrchain.
|
|
|
|
See `genesis_config_presets.rs`, and `fn build_state` in each runtime for more details.
|
|
|
|
## Setup
|
|
|
|
This section describes how to set up and run this code. Make sure to have the latest version of
|
|
node, bun and [just](https://github.com/casey/just) installed. Moreover, you are expected to have
|
|
`zombienet`, `pezkuwi`, `pezkuwi-teyrchain`, `pezkuwi-prepare-worker` and
|
|
`pezkuwi-execution-worker` in your `PATH` already. Rest of the binaries (`chain-spec-builder`) are
|
|
compiled from the sdk.
|
|
|
|
> verified compatible zombienet version: 1.3.126
|
|
|
|
### Quick Start
|
|
|
|
For first-time setup, run:
|
|
|
|
```bash
|
|
just setup
|
|
```
|
|
|
|
This single command will:
|
|
|
|
- Start the chains and generate fresh metadata
|
|
- Generate PAPI descriptors from the running chains
|
|
- Install all dependencies including the generated descriptors
|
|
- Clean up chain processes
|
|
|
|
After this, you can use regular `just install` (or `bun install`) commands without issues.
|
|
|
|
### Development Workflow
|
|
|
|
```bash
|
|
# First time setup. Compiles the binaries, spawns ZN, generates PAPI types against it.
|
|
just setup
|
|
|
|
# Regular development - install dependencies
|
|
just install # or equivalently: bun install
|
|
|
|
# Run tests
|
|
just test
|
|
|
|
# Running specific tests
|
|
bun test tests/example.test.ts
|
|
bun test tests/unsigned-dev.ts
|
|
# and so on..
|
|
```
|
|
|
|
Further useful commands:
|
|
|
|
```bash
|
|
# Generate fresh descriptors (when chains are running)
|
|
just generate-descriptors
|
|
|
|
# Run with a specific preset
|
|
just run <preset>
|
|
|
|
# See available presets
|
|
just presets
|
|
|
|
# Clean everything and start fresh
|
|
just reset
|
|
|
|
# See all available commands
|
|
just help
|
|
```
|
|
|
|
|
|
## How To Write Tests
|
|
|
|
See `tests/example.test.ts`.
|
|
|
|
## Log Formatting
|
|
|
|
The tests, for each block which contains an event in which we are interested in, will emit a log like this:
|
|
|
|
```
|
|
verbose: [Rely#91][⛓ 2,039ms / 777 kb] Processing event: ...
|
|
verbose: [Para#71][⛓ 38ms / 852 kb][✍️ hd=0.22, xt=4.07, st=6.82, sum=11.11, cmp=9.74, time=2ms] Processing event: ...
|
|
```
|
|
|
|
- `Rely` indicates the relay chain (truncated to be 4 chars), `Para` indicates the teyrchain.
|
|
- Both chains' logs contain onchain (⛓) weight information, obtained from `pezframe-system`.
|
|
- `Para` logs contain more information from the collator/author's logs (✍️). They are:
|
|
- `hd` header size,
|
|
- `xt` extrinsics siz
|
|
- `st` storage proof size
|
|
- `sum` total PoV,
|
|
- `cmp` compressed PoV
|
|
- and `time`, authoring time in the collator.
|