-
Notifications
You must be signed in to change notification settings - Fork 40
Slashing
In contrast to a more common definition of slashing, we do not reduce a validator's stake upon slashing. Instead, the economic disincentive is done indirectly by barring the validator from the reward distribution.
In our case, slashing refers to the punishment of a slot in case of misbehaviour. The punishment consists of:
- the slot not being eligible for the block production during the current epoch,
- the slot being barred from any rewards during the current epoch,
- the corresponding validator being parked and subsequently retired from the staker registry without active unparking. We will discuss these punishments in more detail below.
One of our core concepts of our staking algorithm is its invariance w.r.t. stake splitting. It does not matter whether a validator has two keys, each staking 5 NIM, or one key staking 10 NIM. Because of this concept, it would not be possible to remove the full stake of a validator upon misbehaviour.
Thus, we previously determined a slash amount, which may be much smaller than a validator's stake. However, from an incentive point of view, this model is not much different from our current model.
In our model, we can always trace back a single slot that misbehaved. While, in practice, it is probable that the whole validator misbehaved, we cannot punish the whole validator and all its stakes, because it would lead to stake splitting. Thus, we always only punish a single slot with one exception: we also park the corresponding validator for this slot.
There are two conditions triggering slashing. Both will lead to the exact same consequences.
- Creating a fork can be proven by other validators using a fork proof, which triggers the slashing.
- Not producing a block in time will lead to a view change, which triggers the slashing.
Blocking the slot from block production has the effect that we do not need to wait for a faulty slot in the future. Note that a validator may occupy multiple slots, so that the validator might still be misbehaving with his other slots, before these will be blocked as well. Moreover, slots will not be blocked from the PBFT voting.
Blocking the slot from the reward distribution creates an economic disincentive for misbehaviour. Also, since the other participants can use the rewards to increase their stake, it decreases the corresponding validator's share in the overall stake.
By parking a validator we denote marking the validator for automatic retirement. Validators, in our system, can be active and thus be considered during validator selection or they can be inactive/retired. Only after a cool down period, retired validators may be dropped from the validator registry.
Upon slashing, we mark the validator owning the slot as parked. Parked validators are still considered active and thus are considered during the validator selection. The validator has the opportunity to unpark his stake until the end of the following epoch, which simply removes this flag. If the validator fails to unpark the stake, it will be automatically retired and not considered for future validator selections anymore.
This parking mechanism has the effect that we automatically remove offline validators. Temporary outages of a validator do only result in the validator being required to unpark the stake again.