Drop initial slashing from CSM

What do we want

We need to address a change related to the initial slashing penalty value on CL that was brought about by the Pectra hard-fork. This value is currently used in the CSM module to burn this penalty right away when a slashing report is made.

Our ultimate goal is to remove all slashing-related code from the system, since it no longer makes sense in the current protocol state. Even with MEB supported by the module most of the penalty will be applied during the slashing period itself.

There are several ways to achieve the goal described below.

A. Update INITIAL_SLASHING_PENALTY value in the module

Actions required:

• Deploy and make deploy verification of a new CSM implementation with an updated variable value
• Start and pass Aragon vote

Pros:

• No significant actions resources required
• No re-audits required
• Can be included with Pectra-ready CSVerifier instance connecting

Cons:

• Requies a vote
• Not safe from the module perspective (see caveats section below)
• Still requires to keep check for the burned value on withdrawal

Caveats:

• Ideally we have to change the value just with a new hard fork
• If a slashing report was made before the upgrade (vote), resulting in a 1 ether penalty being burned, and then a withdrawal report is made after the upgrade, with the CSM using the newly updated INITIAL_SLASHING_PENALTY value, the contract will fail to properly account for the previously burned penalty. This leads to an issue where more than required would be burned in total. The problem can be resolved by adjusting the logic of the CSM module itself, but doing so would negate the advantage of not requiring an audit.

B. Disable slashing reporting via CSVerifier long before Pectra

Actions required:

• Prepare an updated CSVerifier code and re-audit
• Deploy and make deploy verification of the CSVerifier
• Start and pass Aragon vote

Pros:

• The safest way from the module perspective
• An ability to remove slashing penalty check on withdrawal with an upcoming CSM release

Cons:

• Requires re-audit of the CSVerifier
• Requires on-chain vote mid February

C. Disable slashing delivering on the prover instance and remove all the initial slashing stuff with CSM v2

This solution relies on the assumption that there will be no new slashing reports made to the CSM until after the v2 upgrade has occurred, or that any such report would not include a slashing proof being delivered. Given the historical context (only a few hundred validators have been slashed in total), and considering that the only actor interested in delivering slashings to the CSM is Lido, this assumption appears to be reasonable and likely to hold true.

If our assumption proves incorrect and slashing reports are made to the CSM before or during the upgrade period, then in the worst-case scenario, there could be:

• Operators who have penalties applied twice
• Possibly unbonded operators whose requested exit validators become stuck due to this issue.

Actions required:

• Disable a part of the off-chain logic of the prover bot
• Fingers crossed for no slashings!
• Release CSM v2

Pros:

• Nothing to do with the problem, just to release CSM v2

Cons:

• Relies on a risky assumption
• Requires extensive actions if the plan fails

Conclusion

It seems like option B is the safest approach from a module perspective, but it requires re-auditing CSVerifier and an on-chain vote. Option C is the most straightforward solution, but it relies on a potentially optimistic assumption.