Validator Update: Battle Testing the Kate Testnet

Our Kate Testnet has been active and running for the last two months. So far, 75 validators have onboarded the testnet and we have increased the cap of our external validators to 100 this past week. During this time we have onboarded validators, monitored the network and tested a few scenarios on the network. Now, we will be battle testing the network with a robust set of objectives with a wider active set.

This blog post outlines all the objectives that we will test on the current Kate Testnet as well the future incentivized testnet as well. We plan to test all the scenarios to strengthen our code and create a mainnet ready approach.

Most of these objectives will require complete participation from all the validators. Some of these will be orchestrated internally by running scripts and observing the status of the network.

The following is a list of objectives and scenarios that we will be conducting on the Kate Testnet:

Upgrades

Run Time Upgrades: A proposal-based upgrade process without validator intervention.
Binary Upgrades: Validators update their nodes with bug fixes and improvements. A deadline may be set for urgency.
Hard Forks: Similar to binary upgrades but more time-intensive. Validators must upgrade by a deadline.

Transactions

Balance Transfers: Validators and ecosystem transfer tokens to test balance transfer function.
App ID Generation: Internal activity to test App ID generation in rollup integration and verify on the network.
Data Submissions: Test data submission with and without APP IDs in rollup integration.

Staking

Staking Rewards: Introduce a staking module for validators to earn rewards.
Staking Pool: Validators create pools to attract Nominators. Validators delegate to each other.
Staking Threshold: Increase staking threshold to test network behavior.

Slashing

Slashing due to Liveness: Request validators to shut down nodes to test network and slashing effects.
Slashing due to Double Signing: Internal activity to understand and test double sign effects.
Chilling: Getting validators in the chilling zone to test if everything works as intended

API

Node RPC & Data Availability: Validators create and make public RPC endpoints for data fetching.

Light Clients

Deploy Light Clients: Validators run light clients to verify and propagate data.

Bridge

Attestations: Internal activity to test attestations process.
Data Posted: Internal activity to test data posting.

Governance

Proposal Submission: Validators create and vote on proposals.
Soft Upgrades: Validators test runtime upgrades.
Kicking: Validators test kicking function.

Economy

Transaction Fee Dynamics: Simulate transactions to study fee dynamics.
Burn Rate & Treasury: Monitor burn rate and treasury while simulating transactions.
Rewards: Test Validator and Nominator rewards with internal and external validators.

Stress Testing

Offline Nodes: Simulate offline nodes to understand network effects.
Nominator Pool & Counts: Test nominator counts and pools.

Blockspace

Max Out Node RPC API: Test maximum capacity of Node RPC API.
Max Out Light Clients API: Test maximum capacity of Light Clients API.
System Transactions: Test system transactions in a controlled manner.

Recovery & Disaster Management

Bootnodes: Turn off bootnodes to assess network impact. Monitor through dashboard/explorer.

The plan involves various Proof of Concept (POC) teams responsible for different aspects of testing, including upgrades, transactions, staking, slashing, API, light clients, bridge, governance, economy, stress testing, blockspace, and recovery/disaster management. Each testing activity aims to observe, monitor, and validate the behavior and performance of the blockchain network on the Kate Testnet.

Conducting thorough scenario testing is a pivotal phase in our preparation towards the mainnet launch. During the testing of these scenarios, if the network breaks down or is halted, we will try to recover it through all means possible. In the unlikely event that the chain cannot be recovered, we will spin up a new chain and request validators to reconfigure the new chain spec.