Decision on whether to cancel enactment of a deferred slash.

Back to Wei’s council profile

## Background

During Polkadot validation era 51, an unfortunate slashing event happened to one of the running validator, with around 45.9 DOTs being lost from nominators.

The slashing happened due to an unclear documentation (and argubly bug) in Substrate. The validator was acting in honest, trying to restore an offline running node. However, it used the blockchain state data from another backup node. That state data did not contain the necessary GRANDPA metadata, resulting it to misbehave and the slashing.

The council put forward motion #3 that will directly cancel the slashing.

## Decision

I have tentatively decided to vote no on Polkadot council motion #3. I want to note first that this decision has nothing to do with whether the slashing should be cancelled, but just concerns about precendents and rules. In fact, I think that as the validator is not malicious and the slashing acted as a warning sign for others on how to run validators securely, it’s not unreasonable to refund the cost eventually.

Below I want to explain my rationale of this vote. The summary is that I think council should be careful when deciding things that can make precendents. If possible, precendents are better made by democracy referendum via majority votes. In addition, deciding on-chain rules may be preferred than deciding on individual cases. The former gets the council out of the task of needing to repeatedly decide on individual cases and be able to focus on more important things.

## Council and precendent

Whether the slashing is cancelled will set a strong precendent for the Polkadot validator community, no matter which way it is voted. The council is democratically elected. However, there are only 13 members currently and the bias, no matter in which way, is still strong. I want to argue that as this is the first time slashing refund is considered, it would be better to put this forward as a democracy referendum which allows all coin holders to decide on the precedent, rather than the council.

## Rule and individual case

My second argument is that if possible, we may want to decide on a rule, rather than just the individual case.

First, this frees the council module and the democracy module from needing to repeatedly deciding on the same thing. Once the on-chain rule is set, it can later be delegated and executed semi-automatically with much less interference. This allows council to focus on things that benefit Polkadot more.

Second, there will always be two different spectrum of groups of people with different understanding of how blockchain should work. One spectrum believes that blockchains should be pragmatic and amoral. The other spectrum believes that blockchains should hold strong principles and be ethical. I think we should aim at solutions that can satisfy both groups when possible, and I believe voting on rules rather than individual cases can better accomplish that goal.

I’m working on a design of a new Substrate runtime module pallet-rules that can aid accomplishment of this goal.

## Notes on pragmatism

I also want to add an additional note that both of my arguments are not about removing council’s ability to decide on edge cases or being pragmatic. Even a precendent is obtained or a rule is applied, due to the nature of the human process, it’s not set in stone and can still be changed later. However, under normal operations, being consistent in handling governance matters will help a lot in bringing trust and confidence to Polkadot.

## Conclusion

I have tentatively decided to vote no on Polkadot council motion #3. Council should be careful when deciding things that make precedents. When possible, the precendent is better made by democracy referendum via majority votes. I also argue that in many cases, while the governance retain its ability to decide on individual cases, setting up on-chain enforced rules should be preferred.

I want to emphasis again that my decision on how to cast my vote on this has nothing to do with whether the slashing should be cancelled. In fact, I still remain neutral on that and think that as the validator is not malicious, it’s not unreasonable to refund the cost.