Local QA Environment

Comprehensive Guide to the Local QA Environment

To ensure the stability and quality of the Toto Chain, a comprehensive Quality Assurance (QA) environment is available. This environment allows developers and testers to run a complete, local instance of the Toto Chain network, including multiple validator nodes, monitoring tools, and user-friendly front-ends, all orchestrated with Docker.

This document provides a detailed guide to setting up, running, and interacting with all the components of this local QA environment.

1. Overview: What's Included?

The local QA environment is managed through the discovery-qa repository, which uses Docker Compose to simplify the setup process. When you run it, it launches a full suite of services:

  • An 11-Node Validator Network: It starts eleven separate validator nodes, each named after a standard development account (Alice, Bob, Charlie, Dave, etc.), simulating a robust decentralized network.

  • Polkadot-JS Apps UI: The primary web interface for interacting with the chain.

  • Contracts UI: A specialized web interface for deploying and interacting with Wasm smart contracts.

  • Substrate Telemetry: A service to collect and display live telemetry data from all running nodes.

  • Prometheus: A monitoring service that scrapes and stores time-series data (metrics) from the validator nodes.

  • Grafana: A visualization dashboard that connects to Prometheus, providing graphs and charts to monitor the health and performance of the network.

2. Pre-configured Accounts

The local network is launched with a set of pre-funded accounts, ready for testing.

  • Development Accounts: The standard Alice, Bob, Charlie, Dave, Eve, and Ferdie accounts are included. These are the initial members of the Technical Committee. Their secret keys (mnemonic phrases) are located in the testkeys file in the root of the main repository.

  • Testnet Accounts: 11 specific testnet accounts are also funded: init00, init01, init02, init03, init04, init05, init06, init07, init08, init09, and init10.

  • Ethereum Accounts: Pre-funded Ethereum-style accounts are also available for testing EVM compatibility, including Alice and init00.

3. Connecting a Wallet (Talisman)

To sign transactions and fully interact with the chain, you'll need to connect a wallet. Talisman is a popular choice in the Polkadot ecosystem.

Step 3.1: Add the Local Network to Talisman

By default, Talisman doesn't know about your local private network, so you need to add it manually.

  1. Open the Talisman browser extension.

  2. Click on the network selector at the top (it might say "Polkadot" or another network name).

  3. At the bottom of the network list, click "Add a new network".

  4. Fill in the details for your local node:

    • Network Name: Toto Local Dev (or any name you prefer).

    • RPC URL: ws://127.0.0.1:9944

  5. Click "Add Network". Talisman will now be connected to your local chain.

Step 3.2: Import a Pre-funded Account

Now that Talisman is connected, you need to import one of the pre-funded development accounts to be able to sign transactions.

  1. In Talisman, click the account menu (three dots) and select "Add Account".

  2. Choose the option to "Import from seed phrase".

  3. Open the testkeys file from the root of the Toto Chain repository in a text editor.

  4. Copy the entire mnemonic phrase for the account you want to import (e.g., Alice: bottom drive obey lake curtain smoke basket hold race lonely fit walk...).

  5. Paste the seed phrase into Talisman and follow the prompts to name the account and set a password.

You now have a funded account connected to your local network, ready to interact with the Polkadot-JS UI, vote on proposals, and test extrinsics.

4. Setup and Execution

Step 4.1: Clone and Build

If you haven't already, clone the main Toto Chain repository and compile the node client.

# 1. Clone the repository
git clone git@gitlab.com:PBSA/Peerplays_2.0/discovery.git
cd discovery

# 2. Build the node (from the root of the 'discovery' repository)
cargo build --release

Testing Cycles with Fast Forward Mode

The Toto Chain includes time-based economic cycles, such as the 28-day decay of POTENTIAL and the liquidity halving of the Reward Pool. Waiting for these cycles to elapse in real-time is impractical for testing. To solve this, you can run the chain in a "Fast Forward" mode.

This mode dramatically accelerates the chain's perception of time, allowing you to observe and test long-term economic events in a matter of minutes or hours.

How to Run in Fast Forward Mode

Instead of running the standard cargo build --release, you need to compile the node with a special feature flag. You have two options:

Option A: Preset Fast Execution This mode uses pre-configured, accelerated time settings.

  1. Build with the fast_execution flag:

    # From the root of the 'discovery' repository
cargo build --release --features "peerplays-runtime/fast_execution"

Option B: Custom Execution Speed This mode allows you to define your own time parameters using environment variables. This gives you precise control for specific testing scenarios.

  1. Set your custom time variables:

    # Example: Make a block every second, an epoch every minute, etc.
export PEERPLAYS_MILLISECS_PER_BLOCK=1000
export PEERPLAYS_EPOCH_DURATION_IN_BLOCKS=60
export PEERPLAYS_SECONDS_IN_DAY=120
export PEERPLAYS_DAYS_IN_MONTH=10
export PEERPLAYS_MONTHS_IN_CYCLE=3

  2. Build with the custom_execution flag:

    # From the root of the 'discovery' repository
cargo build --release --features "peerplays-runtime/custom_execution"

Step 4.2: Start the Environment

Navigate to the discovery-qa directory and use docker-compose to start all services.

# 1. Navigate to the QA directory
cd discovery-qa

# 2. Start the environment
docker-compose up

This will start all 11 validator nodes and the associated services in your terminal. You will see a stream of logs from all containers. For the network to begin finalizing blocks, at least 8 nodes need to be running and communicating successfully.

5. Interacting with the Services

  • Polkadot-JS UI:

    • URL: http://localhost:3000

    • Purpose: Your main portal for interacting with the chain. It should automatically connect to your local network.

  • Substrate Telemetry:

    • URL: http://localhost:8080

    • Purpose: The frontend presentation of a backend ingestion server for Substrate Telemetry.

  • Contracts UI:

    • URL: http://localhost:8081

    • Purpose: For deploying and testing Wasm smart contracts.

  • Prometheus:

    • URL: http://localhost:9090

    • Purpose: To query the raw metrics collected from the nodes.

  • Grafana:

    • URL: http://localhost:9999

    • Purpose: To visualize the health and performance of your 11-node network. Login with default credentials (admin / admin).

6. Advanced Usage: Running a Custom Node Image

The QA environment is designed to let you test unpublished changes. To do this, you must first publish a custom Docker image from your feature branch to the project's GitLab container registry.

  1. Publish the Image: In your Merge Request pipeline on GitLab, manually run the dockerize job.

  2. Modify the Dockerfile: In the discovery-qa directory, open the Dockerfile and change the FROM line to point to your custom image:

    # FROM registry.gitlab.com/pbsa/peerplays_2.0/discovery:master
FROM registry.gitlab.com/pbsa/peerplays_2.0/discovery/<your-branch-name>:<commit_SHA>

  3. Rebuild the Images: Rebuild the local containers using your new base image.

    docker-compose build --no-cache

  4. Run the Environment: Start the environment as usual with docker-compose up.

7. Stopping the Environment

When you are finished, shut down the entire environment with a single command:

# From the 'discovery-qa' directory
docker-compose down

# Or simply Ctrl + C from the running command line
^C
PreviousRunning a NodeNextConnecting Your Wallet to the Toto Chain

Last updated