Validator Re-Enabling

[Overkillus]

Aims to implement Stage 3 of Validator Disbling as outlined here: #4359

Features:

• New Disabling Strategy (Staking level)
• Re-enabling logic (Session level)
• More generic disabling decision output
• New Disabling Events

Testing & Security:

• Unit tests
• Mock tests
• Try-runtime checks
• Try-runtime tested on westend snap
• Try-runtime CI tests
• Re-enabling Zombienet Test (?)
• SRLabs Audit

Closes #4745
Closes #2418

[tdimitrov]

I had a quick pass by focusing mainly on the approach. It looks good, nice work @Overkillus!

I've left some thoughts about a corner case with the re-enabling.

[Overkillus]

bot fmt

[command-bot]

@Overkillus https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/7692315 was started for your command "$PIPELINE_SCRIPTS_DIR/commands/fmt/fmt.sh". Check out https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/pipelines?page=1&scope=all&username=group_605_bot to know what else is being executed currently.

Comment bot cancel 15-7908d2d9-da54-4b6e-af31-1b138de1c56d to cancel this command or bot cancel to cancel all commands in this pull request.

[command-bot]

@Overkillus Command "$PIPELINE_SCRIPTS_DIR/commands/fmt/fmt.sh" has finished. Result: https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/7692315 has finished. If any artifacts were generated, you can download them from https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/7692315/artifacts/download.

[Ank4n]

Is it possible to move most of the disabling logic to pallet_session?

It seems staking does not really need to know anything about disabling. Currently, we are maintaing two copies of disabled validator indices in both pallet_session and pallet_staking, apparently because staking only knows about era, but I am not sure what does that mean. Staking does not have any concept of disable in it, and it should only care about slashing. If the concern is that we want to keep a validator disabled for the whole era, staking returns a set of validators only for sessions that trigger an era. For other sessions, it simply returns None. So session should know when to clear disabled validators.

There is a larger reason as to why I am flagging this. With staking moving to AH, the offence lifecycle would be something like this:

• Offense is reported and verified on RC.
• Any disable logic applied and propagated by pallet_session. It should also keep track of SlashPerbill in its DisabledValidators store.
• An offence report (Offender, Session, SlashPerbill) is sent to AH for slashing.

In practice, pallet_staking will be replaced by pallet_staking_client (or a more suitable name) that will fill in the gaps. That is, it will act as OnOffenceHandler and SessionManager on RC, and async communicate with Staking/AH.

tl;dr: Given that Session and Staking communication would become async, this disabling logic doesn’t seem compatible or, at the very least, "good design" with that in mind.

[Ank4n]

Right?

Suggested change

	This PR changes when an active validator node gets disabled within parachain consensus (reduced responsibilities and
	This PR changes when an active validator node gets disabled within relaychain consensus (reduced responsibilities and

[Overkillus]

Not really. Parachains don't have their own native consensus or security and they derive it from the RLC.

In Polkadot when we say parachain consensus we are referring to parts of polkadot protocol that allow the inheritance of security and consensus to parachains AKA the part where we assign responsibility (backing), ensure availability, recheck correctness (approval checking rerunning of PVs) and punish wrongdoers (disputes and slashes).

I can maybe change it Parachain Consensus Protocol to make it a bit clearer but otherwise it is consistent with all our other materials. See here for instance: https://wiki.polkadot.network/docs/learn-parachains-faq#:~:text=%22Parachain%20consensus%22%20is%20special%20in,can%20control%20their%20own%20consensus.

[Ank4n]

Should this ever happen? Might want to mark this defensive.

[Ank4n]

This could be defensive as well.

Suggested change

	if i >= Validators::<T>::decode_len().unwrap_or(0) as u32 {
	if i >= Validators::<T>::decode_len().defensive_unwrap_or(0) as u32 {

[Overkillus]

@Ank4n

Is it possible to move most of the disabling logic to pallet_session?

(assuming we want to do this)

I will discuss if this is a good idea later below but even if we assume we want to do this I don't believe it is appropriate to do this in this PR. This PR only aims to, with minimal changes and refactors, simply allow for validator re-enabling using all the previous already in-place logic. I want to make sure that this PR is minimal and adheres to what was already pre-agreed in the design document for disabling, to limit audit time and just be more sure that everything does exactly what we think it does.

If we have plans to refactor the staking pallet (which as you mentioned will be done anyway during the port to AH) then it should be done in a separate primarily refactor/port PR.

---

Is it possible to move most of the disabling logic to pallet_session?

(answering if we want to do this)

Staking pallet as it stands is responsible for more than just slashing. It holds important params with regards to the active validator set. For instance min, ideal, and max validator counts. What it means to be disabled is not within the purview of the staking pallet, what it does is simply keeps track of highest offenders up to some limit and makes this info available for others. This is highly customisable and different users of this pallet can add new strategies with new limits.

Since we keep those validators for an era it makes sense to keep track of their offences (potential disabling status) also for a full era. Storing this information in session when we aim to keep it for era seems like an unintuitive approach.

I might agree that we could make it less opinionated by moving disabling strategies to session and instead keeping a history of all offences (unfiltered by disabling strategies) in staking. Nevertheless in this approach we still should keep track of all offences in staking. An offence is more than a slash, there might by other byproducts or consequences and we need to allow for them.

In the new pipeline for offences that you suggested, where do you think a history of offences within an era should be stored?

Session - Staking coupling

It is okay to keep staking bounded to session, but session should not be dependant on staking. Adding logic to session that is actually era-wide in scope through hacky reads of signals from staking seems well, hacky. This information should be kept in a context that is explicitly era-wide and shared with session.

TLDR: This might be a needed change but is outside of the scope of this PR and some of that information should still live in era-wide and not session-wide scopes.

[Ank4n]

@Overkillus

I wouldn't try to block you if you want to go ahead with this PR, especially since most of the things I flagged should ideally had been flagged with the earlier PRs, and this PR does not introduce a new design decision. That said:

I will discuss if this is a good idea later below but even if we assume we want to do this I don't believe it is appropriate to do this in this PR.

Since this PR touches the logic that we know we will have to migrate in next couple of months, it is reasonable enough enough to make those changes in this PR.

Staking pallet as it stands is responsible for more than just slashing. It holds important params with regards to the active validator set. For instance min, ideal, and max validator counts. What it means to be disabled is not within the purview of the staking pallet, what it does is simply keeps track of highest offenders up to some limit and makes this info available for others. This is highly customisable and different users of this pallet can add new strategies with new limits.

I believe you only require current count of active validator set. Could you point me any param that you need specifically from pallet_staking for disabling? The SlashPerbill is decided based on offense (also outside pallet_staking) and can be tracked in storage for disabled validators in pallet_session as well. I don't see it makes any difference.

In the new pipeline for offences that you suggested, where do you think a history of offences within an era should be stored?
It is okay to keep staking bounded to session, but session should not be dependant on staking. Adding logic to session that is actually era-wide in scope through hacky reads of signals from staking seems well, hacky. This information should be kept in a context that is explicitly era-wide and shared with session.

Why does offence or disabling has to relate with an era? pallet_session can use variety of ways to manage this.

• Only clear disabled validator when underlying economic condition changes, i.e. when it receives a new set of validators.
• Any time validator is disabled, keep them disabled for the next x sessions. x can be 6.

I think we have already tried to hack around with the concept of Era and Session, and having to maintain DisabledValidators in two places is a code smell stemming from that. If we look at pallet-staking independently, disabled in its context makes no meaningful sense. Another code smell is that the disable logic right now is spread between staking and session, with session acting like a proxy that receives disabled validators from staking and passes it to the session handlers.

IMO, this is a flawed design, in addition to the fact that it also doesn’t fit well with the post-AH migration setup.