//
🚧
Consensus nodes & staking pools
Search
Duplicate
Try Notion
🚧🚧
Consensus nodes & staking pools
Concept
The problem of improving the probabilistic finality of PoW consensuses has been treated by a variety of committee-based PoS consensuses such as Tendermint. However, unlike in the former mechanism, where all consensus nodes ("miners") are able to propose a block and one of them is chosen probabilistically, in a committee-based blockchain, blocks are cooperatively created through a voting mechanism. Therefore, the consensus over the "valid" state of the blockchain depends on the voting behavior of all its consensus nodes.
However, since permissionless settings inherently exhibit Sybil vulnerability, assessing nodes' rational behavior becomes impossible. As a result, the prevalent solution has been to apply a weighted voting power rule, where both consensus and governance votes are weighted by their respective stakes. In this paradigm, a block (or a governance proposal) is considered valid when it accumulates at least two-thirds of the total voting power from the consensus nodes set. Regrettably, this approach has often led to the centralization of power in the hands of a few large token holders, as exemplified by Cosmos, where more than two-thirds of voting power of most chains is concentrated in just 5 to 7 entities. And this system, in fact, still does not guarantee that their intentions align with the best interests of the network in the long term.
KIRA builds upon Tendermint as its consensus engine and introduces fundamental adjustments to the block proposer role, transforming the system into a governance-permissioned one that unlocks powerful features:
The Committee, a.k.a Consensus node set or “Validator” set, is no longer fixed and determined by stake eligibility. Instead, network governance controls who can join and leave the committee, and can set requirements such as proof of individuality (through the 🚧Identity Registrar for instance and which doesn't have to be KYC), community involvement (such as joining consensus node standups), or adherence to the Code of Conduct in the 🚧Data Registry to increase sybil resistance.
The block proposer role rotates according to an equal probability round robin mechanism, meaning that all consensus nodes have an equal chance of proposing new blocks. This also means that they are rewarded equally, rather than proportionally to their stake. More information on rewards distribution can be found in the Rewards Distributor module.
Claiming a validator seat
Before any Consensus node can participate in network validation, they must first "claim" their Validator Seat, a process parallel to how governance members claim their Councilor Seat. This action acknowledges the network Code of Conduct and allows the integration of the node in the consensus registrar. To submit a MsgClaimValidator transaction, the account must have permission 2 , which is assigned either through governance (mainnet) or granted by the sudo account (testnet). In addition, this transaction requires the node's globally unique moniker identifier as a parameter. This moniker is a friendly name with minimum 4 non-whitespace characters that can be set in advance by the account via the 🚧Identity Registrar module, or directly when submitting the transaction via the claim-validator-seat CLI if it has not been assigned a value yet. If a different value than the existing one is provided, the transaction will fail. This process ensures the unique identity of each consensus node in the network.
Staking pools status & commissions
Each consensus node operates its own staking pool where delegators can stake their assets. Each staking pool has a unique ID that is linked to the consensus node's address. The consensus node has the ability to enable or disable the staking pool, as well as set the commission rate on block rewards. Staking pools play a crucial role in reward distribution on KIRA network. All rewards are managed and distributed through these pools, which helps to streamline the process given the network's diverse range of staking tokens.
Before the block’s and fee rewards of a given block are distributed to proposer staking pool’s delegators, the proposer takes a percentage of both types of rewards as commissions. Regarding block rewards, subsidized by KEX inflation, each consensus node setup their own staking pool’s commission rate. The commission rate is a decimal value that cannot be set above 0.5 (50%) and under 0.01 (1%) to prevent them from over-charging delegators or undercharging them in order to make smaller consensus nodes unprofitable. Commissions over fee rewards from execution fees, however, are homogeneous to all staking pools and defined by a governance managed validators_fee_share network property. Likewise, validators_fee_share is capped at 0.5 (50%) but can be set to 0.
Performance-based rewards
Consensus nodes are subject to a performance evaluation and the amount of rewards they will actually receive from their commission is pro-rata to their participation in the consensus. If they fail to sign consecutive blocks during a given period, some of those rewards are cut off and sent to the community treasury. Outstanding block and fee rewards are then sent to the consensus node’s staking pool and become claimable by their respective delegators in proportion to the derivative tokens they have. Notice in particular that consensus nodes can be rewarded twice: once through both previous commissions they take as consensus nodes for their service, and once more as delegator if they delegate some assets.
For more information regarding network rewards distribution mechanisms please refer to the 🚧Fees and staking rewards distribution module. For more information regarding KIRA’s economics, please refer to the MBPoS and the Underlying Economics section of the Multistaking module.
Consensus nodes ranks and statuses
đź“Ś
The status of a consensus node and the status of its staking pool are two distinct things. Consensus nodes that have not created a staking pool or have disabled it can still participate in the consensus process and produce blocks, but they will not be eligible for any rewards.
KIRA network uses a ranking system to incentivize consensus nodes to stay online, or active, and create a friendly, competitive environment. The ranking is based on the number of blocks a consensus node produces and the number of missed blocks. If a consensus node signs a block, their rank increases. If a consensus node consecutively fails to sign a block for a certain number of times, they are deemed offline, or inactive, and their rank decreases. The ranking system also includes a mechanism for consensus nodes to temporarily pause their node without affecting their rank, and for the governance to reset all ranks periodically. Inactive consensus nodes are removed from the consensus node set, cannot produce blocks and are unable to perform some actions such as editing their staking pool until they signal they are ready to be active again. If a consensus node is inactive, delegators cannot delegate any tokens; they can only undelegate their stake.
For more information regarding consensus nodes ranking system please refer to the Consensus nodes ranks & statuses section of KIRA’s slashing module.
Consensus node FAQ
The Cosmos Validator FAQ provides a wealth of information about being a consensus node for anyone interested in learning more about this role.
Parameters
Staking pool properties
NAME
TYPE
DESCRIPTION
id
int
Pool’s ID
commission
int
Defines the staking pool’s commission rate over block rewards (cf. 🚧Fees and staking rewards distribution)
enabled
boolean
Defines if the pool is enabled or disabled. If set to false the pool doesn’t accumulate any reward and delegators are only able to unstake.
CLI functions description
x/customstaking
claim-validator-seat - Claim a consensus node seat to be part of KIRA’s consensus node set.
x/multistaking
upsert-staking-pool - Create or edit a staking pool as a consensus node.
query/customstaking
validator - Query an active consensus node’s information (val key, rank, active status, streak) using filters
validators - Query all existing consensus nodes using specific filters
query/multistaking
pools - Query all existing staking pools and return their respective parameters (enabled, commission) and current metrics (total staked tokens, total accumulated rewards, …)
Governance
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
Claiming a seat to join the consensus node set
Joining the consensus node set is done by sending a claim-validator-seat transaction which requires a 2 permission. This permission is assigned either through governance (mainnet), or granted by the sudo account (testnet). The claim-validator-seat transaction requires the node's globally unique moniker identifier as a parameter. This moniker can be set prior, via the Identity Registrar module, or directly via the claim-validator-seat CLI if it does not already have a value (the transaction will fail if given a different value than the existing one).
$MONIKER
string
Moniker of the account who wish to claims a consensus node seat
$PUBKEY
string
Public key of the account who wish to claims a consensus node seat
$COMMISSION
string
The commission rate
Bash
Copy
sekaid tx customstaking claim-validator-seat \ --from=$SIGNER $FLAGS_TX \ [ --moniker=$MONIKER || --pubkey=$PUBKEY ]
​
To verify if the consensus node seat was successfully claimed, the validator query should be returning a JSON similar to the following:
JSON
Copy
{ "val_key": "kiravaloper1q0fkns62jl4mfxavxug4rvsp7d4770mfkzupzp", "pub_key": { "@type": "/cosmos.crypto.ed25519.PubKey", "key": "YMPiwZecoXe2m7UrO3hJtl51lYrMCGS+rlGuN1I7dpA=" }, "status": "ACTIVE", "rank": "49", "streak": "49" }
​
Creating/editing a staking pool
An active consensus node can create or edit its unique staking pool using the upsert-staking-pool transaction. The commission rate is a decimal value that cannot be set above 0.5 (50%) and under 0.01 (1%). Editable parameters :commission, enabled (default=true).
$VAL*
string
Consensus node’s address kiravaloper...
$COMMISSION
int
Staking pool’s commission rate over block rewards
$ENABLED
bool
Staking pool status
Bash
Copy
sekaid tx multistaking upsert-staking-pool \ --from=$SIGNER $FLAGS_TX \ $COMMISSION --enabled=$ENABLED \ $VAL
​
Bash
Copy
# Example sekaid tx multistaking upsert-staking-pool \ --from=$SIGNER $FLAGS_TX \ --enabled=false kiravaloper1q0fkns62jl4mfxavxug4rvsp7d4770mfkzupzp
​
Queries
$ADDR
string
Consensus node’s account address
$VAL
string
Consensus node’s address kiravaloper...
$MONIKER
string
Consensus node’s moniker
$STATUS
string
Status active/inactive
$PKEY
string
Consensus nodes’s public key
$PROP
string
The proposer key
Consensus node information
Consensus nodes information, such as the consensus node’s address, status, streak and rank, can be retrieved by using the following queries.
List all existing consensus nodes using different kind of filters
Bash
Copy
sekaid query customstaking validators [--addr=$ADDR || --val-addr=$VAL || --moniker=$MONIKER || --status=$STATUS || --pubkey=$PKEY || --proposer=$PROP] $FLAGS_QR | jq
​
Query a specific consensus node’s information using either its account address, its node address or its moniker.
Bash
Copy
sekaid query customstaking validator [--addr=$ADDR || --val-addr=$VAL || --moniker=$MONIKER] $FLAGS_QR | jq
​
Staking pool information
All existing staking pools real time metrics and their respective parameters can be queried using the following CLI.
Bash
Copy
sekaid query multistaking pools $FLAGS_QR | jq
​