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]

@Ank4n

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 is what I would suggest. This impl is simply a part of an earlier design which was pre-approved by SRLabs in the design's audit. It just adds some new functionality using the same infrastructure without altering it too much.

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.

We have the power to open multiple PRs to separate unrelated changes between the PRs. Enabling new functionality in the current design should not come with a major refactor if it is not neccesary. I am open to the refactor at a later stage but nevertheless it should be a separate PR.

This PR does not make the future refactor harder or easier. I would understand withholding the change if it made the refactor harder. It does not make it harder and is orthogonal.

On top of all of that this PR is a security-related fix. It has a higher priority than a genral refactor and should not be budled with it without a good reason. It might only obfuscate the auditing process.

The rest of the discussion dives into why the refactor might be a good idea later on which we should separate into a separate issue or ticket. I'd be happy to participate in those discussions and help as much as I can.

[tdimitrov]

We have the power to open multiple PRs to separate unrelated changes between the PRs. Enabling new functionality in the current design should not come with a major refactor if it is not neccesary. I am open to the refactor at a later stage but nevertheless it should be a separate PR.

I agree with @Overkillus here. Considering that this PR is part of the disabling strategy roll out I am strongly against doing any out of scope re-factorings.

What @Ank4n suggests definitely makes sense and we should do it but as a separate effort. Let's focus on the disabling strategy in this PR.

[sandreim]

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.

Given that this PR doesn't make it harder to do the migration in the future, your suggestion is best handled as separate task/PR. In general I think it is not a good idea to require unrelated refactorings in the scope of a change that is concerned with security.

@Ank4n please take another look and if there are no other causes of concern I would say we should merge. We want to get this change in production as soon as possible.

[Ank4n]

@tdimitrov @sandreim The refactoring needed is not unrelated. But blocking also serves no purpose, and we can handle this in a followup issue.

@Overkillus Could you check if its possible to get rid of the storage item DisabledValidators in pallet-staking and only maintain it in pallet-session (even if it results in a bit messy code)? This would make the followup refactor noop. Otherwise, I'm ready to approve.

@gpestana You may want to take a quick look at the changes as well.

[Overkillus]

Added all the defensive suggestions from @Ank4n Good eye for spotting them, thanks!

Could you check if its possible to get rid of the storage item DisabledValidators in pallet-staking and only maintain it in pallet-session (even if it results in a bit messy code)?

This is not trivial. 99% of the disabling logic lives in staking so moving it over is not easy and this is a major part of the needed refactor.

[paritytech-workflow-stopper]

All GitHub workflows were cancelled due to failure one of the required jobs.
Failed workflow url: https://github.com/paritytech/polkadot-sdk/actions/runs/11892215786
Failed job name: fmt

[Overkillus]

Tests in CI failed on test-linux-stable (1/3, parity-large-persistent):

   FLAKY 4/6 [  31.550s] pallet-revive-eth-rpc tests::deploy_and_call
   FLAKY 2/6 [   0.107s] polkadot-dispute-distribution tests::send_dispute_gets_cleaned_up
   FLAKY 2/6 [ 126.884s] polkadot-node-core-pvf::it execute_job_terminates_on_timeout
  TRY 6 FAIL [  30.260s] pallet-revive-eth-rpc tests::native_evm_ratio_works
  TRY 6 FAIL [   2.420s] sc-rpc-spec-v2 chain_head::tests::ensure_operation_limits_works

• eth-rpc tests (deploy_and_call & native_evm_ratio_works) seem to be very flaky overall, native_evm_ratio_works always fails locally (0/30)
• send_dispute_gets_cleaned_up is a bit weirder, passing locally with no fail (100/100)
• execute_job_terminates_on_timeout, always passes locally (100/100)
• ensure_operation_limits_works, always passes locally (100/100)

Looking into flaking tests further.