Authors: Jeffrey Burdges
Other authors: Robert Habermeier, Alfonso Cevallos
We need our slashing algorithm to be fair and effective. We discuss how this means slashing must respect nominators' exposure, be anti-Sibel, and be monotonic.
Slashing within one era
In any era , there is a fixed amount of stake aka base exposure assigned by any nominator to any validator . We demand that slashing never exceeds nominators' exposure because doing so creates an incentive to break up stash keys. We avoid encouraging such Sibel-ish behavior in Polkadot because doing so makes Polkadot less fair and harms our information about nominator behavior.
We immediately remove any validator whenever they gets slashed, which prevents repeated slashing after that block height. There is however an inconsistency in that might commit multiple violations before the chain acknowledges the slash and kicks . We fear this introduces significant randomness into our slashing penalties, which increases governance workload and makes the slashing less fair. We also worry that might equivocate retroactively, perhaps to extort their own nominators. As a counter measure, if era sees validator slashed for several distinct proportions , then we define and slash their nominator only .
As an aside, we could write throughout if we wanted to slash different nominators differently, like by slashing the validator themselves more, i.e. for . We abandoned this idea because validators could always be their own nominators.
We actually have only minimal concerns about multiple miss-behaviours from the same validator in one era, but if we discover some in future then the slashing lock could combine them before producing these . In other words, with equality by default, but a strict inequality remains possible for some combinations. We expect this would complicate cross era logic, but such issues should be addressed by considering the specific miss-behaviour.
In essence, this definition provides default mechanism for combining slashes within one era that is simple, fair, and commutative, but alternative logic remains possible so long as we slash the same regardless of the order in which offenses are detected. We emphasise that future slashing logic might take numerous factors into consideration, so doing here retains the most flexibility for future slashing logic.
We do however worry about miss-behaviours from different validators both because nomination must restrict Sibels and also because correlated slashing need not necessarily involve the same validators. We therefore let denote the validators nominated by in era and slash from when multiple validators get slashed.
Slashing in past eras
As hinted above, we cannot assume that all events that warrant slashing a particular stash account get detected early or occur within the same era. If and are distinct eras then we expect so the above arguments fail. Indeed, we cannot even sum slashes applied to different validators because doing so could quickly exceeds nominators exposure .
We might assume to be the "same" stake, but this does not obviously buy us much. We therefore suggest slashing the amount
where again is the validators nominated by in era
In particular, there is still an extortion attack in which someone runs many poorly staked validators, receives nominations, and then threatens their nominators with being slashed. We cannot prevent such attacks entirely, but this outer reduces the damage over formula that add slashing from different eras.
We thus far kept our slashing relatively simple and fixed some fairness issues with the outer maximum , but created another problem: If gets slashed once, then could thereafter commit similar offenses with impunity, which is neither fair nor effective. As noted above, we accept this within a single era because validators get removed when they get slashed, but across eras nominators can support multiple validators. We therefore need another mechanism that removes this impunity to minimize any further risks to the network going forwards.
We propose to limit the eras spanned by this outer maximum to an explicit spans that end after an eras in which any slashing events for that span gets detected. In concrete terms, we partition the eras of some nominator into slashing spans which are maximal contiguous sequence of eras such that is the least era in which gets slashed for actions in one of the .
We shall sum offences across slashing spans. In other words, if we range over the slashing spans for then we have slashed in total
In particular, if gets slashed in epoch 1 with the detection occurring in epoch 2, then resumes nomination in epoch 3, and only then gets slashed again for actions in epoch 1 and 2, then these later slashes are counted as part of the same slashing span as 's first slash from epoch 1, but any slash in epoch 3 count afresh in a new span that gets added.
Slashing Span Lemma. Any slashing span-like construction must end whenever we detect some slash.
Proof. Let be the validators' minimum self exposure and let be the stake to become a validator. Some nominator nominates validators for with her account of stake. In epoch , stakes enough to become a validator in epoch , so stakes only and for stakes somewhat more. In epoch , commits a violation. If we did not end 's slashing span then then rule would prevent these slashes from actually slashing further. In this way, a planned series of violations causing slashes across epochs only actually slashes of the desired slash value.
There are many design choices that restrain this lemma somewhat, but they make our slashing fragile, which harms our analysis and compossibility.
We now detail several additional actions taken whenever some validator causes the slashing of some nominator . Among other concerns, these help mitigate reenlistment mistakes that nominators would occasionally make.
We first post a slashing transaction to the chain, which drops the offending validator from the active validator list by invalidating their controller key, or maybe just their session keys. In consequence, all nodes ignore for the remainder of the era. It invalidates any future blocks that do not ignore too. We also remove all nomination approval votes by any nominator for , even those who currently allocate zero stake.
We handle the nominator less speedily though. We merely update the slashing accounting below when the offense occurred in some past slashing span for , meaning we need not end their current slashing span. We go further assuming the usual case that the offense occurred in 's currently running slashing span though: We terminate 's current slashing span at the end of the current era, which should then start a new slashing span for .
We also mark suppressed which partially suppresses all of 's nomination approval votes for future eras. We do not suppress or remove 's current nominations for the current era or reduce the stake currently backing other validators. In principle, we could suppresses 's nomination approval votes somewhat whenever gets slashed in previous slashing spans, but doing so appears unnecessary because suppression really comes only as part of ending a slashing span.
Also, we permit to update their nomination approval votes for future eras during the current or future era, but doing so removes them from the aka suppressed state. We also notify that cause them to be slashed and suppressed.
These state alterations reduce the risks of unintentional reenlistment of any nominator, while also balancing risks to the network. In particular, these measures provide justification for treating any future nominations by separately from any that happen in the current era or before.
We cannot slash for anything beyond the unbonding period and must expire slashing records when they go past the unbonding period. We address this easily thanks to slashing spans: We track the maximum slash within each slashing span, which we update anytime a slash raises the slashing span's maximum slash. We shall use again below in rewards computations.
As an aside, there was another accounting strategy here: Record all slash events along with some value recording the amount actually slashed at that time. If is later than then we record the initial slash at and record a lesser slash at the later . These values permit slashes to expire without unfairly increasing other slashes. We believe this extra complexity and storage, does not improve network security, and strengthens extortion attacks on nominators.
We ask that slashing be monotonic increasing for all parties so that validators cannot reduce any nominator's slash by additional miss-behavior. In other words, the amount any nominator gets slashed can only increase with more slashings events, even ones involving the same validator but not the same nominator.
We think fairness imposes this condition because otherwise validators can reduce the slash of their favoured nominators, normally by making other nominators be slashed more. We know trusted computing environments (TEE) avoid this issue, but we do not currently foresee requiring that all validators use them.
We have achieved monotonicity with () because summation and maximums are monotonically increasing over the positive real numbers, assuming any logic that adjusts the also adheres to monotonicity.
There are no meaningful limits on the diversity of nominators who nominated a particular validator within the unbonding period. As a direct consequence of monotonicity, almost every nominators can be slashed simultaneously, even if only one validator gets slashed. In particular, there are "rage quit attacks" in which one widely trusted validator adds past equivocations that cover many nominators. We therefore cannot bound the total stake destroyed by a combined slashing event much below the slash applied to the total stake of the network.
In particular, we cannot prevent validators from retroactively validating invalid blocks, which causes a 100% slash. We could reduce these high slashes from old offenses if truly uncorrelated, but if correlated then only governance could interveen by searching historical logs for the invalid block hash.
Suppressed nominators in Phragmen
Above, we defined a slashing span for a nominator to end after the era during which a slashing event during gets detected and acknowledged by the chain. We asked above that all 's nomination approval votes, for any validator, should be suppressed after the era that ends a slashing span , but never defined suppressed.
We introduce a network paramater called the suppression factor. We let denote the value slashed from nominator in slashing span . We also let denote the slashing spans of within the unbonding period for which has not updated their nominations. We now ignore of 's stake in Phragmen when is marked as suppressed.
If suppression does nothing (), then at the next epoch enters a fresh slashing span by the Slashing Span Lemma, and risks additive slashing. We consider this problematic for several reasons: First, we consider 's judgement flawed, so they should reevaluate their votes' risks, both for themselves and the network's good. Second, could easily be slashed several times if reports are prompt, but only once if reports are delayed, which incentivizes delaying reports. Also, slashes could be caused by intermittent bugs.
If suppression removes all 's nominations (), then remains completely safe, but widespread slashing could remove massive amounts of stake from the system if many nominators get slashed nearly simultaneously, perhaps only by some small amount. If these fail to renominate quickly, then much of the total stake invested by nominators becomes suppressed, not unlike the "rage quit attacks" enabled by monotonicity. We consider this problematic because an adversary might suddenly control more than one third of the stake.
We think or sounds reasonable. We suspect meshes poorly with our 2/3rds honest assumption elsewhere. At some point creates similar issues to , but no intuitive arguments present themselves.
We have intentionally kept the above computation extremely simple so that can dynamically be changed by governance to reintroduce suppressed stake in an emergency. We code could change automatically but doing so appears pointless.
TODO: Import any discussion from Alfonso's text
Rewards for slashable offense reports
Interestingly, we find that monotonicity also constrains our rewards for offense reports that result in slashing: If a validator gets slashed, then they could freely equivocate more and report upon themselves to earn back some of the slashed value. It follows that slashes should always slash the validator's self stake more than the reward for the slash.
Rewards based on slashing nominators
We quickly give an inefficient straw-man that describes issuing rewards based upon slashing nominators.
We define to be the maximum proportion of a slash that ever gets paid out, presumably . We also define to be the proportion of paid out initially on the first offence detection. So a fresh slash of value results in a payout of . Set so that .
We consider a slash of value being applied to the nominator . We let and denote 's actual slash in slashing span given by before and after applying the new slash, respectively, so when 's slash increases by .
We track the value in 's slashing span record, but we also track another value that represents the total amount paid out so far. If then we pay out and increase by this amount. If then we pay out . In either case, we store .
In this way, our validator cannot reclaim more than from a slash of value , even by repeatedly equivocations, so should remain below the required self stake. Any slash of size always results in some payout, but slashes less than never pay out.
Rewards based on slashing only validators
We dislike that the above reward scheme requires both considering all impacted when doing payouts, and imposing the bound that remain below the self stake remains tricky.
We therefore propose to compute rewards only for validators being slashed instead. We shall require that validators always get slashed whenever their nominators get slashed, which means validators cannot be slashed 100% without their nominators all also being slashed 100%.
We have some minimum exposure aka stake that validator operators must provide themselves, meaning . As a simplifying assumption, we ask that be kept small enough that rewards can always be covered by the validators' exposure, meaning . We do not explore any cases where this fails here, but doing so requires a subtle definition of some such that rewards still cannot create inflation.
We now define such that where is our required minimum total stake for any validator. In the above scheme, we shall replace by and only apply the payouts to slashes against validator operators minimum exposure , meaning replace the slash value by .
We consider a slash of value being applied to the validator . We define the minimum validator adjusted slash value to be the fraction of this slash applied to the minimum validator stake . We have a total minimum validator adjusted slash given by , which provides an analog of total regular slashes but only considering the validator themselves.
We next let and denote 's total validator adjusted slash in their slashing span before and after applying the new slash, respectively, so when 's total validator adjusted slash increases by .
We track the value in the validator 's slashing span record, but we also track another value that represents the total amount paid out so far. If then we pay out and increase by this amount. If then we pay out . In either case, we store .
In this way, our validator cannot reclaim more than from a slash of value , even by repeatedly equivocations. Any slash of size always results in some payout, but slashes less than never pay out.
In both scheme, we have similar payouts initially, but our second scheme with payouts based only on the validator slashes results in smaller reward payouts when cross era slashing logic kicks in. As an example, if a validator gets similar slashes for different epochs, then the factor would reduce the entire reward if payouts are based only on the validator slashes, but if has disjoin nominators in every epoch then the factor makes only a minimal appearance.