Update Lock amounts based on slashing.

[kianenigma]

Context. We have pallets that have the ability to reduce the balance of an account's in a particular token. For simplicity, we assume a single-currency chain. This can be achieved through T::Currency::slash_reserved() or T::Currency::slash(), or anything similar.

And there are other pallets that make an assumption on a particular account having a specific amount of tokens, and throw a lock in there to ensure the balance does not go below that.

The problem. The problem is that this assumption can be easily torn apart by the former group of pallets, and if there are no communication between them, the latter group will make wrong assumptions. Note that sometimes both sides of the above scenario can even be the same pallet. For example, PhragmenElections sets a lock for a particular amount as the weight of a vote, but staking can slash that account in the meantime, potentially even killing the account entirely, whilst the vote will stay remain in PhragmenElection, with the same weight.

Potential solution. The straightforward approach to me is to allow different pallets to listen to account balance changes from other pallets. Currently, staking aggregates all slash amounts into one NegativeImbalance and reports them to the outer world. This needs to stay, but we need another similar event that is triggered per-slashed-account. For example:

enum ImbalanceType {
   Free,
   Reserved,
}
trait OnAccountImbalance<A, B> {
    fn on_account_imbalance(who: A, amount: B, type: ImbalanceType) {}
} 

Any pallet that wants to listen to this event would implement the above. Staking, ElectionsPhragmen, and other pallets that have the ability to slash funds can then implement it.

Discussion. I hope someone will recommend an easier way to solve this. What I proposed can be a bit to expensive, and is quite a pain to weigh properly.

Similar: paritytech/substrate#3088

[shawntabrizi]

An alternative to a hook would simply be a mechanism for people to report such discrepancies in the system and for the system itself to check there is an issue. I would consider this kind of extrinsic a "fisherman" task which ideally would reward the user for reporting the issue correctly, and charge the tx fee from them otherwise.

[xlc]

One of the problem is which pallet's reserved token should get slashed first?

Also most of the pallets assume their token reserved token will never get slashed / unreserved by other pallets otherwise the economic incentive will not hold. e.g. the deposit for proxy, identity, etc all provides incentive for people to purge unwanted data. but if the reserved token get slashed, the incentive will disappear.

[kianenigma]

One of the problem is which pallet's reserved token should get slashed first?

Also most of the pallets assume their token reserved token will never get slashed / unreserved by other pallets otherwise the economic incentive will not hold. e.g. the deposit for proxy, identity, etc all provides incentive for people to purge unwanted data. but if the reserved token get slashed, the incentive will disappear.

This can potentially be fixed by paritytech/substrate#7223

[kianenigma]

for nomination pools we added a OnSlash hook which can probably be used to fix this as well.

[gpestana]

At this point I'd use the OnStakingUpdate::on_slash event for this. Pallets that want to be notified when a slash in staking happens should implement the trait OnStakingUpdate and add themselves to the tuple of EventListeners in the staking config (similar to the approach with the stake-tracker but much simpler).

With this approach, there is nothing we need to do on the staking pallet side. But let's take a look at other polkadot-sdk pallets where we should implement the OnStakingUpdate trait to listen to staking slashes.

This is a more involved issue to work on but I'm happy to mentor someone who'd like to pick this up. I'll set this issue as mentor.