//
Consensus nodes ranks & statuses
Search
Duplicate
Try Notion
Consensus nodes ranks & statuses
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:
STATUS
DESCRIPTION
active
Validator is actively participating in consensus, proposing and signing blocks. Every produced block increases validator rank by 1
inactive
Validator stopped producing blocks and didn't signal to the network any planned maintenance. As the result his rank got slashed.
paused
Validator node entered maintenance node and is not producing blocks. The rank is not impacted.
jailed
Validator is jailed (permanently) due to double signing fault. Governance must investigate reason for the fault and unjail node via proposal.
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
NAME
TYPE
EXAMPLE
DESCRIPTION
address
string
kira1yq8l...
The address of the consensus node.
start_height
int64
1500
The height at which the consensus node was first a candidate OR was activated.
inactive_until
google.protobuf.Timestamp
2023-05-09T00:00:00Z
The timestamp consensus node cannot be activated until.
missed_blocks_counter
int64
0
Total missed blocks counter.
produced_blocks_counter
int64
4500
Total produced blocks counter.
mischance_confidence
int64
0
Mischance confidence counter - counts when node is in active status.
mischance
int64
0
Missed blocks counter - counts after mischance_confidence is reached and if node is in active status.
last_present_block
int64
1575648
The last block height signed by the consensus node.
Consensus nodes rank
Nodes rank and statuses are stored in the x/staking module and can be queried using 🚧Consensus nodes & staking pools CLI.
NAME
TYPE
EXAMPLE
DESCRIPTION
val_key
sdk.ValAddress
kiravaloper1yq8lg...
The validator key, casted to a Cosmos SDK ValAddress type.
pub_key
sdk.PubKey
kiravalconspub1zcjduepqw...
The public key of the validator, accepted as a cosmos.crypto.PubKey interface.
status
string
active
The current status of the validator.
rank
int64
112
A long-term statistic implying the longest streak that a validator ever achieved. This helps to judge real-life performance and reliability of validators.
streak
int64
10
The consecutive number of times that a given validator successfully proposed a block (since the last time they failed) that was accepted into the blockchain state. Similar to kill-streaks in video games, this implies short-term performance.
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
Proposals
Filter
Sort
Subcommand Path
CLI
DESCRIPTION
PERMISSIONS (VOTE/CREATION/SUDO)
proposal-reset-whole-validator-rank
Proposes to reset the ranking of all validators
26
27
proposal-reset-whole-councilor-rank
Proposes to reset the ranking of all councilors
62
63
proposal-jail-councilor
Proposes to jail councilors for violating the network's rules
64
65
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.
Proposals