Skip to main content

Jailing & slashing

Concept​

Building on the broader concepts explored in our guide, KIRA’s governance-permissioned validator set, a standout feature of its consensus system, addresses the inherent challenges in permissionless environments where any participant can become a validator and removal is nearly impossible. In Kira's framework, malicious validators can be permanently removed by their peers, a process made feasible because voting power isn’t based on the size of one's stake. This ensures that coin ownership doesn't lead to disproportionate influence. Consequently, Kira specifically targets instances of double-signing for potential slashing. By mitigating the risk of severe penalties for minor or unintentional errors, Kira's model aims to foster a strong, diverse validator community, enhancing network decentralization and resilience. This approach not only challenges the traditional necessity for harsh slashing in maintaining network integrity but also seeks a harmonious balance between security and inclusivity. Aligned with Byzantine principles, Kira embraces the inevitability of human error and system failures, showcasing a more adaptable and empathetic approach to network governance.

Automatic Jailing & Threshold Slashing​

In KIRA, double-signing is the only penalized fault for consensus nodes. Consensus nodes going offline will not be punished and/or slashed as explained in the Consensus nodes ranks & statuses. Double-signing occurs when a consensus node proposes or participates in the production of two different blocks at the same block height, creating or attempting to create a fork in the blockchain. A fork is when there are two or more valid chain histories that could be followed, and it's not immediately clear which one should be considered the "correct" chain, a.k.a canonical chain. Forks can disrupt network observers, such as light nodes, who do not have the resources to fully validate transactions and therefore rely on a single chain for their own operations. If a light node is unable to determine which fork is the canonical chain, it may be vulnerable to attacks where the same funds are spent multiple times, once on each fork.

However, double-signing does not necessarily mean that a consensus node is acting maliciously and in this case slashing doesn’t actually add any security to the network. There can be various reasons for unintentional misbehavior, such as:

  • Launching the node before it is fully synced
  • Application or hardware faults
  • Misconfiguration
  • Accidentally deploying two nodes with the same key

For this reason, KIRA does not automatically punish nodes for double-signing. Instead, they are automatically jailed and their fate is decided by governance later on, which may choose to unjail them, permanently remove them from the consensus node set, and/or slash them in cases of coordinated attacks. This protects delegators' staked funds and minimizes the risk of accidental loss, which is important when staking valuable assets such as Bitcoin, digital fiat, or commodities. This is possible because the consensus node set is governance-permissioned and voting power is not based on the stake backing them. This means that malicious consensus nodes can be permanently removed by other consensus nodes without being able to influence governance decisions.

To detect coordinated attacks, KIRA utilizes the concept of threshold slashing. An automatic slashing proposal only occurs if a certain number of consensus nodes double-sign within a specific time frame, with the threshold being less than 1/3 of all consensus nodes. The threshold slashing parameters, slashing_period (3600 seconds by default) and max_jailed_percentage (25 by default, i.e 25% of all active consensus nodes), are network properties that can be adjusted by governance.

Slashing and Governance Dispute Procedures​

note

Slashing a staking pool is a permanent operation. Once a pool has been slashed, it is no longer possible to add deposits to it, and there is no way to return it to its original state.

In KIRA, slashing is governed, meaning that the decision to slash and the amount to be slashed is determined by the governance and evaluated on a case-by-case basis to prevent cases where software bugs could result in the loss of delegator assets. KIRA's governance-permissioned nature reduces the difficulty and risk of running a node, making it accessible to anyone, even those with little experience, rather than requiring expensive cloud provider setups.

Jailing & Unjailing​

If a consensus node is caught double-signing, it will be automatically jailed by the network and its status will be changed to jailed. This does not necessarily mean that the node will be slashed, as double-signing is not automatically considered malicious. While a node is jailed, it (or any governance member with proposal creation permission 20) can request to be unjailed through a governance proposal using sekaid tx customstaking proposal unjail-validator. This request must be made within a certain time frame, defined by the unjail_max_time network property (600 seconds by default). If the request is not made or accepted within this time frame, the node will become permanently jailed. The process of unjailing a node is a judgment proposal, meaning that all governance members voting permissions 21 and consensus nodes with active status, can vote on whether or not the node should be unjailed.

While it is jailed, a node cannot propose blocks, doesn’t accumulate rewards, cannot receive any new delegations and cannot vote on any proposals. Meanwhile other nodes can wait to see if there is evidence of double-signing collusion with other potential malicious nodes or other suspicious activity during that time window.

Slashing​

If a slashing decision is being considered, all governance members with proposal creation permission 57 can rise a slashing proposal using proposal-slash-validator to slash and permanently remove the node from the active consensus node set. However, if max_jailed_percentage is reached, a slashing proposal for each incriminated consensus node is automatically rised by the network.

While a slashing proposal is ongoing, the consensus node under investigation can submit counter-evidence, or "refutation," using the refute-slashing-proposal method by providing an URL or CID to an IPFS resource. Once the counter-evidence is submitted, it cannot be updated again. If a governance proposal results in a slashing event, the consensus node can no longer be unjailed and its staking pool is slashed and becomes inoperative. Users can only undelegate their existing stake in this case.

A slashing proposal can have one of the following outcome:

  • If the slashing proposal ends without reaching the required quorum, the consensus node is not slashed and can request to be unjailed by rising an unjailing proposal.
  • If it ends by reaching the required quorum :
    • If the governance decided not to slash, the node is not slashed and can request to be unjailed.
    • If the governance decided to slash, the node is slashed by the percentage determined in the proposal and cannot be unjailed.

Governance Proposals Hierarchy​

Slashing proposals take precedence over unjailing proposals. If a slashing proposal is raised for a given consensus node, any active unjailing proposals related to this node are cancelled, and no new unjailing proposals can be raised until the slashing proposal is finalized. This hierarchical relationship ensures that no unjailing action can be finalized before a slashing action, which prevents malicious consensus nodes from starting to produce blocks and receive new delegations before a potential slashing event. This helps to prevent difficult-to-handle situations where malicious nodes are able to gain an advantage before being punished for their actions or having to slash new, innocent delegators.

Slashing Amount​

note

Jailed nodes being slashed as well as any of the others colluders listed in the proposal cannot vote on any proposal as their status is jailed and not active.

If a slashing proposal is rised, all governance members with voting permission 58 and consensus nodes with the active status, can vote by providing a slashing percentage as an input. This input is limited by the maximum slashing percentage max_slashing_percentage, which is a configurable parameter in the network properties. This percentage can range from 0% to 100%, with a default value of 0.5%. This limit is meant to provide delegators to have a quantifiable manner of measuring their potential risks when staking. The exact percentage of slashing for a given proposal is determined by taking the median of all votes inputs. For the slashing to occur, more than 50% of all governance members participating in the proposal process must vote with a non-zero slash.

Examples:

  • If the max_slashing_percentage is set to 0.1 and the slashing votes are: 0, 0, 0, 0, 0, 0.5, 1, 0.5, 0.25, 0.25, 0.25, 0.75, 0.01, 0, 0.25 then the median is 0.25 but the final slashing 10%.
  • If the max_slashing_percentage is set to 0.5 and the slashing votes are: 0, 0, 0, 0.01, 0.01, 0.03, 0.03, 1, 0.04, 0.05, 0.07, 0.08, 1, 0.1 then the median is 0.35 and the final slashing is 3.5%.
  • If the max_slashing_percentage is set to 0.25 and the slashing votes are: 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.5, 0.5, 0.01, 0, 0, 1, then the median is 0 and no slashing takes place.

Slashing proposal structure

{
	"offender": "kiraXXX...XXX",           // validator address that commited a fault
	"staking_pool_id": <integer>,
  "misbehaviour_time": <timestamp>,      // time at which misbehaviour occured
  "misbehaviour_type": "double-signing", //string type of evidence (in the future there can be different types)
  "jailed_percentage": <decimal>,        // percentage of validators that was jailed (colluded)
  "colluders": [                         // list of validator who colluded with a misbehaving validator
		"kiraXXX...XXX",
		"kiraXXX...XXX",
		...,
		"kiraXXX...XXX"
	],
  "refutation": "<string/url/CID>"       // validator supplied counter-evidence proving that his behaviour was not intentionally malicious,
  "votes": [
    { "voter": "kiraXXX...XXX", "slash": <decimal> },
		{ "voter": "kiraXXX...XXX", "slash": 0.5 },
		...
		{ "voter": "kiraXXX...XXX", "slash": 0 }
	]
}

Slashing Mechanism​

If a governance proposal results in a slashing event, the decided percentage will be taken off all staked tokens within the staking pool. The derivative tokens representing each one of these staked tokens will also lose their 1-to-1 peg. For example, if consensus node V1 is being slashed by 5%, then unstaking 2 of any tokens XYZ would only return 1.9 XYZ, similar to the concept of impermanent loss in automated market maker systems like Uniswap. KIRA's slashing mechanism uses a ceiling function to avoid transferring 0 amounts and to accommodate singular units and non-fungible tokens. A specific mechanism for non-fungible tokens will be implemented in a future update. The slashed tokens, including KIRA's native token KEX, are transferred to a governance-controlled community spending pool where a decision can be made regarding their final fate, such as giving them away to the community or refunding them in the case of unfair slashing. The information about the slashing, including the percentage and the result of the governance proposal, is recorded in the staking pool and can be queried for reference.

Parameters​

Cli Syntax & Examples​

note

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 section

Transactions​

There is no transactions other than the governance proposals for this sub-module.