Concept
The KIRA network encourages consensus nodes uptime (i.e maintain an active status) by implementing a ranking system that fosters a dynamic and competitive environment to collectively promote network robustness and high participation levels. KIRA network utilizes the Tendermint consensus protocol, which ensures liveness by requiring a minimum of 2/3 + 1 of the consensus node set's total voting power to sign a block. While KIRA doesn't employ weighted voting and considers each node as having a single vote, the principle remains that it is not guaranteed for every node to sign every block as up to 1/3 of nodes can miss a block at any given time. This can be due to various factors, such as the random distribution of nodes around the world, limited networking connectivity between them, and the limited time that nodes have to wait for consensus votes. Accordingly, KIRA network's ranking system is designed to adapt to these variables. The system's parameters are fine-tuned by KIRA network governance to align individual node performance with the broader network health. This approach ensures high levels of participation while upholding the robustness of the network.
Ranking system
The rank value is a measure of a node's performance and is used to inform the governance system about the node's activity. It does not affect the operation or future revenue of the node, but it may impact the visibility of the node in the public ranking system on the frontend application.
KIRA network's consensus nodes ranking system and the associated node statuses operates on block production and missed blocks counter and is measured through two performance indicators, streak and rank.
The streak functions like a short-term performance indicator, showing the sequential number of successful block proposals by a consensus node in real time. This is akin to kill-streaks in video games. A failure to propose a single block resets the streak to zero and increases the node’s mischance_confidence counter.
In contrast, the rank acts as a long-term performance indicator, reflecting the maximum streak a validator has ever achieved. It is the main performance indicator.
While a node's rank may decrease due to missed blocks, the ranking system accommodates for the unpredictability of block production chances and waits until a node misses a mischance_confidence number of blocks before considering the node offline. When a node’s status becomes offline, each subsequent missed block, or mischance counter, decreases the node's rank by a constant amount, mischance_rank_decrease_amount (set to 10 by default). However, if a node's status remains offline and their mischance score surpasses the max_mischance value, defined in the network properties, the system will categorize the node as inactive. An inactive status triggers a decrease in the node's rank by a percentage amount, defined by inactive_rank_decrease_percent (set to 50% by default).
Consequently, inactive consensus nodes get removed from the consensus node set and are barred from producing blocks. They can return to active status only when their operators signal readiness to produce blocks again, having resolved their internal issues, by using the activate CLI. The governance can adjust all these network properties to ensure a probabilistically fair decrease in a node's rank.
Ranking Reset
It may be useful for the governance to have the ability to reset all ranks simultaneously (e.g., incentivized games, etc.). For this purpose, the governance module has a dedicated proposal and corresponding voting permission.
Node statuses
Depending on it’s performance and activity, a consensus node can have one of the following statuses:
Pausing node
For planned maintenance where a consensus node must be offline, it can use the pause CLI to remove itself from the consensus node set. This will prevent the its rank from being impacted and the node will not be inactivated. When it is back online, the consensus node can use the unpause CLI to signal to the network that it is ready to rejoin the consensus node set.
Initial Framework for determining optimal ranking system values
Determining the optimal values for max_mischance and inactive_rank_decrease_percent depends on various factors, including the specific network conditions, the desired level of decentralization, average time for automatic recovery and the overall network performance. Based on the average block production rate, expected node uptime, and network latency of existing Cosmos ecosystem chains, the following initial values are proposed.
mischance_confidence: In the Cosmos ecosystem, the average block time is around 5-7 seconds. To give a node a reasonable amount of time to recover from temporary issues, mischance_confidence could be set to a value equivalent to 10 minutes, such as 120 blocks (assuming a 5-second block time). This would allow nodes to recover from short-term issues without being unfairly penalized.
max_mischance: Assuming an expected node uptime of 99% per day (i.e 14.4min of allowed downtime per day) and considering network latency, we can initially set max_mischance to 60 blocks (5min) . This means that, after missing 120 blocks, if a node misses another 60 consecutive blocks, its status will change to being inactive and its rank will be slashed.
inactive_rank_decrease_percent: To create a competitive environment that encourages node operators to maintain high performance, we can set the inactive_rank_decrease_percent to 20%. This value is significant enough to incentivize operators to address any issues leading to downtime quickly, without being overly punitive for temporary issues.
Parameters
Ranking System
Consensus nodes rank
Nodes rank and statuses are stored in the x/staking module and can be queried using Consensus nodes & staking pools CLI.
CLI syntax & examples
Each CLI command and proposal process in KIRA requires specific permissions. These permissions must be added to the account's whitelist or obtained as sudo permissions for direct changes. Refer to the Roles & Permissions documentation for more details. $SIGNER represents the transaction signer's account name or address. For instructions on setting common flags as environment variables, such as $FLAGS_TX and $FLAGS_QR, see the CLI flags configuration section
Governance
Transactions
sekaid tx customslashing
pause - Pause a consensus node
unpause - Unpause a consensus node previously paused
activate - Activate a consensus node previously inactivated for downtime
Pause Validator
Bash
Copy
sekaid tx customslashing pause \
--from=$SIGNER $FLAGS_TX
Unpause Validator
Bash
Copy
sekaid tx customslashing unpause \
--from=$SIGNER $FLAGS_TX
Activating an inactive node
Bash
Copy
sekaid tx customslashing activate \
--from=$SIGNER $FLAGS_TX
Queries
Nodes rank and statuses can be queried using the Consensus node’s dedicated queries.