Introduction of Approval Slashes [Disabling Strategy Stage 4]

[Overkillus]

Implementation of Stage 4 of the new Disabling Strategy.

Stage 3 needs to be deployed before this goes live. (Stage 3 PR)

Currently only backers are ever slashed as a result of disputes.

This PR creates 3 types of offences with respective slashes:

• ForInvalidBacked (100%) -> hard punishment as backers bear all the responsbility for validity
• ForInvalidApproved (2%) -> minor punishment to deter lazy validators
• AgainstValid (0%) -> very minor punishment (this causes disablement so opp cost)

Closes #4746

IMPL details:

This will require a change to parachains primitives which are used both on the runtime and node side. Rolling it out is time consuming so the plan is to release it in 2 parts.

First updade runtime only with new offence types but keep old runtime apis (mapping from new format to old) so the node logic can remain the same. This will allow us to have the new offences for disputes concluding on-chain. Past session disputes that require proof submissions will temporarily not support the new slash types (but they are rarer). This will make the network more robust in the short term (as it is much easier to deploy).

As the second part we can update the runtime apis and node side to fully support the new types.

TODOs:

• new offence types
• migrations (migration not needed because codec is compatible in conversion from old->new)
• migration tests
• conversion (new -> old) to preserve old runtime apis
• conversion of disputeProofs (old -> new) to maintain old past session dispute behaviour
• new runtime apis (postponed for later)
• disabling for spammy validators zombienet test
• disabling for lazy validators zombienet test
• unit tests

[ordian]

As we discussed, the way it's currently implemented makes it hard to deploy with too many breaking changes. I've dropped my proposal below how to make this change less breaking and not require a backport for the node side.

[ordian]

My suggestion:
add this new offence type at the end with index 2, such that this new type will be a superset of the old type (meaning we can they encode the same way except for the new variant).

We should keep the old enum as is and introduce the new enum with the new variant with From impl. The runtime should use the new variant (and have a runtime migration for disputes slashing storage) and the node side should use the old variant until the new runtime api version is available.

Runtime API should have a new method for getting unapplied slashes here that will return vstaging::PendingSlashes with the new enum variant. The old runtime impl should also exist and try to convert new types into old ones - filtering out the ones it can't.

With this proposal, old nodes will continue to work with the new runtime, but will be able to only submit slashing extrinsics to the runtime (for the past-session slashes) for backing and AgainstValid offences. Which is fine, because new nodes will be able to submit all of them.

[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/15461957597
Failed job name: build-runtimes-polkavm

[ordian]

I've looked into SemVer breaking changes of disabling PR and not sure if it's possible to avoid them completely. The problem is that report_offence method is used in both on-chain and off-chain slashing. If we want to use new offence type in on-chain slashing, we have to make a breaking change to SlashingOffence type.

[paritytech-release-backport-bot]

Successfully created backport PR for stable2503:

• [stable2503] Backport #6827 #8770

[Polkadot-Forum]

This pull request has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/polkadot-digest-11-jul-2025/13707/1