Consensus nodes & staking pools

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:

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.

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.

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.

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.

The Cosmos Validator FAQ provides a wealth of information about being a consensus node for anyone interested in learning more about this role.

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

Query a specific consensus node’s information using either its account address, its node address or its moniker.

All existing staking pools real time metrics and their respective parameters can be queried using the following CLI.