Double signing is the only penalized validator fault in KIRA. Double signing refers to a situation where validator proposes or participates in the production of two different blocks at the same block height. In short double-signing means creating or attempting to create a fork - that is publishing two parallel versions of the blockchain state. Forks can mischeave network observers because they allow the attacker to spend the same funds multiple times - once from each fork. To prevent such situation from occurring KIRA permanently jails validators who double signed.
Double signing does NOT necessary means that the validator is malicious on purpose and there can be many possible reasons for the node operator to unintentionally misbehave:
Launching node before its fully synced (validator signs old blocs)
CI/CD & Blockchain Application faults
Hardware faults such as accidental loss of state file
Misconfiguration during setup
Accidental deployment of two nodes with the same signing key
Majority of double-signing events occurs unintentionally and for that reason KIRA does NOT automatically slash delegators stake without governance judgement and does NOT automatically punish validators in any other way then by removing them from consensus. The reason this is possible is that validator set is governance permissioned and potentially malicious nodes can't re-join the validator set again by simply creating a new node with a new key and moving coins, as in the case of other PoS chains. The governance of the network is tasked with deciding fate of all validator nodes that commit double signing fault, weather they should be unjailed, left permanently removed from the validator set or slashed in critical cases of coordinated attacks. In either case the governance protects staked funds of delegators thus almost entirely preventing risk of accidental loss of funds.
Possible Double-Signing Outcomes
Governance chooses not to unjail validator and remove him from the validator set or the node becomes tombstoned after UnjailMaxTime passes
Governance determines that the failure was unintentional and unjails validator without slashing
Governance determines that the failure was intentional and organized thus permanent jailing and slashing should take place (to be available alongside MBPoS release)
Besides having ability to unjail validators who commited double signing, governance can define UnjailMaxTime network property, which defines time within which proposal to unjail validator must be submitted. If unjail proposal is not submitted then node becomes permanently jailed AKA tombstoned.
NOTE: Proposals can be raised using via CLI sekaid tx customstaking proposalcommand. The --help flag can be used to discover further options. To raise a certain proposal a dedicated permission is required. For example to submit UnjailValidatormessage a PermCreateUnjailValidatorProposal (20) permission must be assigned to the account creating said proposal. For example to vote on the UnjailValidator a `PermVoteUnjailValidatorProposal (21) is needed. To find available proposal types and corresponding to them permissions required to submit or vote see Proposals documentation.
Commands Examples
Unjail Validator Proposal
# CLI
sekaid tx customstaking proposal proposal-unjail-validator "$ADDRESS" "$REFERENCE" \
--title="Unjail validator '$ADDRESS'" --description="Proposal to unjail '$ADDRESS' due to his unintentional fault" \
--from "$ACCOUNT" --chain-id=$NETWORK_NAME --keyring-backend=test --fees=100ukex --yes --log_format=json --broadcast-mode=async --output=json
# KM
unjail validator "kiravaloperXXX...XXX"
Bash